Start-CHARGENAmpAttack – Looking at CHARGEN protocol denial of service attacks
I am going to start by saying that this post is pretty much all Patrick Gray's (http://risky.biz, @riskybusiness). Patrick recently did a short interview with Marc Eisenbarth as part of the AusCert coverage for the Risky Business podcast, where they were discussing amplification attacks like those seen using DNS and NTP, but also looking at the future where things like SNMP or even the CHARGEN protocol might come into play. Now I happened to be listening on a train that was slowly going nowhere, and thought to myself, how hard would it be to write a CHARGEN DDOS tool that makes use of these amplification techniques? Could I manage to write one?
So last week, whilst managing work, on call, and a dead PSU in my main machine at home, I started looking at how easy it would be. All in all, it took about 3 days from inception to actually having a primitive tool which could be used. I can’t take all of the credit for this however, I had help from Google and some rather good pieces of code from www.winsocketdotnetworkprogramming.com (that is one long domain name). All I did was add some easy to use PowerShell code using jobs to provide parallelism.
So before we get too far along. Let’s talk about CHARGEN.
What is CHARGEN?
CHARGEN, or the Character Generator Protocol, is a network service defined in RFC864, from way back in 1983 (which makes it older than me). It was designed for testing, debugging and measuring networks and applications. The idea is simple, connect to the port and get a “random” amount of “random” characters back. You can connect on TCP or UDP on port 19, with none/some data, and it will send the “random” data back to you.
The specification contains a significant number of security issues which as you will see shortly, will lead to its misuse. This isn’t a protocol which is in wide use today, but oddly enough, you will find it in some of the most peculiar places (home routers, printers, etc) and this is why we, as IT and security professionals, need to be aware of its capabilities.
To enable CHARGEN services in Windows, simply install the “Simple TCP/IP Services”. In Linux, enable via INETD.
How do we abuse CHARGEN?
The most typical abuse for a protocol like CHARGEN is by its involvement to amplify DDOS via the spoofing of source IP addresses in UDP packets. The scenario is pretty much the same whether the protocol to be abused is DNS, NTP, SNMP or CHARGEN. The attacker sends a UDP packet to the server running the protocol, however the source IP address has been specified incorrectly, in other words, spoofed, to look like a different address. In this case, the attacker will specify an IP address of a server or service they which to DDOS. When the server receives this UDP packet, it will send the response back to the source address. This response will be sent to the victim machine, the one whose IP address was fraudulently specified in the original packet.
How does this amplify our attack? Well, the attack is sending an extremely small packet to the server running CHARGEN, which will then send back a packet containing the “random” data. This response can be anywhere from a few bytes to several kilobytes in size. Thus, the attacks very small message has been amplified to something much larger.
Let’s take a look at a quick CHARGEN message exchange. In the capture below, our client has sent a message to the CHARGEN server, which has responded back to it straight away. The client send a packet with a length of 58 bytes, and the server responded with a packet with a length of 1441 bytes. This is roughly a 28 fold increase in size. It should also be noted that the source MAC for the incoming packet matches the destination MAC of the outgoing packet. This means that at the hardware later, the same machine sent and received this packet.
Packet papture of a legitimate CHARGEN session
But how do we do this in practice?
We need to be familiar with network and socket programming to be able to create UDP packets with invalid/spoofed source addresses, it isn’t something we can simply do with the Microsoft .Net Framework’s building UDPClient class. The built in UDPClient class automatically specifies our IP address as the source IP in the packet, and we don’t want that. We need to work with the lower network socket classes to have our way.
Now, I wanted to try and do all of this in PowerShell, but right now I just don’t have the knowledge, and my .Net and C# skills are pretty limited as well. Thankfully as I was trying to learn .Net socket coding, I came across the site, www.winsocketdotnetworkprogramming.com, and whilst the site resembles something from the 1990’s, there is some really good stuff there. In particular interest to me/us for this code is Chapter 8, and within that chapter, sections 23 and 25.
Section 23 (Creating Protocols Header Definition Class (C#)) covers off developing a basic wrapper around the low level .Net framework socket components, allowing for a simpler way of creating and sending things like UDP packets. These protocol header definitions are expanded upon in Section 25 (C# Raw UDP Socket Program Example). At the end of Section 25, you will have an application called RawSocketUDP.exe, which is perfect for UDP packet spoofing and amplification attacks. The executable takes in a source and destination IP and port, an IP on the local machine to bind to, a payload size and the number of packets to send. Normally, the bind address (the IP address on our system we want to use to send the packet) and the source address would be the same, because we want the response to come back to us, but if we want to be naughty, we simply say another address is the source.
Our first CHARGEN attack!
The demo environment consists of 4 machines:
Two servers with CHARGEN - 192.168.1 and 192.168.2
One attacker – 192.168.1.10
One victim – 192.168.1.20
So how do we go about an attack using source IP address spoofing and the amplification abilities of CHARGEN?
Well, here is an example CHARGEN attack:
RawSocketUDP.exe -as 192.168.1.20 -ad 192.168.1.1 -ps 3389 -pd 19 -b 192.168.1.10 -n 1
A break down is:
Source (-as) is 192.168.1.20 – this is the system we are trying to take down, our victim
Destination (-da) is 192.168.1.1 – this is our server running CHARGEN which will be exploited
Source Port (-ds) is 3389 – The CHARGEN service response will be directed at this port (UDP)
Destination Port (-pd) is 19 – This is the port number for CHARGEN on the server we are exploiting
Bind Address (-b) is 192.168.1.10 – This is our IP address, we need to specify which network interface we are send the packet out on.
Number of times to send (-n) is 1 – Send one UDP Packet
So what happens when we run this command? Well let’s look at a packet captures. Note: yes, the times are slightly off in the captures, the test lab didn’t/doesn’t have super accurate clocks. Onwards to captures.
First on the machine we are launching the attack from:
Packet capture from attacker's PC
See how we send out a packet, but get no response. Also note that the source isn't our IP address of 192.168.1.10.
Now on the server running CHARGEN:
Packet capture from CHARGEN Server
See how we receive one CHARGEN request packet, and send one out but notice that the source MAC address for the incoming packet differed from the destination MAC addresse for the response! This is the clear sign that the source IP address has been spoofed in thus packet.
And finally, the victim:
Packet capture from victim
See how we receive a packet when we weren't expecting one.
How do we scale this attack out?
Now how do we weaponize this on a large scale?
Well, what about PowerShell!!!
So how would we go about this one? Well this is/was my thinking:
- Get list of CHARGEN systems
- Import list into PowerShell
- Run a separate PowerShell Job for each server, which:
- Runs RawSocketUDP.exe
- Sleeps
- Repeat
Sounds pretty easy to do. What we need is a PowerShell CMDLet that can simplify the process, accepting say, a victim’s IP address, some CHARGEN servers, etc. and then run RawSocketUDP.exe in parallel against each of the specified servers. We would need some logic to keep running the executable over and over again, perhaps having a small sleep between each time we send a batch of UDP packets to the CHARGEN server.
Let’s take a look at what I came up with:
This is a rather simple CMDLet, accepting as parameters specifying the IP address of the victim, the IP address on out machine sending the initial CHARGEN packets, one or more Servers running CHARGEN (with values taken from the pipeline) and finally the folder where the RawSocketUDP.exe is located. Optionally we can specify the port on the victim side, the number of messages we will send in each period and the period we will sleep between runs. For these optional parameters, the defaults are UDP3389 (RDP), 10 messages and 10 seconds.
The Process {} code block is rather simple, for each CHARGEN server IP address specified earlier, we will create a new job. The job has a rather simple ScriptBlock {}, which will start by changing the location we are currently at to be the previously specified location of the RawSocketUDP.exe. After that, there is a simple while ($true) loop which will run indefinitely and does two things; run the RawSocketUDP.exe with the appropriate parameters, and then sleep for the specified period of time.
That’s all of the code, rather simple and easy.
Let’s perform a larger attack
This time, we are going to perform a much larger attack than our first. This time we will make use of two servers running the CHARGEN protocol, 192.168.1.1 and 192.168.1.2 to direct attack traffic to our victim on 192.168.1.20.
After importing the function previously mentioned. Our attack comes down to this oneline:
So what is this command? Quite simply we are passing an array of CHARGEN server IP addresses to our Start-CHARGENAmpAttack function, specifying the victim IP, our IP and of course, the location of the RawSocketUDP.exe.
What will happen next? Well, every 10 seconds we will send 10 UDP packets to the CHARGEN server, which will respond, but direct the response to the victim IP. This will keep happening until we stop the jobs with the following commands:
Of course, we might want to up the number of packets we send, and reduce the sleep period. We probably want to target more CHARGEN servers as well.
And a quick look at the packet capture on the victim…yes there are lots of unwanted packets flowing in!
Packet capture from victim with multiple CHARGEN servers attacking
How effective is it?
It is hard to really say how effective this attack is. In my simple lab, the two CHARGEN servers did generate a significant amount of traffic, however determining if this could be effective isn’t something I have the gear to do. What I can say is this, in my simple lab, left alone for two hours, the two CHARGEN servers did manage to crash the machine which was the victim. As we have seen this amplification attacks, especially DNS and NTP be quite effective against large targets, then CHARGEN could also be leveraged, providing you can find enough servers running the protocol.
So where to from here?
This is the hard part really. No one should have CHARGEN exposed, but it is always worth checking your environment to be sure, and not just the perimeter, this attack could be deliciously fun within a corporate network. Printers and print servers and the like often have CHARGEN running, and would make good little zombies for attacking some other part of the corporate infrastructure, and without some decent monitoring in your environment, this could be a pain to lock down.
I hope you enjoyed this blog post. It was longer than usual, but I really do hope there was something in there for people to enjoy. If you do try out CHARGEN amplification attacks with what you have seen here, please let me know, I would love to hear from you.
Links for PowerShell Shenanigans
I thought it might be easier for those wanting the links from my resent presentation if I provided a list of them here, so you didn't have to go through the presentation to find them.
My code on GitHub: http://j.mp/1i33Zrk
QuarksPWDump: http://j.mp/1kF30e9
PowerSploit: http://j.mp/1gJORtF
PowerWorm Analysis: http://j.mp/RzgsHb
PowerBleed: http://j.mp/1jfyILK
Microsoft PowerShell/Security Series:
Practical Persistence in PowerShell: http://j.mp/1mU6fQq
Bruteforcing WinRM with PowerShell: http://j.mp/1nBlwX2
I hope you all enjoy!
Brisbane Infrastructure Group Presentation
On Tuesday I presented to the Brisbane Infrastructure Group a similar presentation to the one at CrikeyCon. This presentation contains updated information, some defence measures and just better information overall.
You can download the slide deck here, and the SlideShare can be found here (and embedded below).
PowerWorm Analysis and Weaponized PowerWorm
So Matt Graber posted a few weeks ago three items of significant importance for PowerShell security folks.
The first, is he has performed an extremely detailed analysis of PowerWorm, the PowerShell malware that TendMicro found about a month ago and I wrote about as well. Matt has gone one better though, and rewritten the code, make it safe, and cleaned up the abstraction and obfuscation and put all of the code up on GitHub.
I recommend everyone, both those who are interested in PowerShell and those who are interested in malware to take a look.
Matt talks about why the PowerShell execution policy doesn’t help, the code uses the –endcodedcommand parameter when calling powershell.exe. I didn’t know about this till recently, and I was shocked at its effectiveness. If you haven’t looked into this one, I so thoroughly recommend you do, it is amazing.
There is plenty of other interesting things though, considering how this malware users PowerShell and WMI to persist. As I mentioned earlier, the use of the Net.WebClient explained why Polipo was needed as well as Tor.
I also was highly interested in the use of freegeoip.com, I have already started writing some code to make use of this site. I recommend you take a look.
Please go and look at the Matt’s post, and at his GitHub code.
But wait, there is much more! PowerWorm has picked up the functionality of CryptoLocker!!!!
Matt also tweeted a link to this post at Bleeping Computer, which describes a new variant of PowerWorm, dubbed PoshCoder or PoshKoder. This variant is encrypting files and folders in a manner similar to CryptoLocker, and then demanding the victim pays a fee of a couple of bitcoin.
The posts on Bleeping Computer do reference more volatile code, so I do warn you that it isn’t safe to play with unlike Matt’s deactivated code, so be careful. If you want to play, look at Matt’s code.
One interesting thing, is amongst these posts, it appears the malware writer makes an appearance. Whilst I and those on the forum could be wrong, there are some cryptic comments by one of the posters who makes even me wonder.
What is interesting, is that what Matt, TendMicro, myself and most others thought was harmless, has been successfully weaponized, and done so entirely in PowerShell. This malware, PoshCoder, is just as dangerous as CryptoLocker, but nowhere near as detectable. Right now, the low infection rates have prevented this from becoming a massive problem.
Last thing, paying the ransom doesn’t seem to be effective. There is a glitch somewhere and decryption isn’t working correctly. So bad news for anyone infected, you probably can’t get your files back.
Good news, some people have reported that Microsoft Security Essentials is detecting the malware.
More PowerShell Malware Found In The Wild
Last night Matt Graeber of @mattifestation published a tweet that quickly gained my interest:
Woot! More PowerShell (albeit lame) found in the wild. http://t.co/jQk1kL6TRD
— Matt Graeber (@mattifestation) March 28, 2014
Matt was commenting on a TrendMicro post, Word and Excel Files Infected Using Windows PowerShell, in regards to another (in Matt’s words, “lame”,) discovery of PowerShell Malware. TrendMicro discovered two pieces of malware W97M_CRIGENT.A and X97M_CRIGENT.A, which really in the big picture are quite unremarkable pieces of malware.
There are however, some functions/features of this malware that will be interesting to anyone who saw my presentation.
Firstly, the malware enters via an infected Word or Excel document, much like the initial entry during my presentation. The malware that TrendMicro discovered is significantly more complex than mine is, making use of some interesting DNS queries and cloud storage provides for hosting things like Tor and Polipo. The use of DNS TXT records I find incredibly interesting.
One thing I thought was left out of the TrendMicro post is, why Polipo? Well the answer is extremely obvious to someone who has spent a significant amount of time developing PowerShell or even .Net code! The answer is, and I say this without seeing the code, they (the malware author) wanted to use the Net.WebClient object, which does not support SOCKS proxies. The author wanted to route the traffic via Tor, and needed Polipo to provide a HTTP proxy to route the WebClient traffic via Tor. How do I know this, well, I have deployed an extremely similar configuration for another project I was working on.
Once the malware has Tor and Polipo locally, it connects to the C&C server via the Tor network. The malware uploads a chunk of information to the C&C server, including:
- IP Address
- Country code
- Country name
- Region code
- Region name
- City
- Zipcode
- Latitude
- User account privilege
- OS version
- OS architecture
- Domain
- OS Language
- Microsoft Office applications
- Microsoft Office versions
Most of this are easily gathered with PowerShell, I pretty much included most of these in my presentation, if you remember:
An excerpt from my PowerShell Shenanigan’s code, found here.
Whilst I do not have all of the information there, it is extremely easy to extend what I had.
The malware seems to be a throw back from 90s, running off and infecting Word and Excel documents as a mechanism for propagation.
Whilst the use of PowerShell really did not seem to why TrendMicro thought it was blog worthy, they seemed to focus on the use of Tor; I think it is a wholly interesting piece of code.
I would love to look at the samples, as would Carlos Perez (@Carlos_Perez). I would love to see how well developed the PowerShell is! If anyone has seen the samples, please contact me!
WinRM in Workgroup Environments
Just a quick blog post this time, mainly focusing on some configuration items you “may” need to do if you are working with WinRM, in particular in workgroup environments. These are settings you may need to configure client side when trying to interact with servers. You probably saw these in the notes section of Get-WinRMPassword.
Firstly, how do you view your configuration?
winrm get winrm/config
Next, if you are connecting to systems where HTTP listeners have been configured on the server, if your running on a later Windows Client, you will need to allow for the connection to be made. By default “unencrypted” that is HTTP sessions will not be allowed.
winrm set winrm/config/service @{AllowUnencrypted="true"}
Now I recommend enabling basic auth, just incase.
winrm set winrm/config/client/auth @{Basic="true"}
Finally, the server a client connects to, actually needs to be listed in trusted hosts. This can be done like this:
winrm set winrm/config/client @{TrustedHosts="myserver"}
Note that the command above will clear any other trusted host entries you might have.
And that is pretty much all you need to do!
The easiest to understand guides are (in no particular order):
PowerShell + WinRM = Get-WinRMPassword
Hi All!
So I was working out what I will be putting in the paper based upon my PowerShell Shenanigans presentation from CrikeyCon, and started to ponder a few things around WinRM. In particular:
- How many machines have WinRM exposed to the public Internet?
- Out of these, are they exposing HTTP or HTTPS endpoints?
- Could this be an interesting remote dictionary/brute force attack?
- Could this be written in PowerShell for humour sake?
- Could we use this to breach a network and go from there?
- Has anyone else thought of this?
Let’s take a look at the answers to these questions.
Well the first two are pretty easy to answer. Turning to our good friend, Shaodan, we can put in some queries to get some rough estimates:
WinRM HTTP Hosts (TCP 5985) 185316
WinRM HTTPS Hosts (TCP 5986) 83840
Now we can’t easily assume that there is 269156 individual hosts out there, because we might have some duplicates (hosts listening on both HTTP and HTTPS) as well as some hosts with other services out there. There could also be older Windows Server systems listening on TCP 80 and 443. Either way, almost 300K is a pretty nice number to work with.
Now surely people really are not enabling HTTP? Well, I found this on some of my “out of the box” test systems. Interesting.
I think this would be an interesting attack method…
Could we make an attack tool and could it be made in PowerShell? It turns out, Microsoft has given us a significant amount code to perform this attack. As usual, let’s see if there is anything in PowerShell which looks like the basis for a brute force or dictionary based attack tool…test-wsman looks good!
Get-Help Test-WSMan: http://pastebin.com/uxKeEPHr
And we know how to read files and build PSCredential objects dynamically. So what would the CMDLet look like then?
CMDLet, Get-WinRMPassword: http://pastebin.com/RdygF0J6
And how would it work?
Examples: http://pastebin.com/pUhVazW3
So has anyone else done this? Yes, and some very smart people pointed out this as a possibility several years ago. TheLightCosine and Mubix (disclosure: I am a massive fan of Mubix’ work) talked about this very thing back in November 2012, and even wrote a MetaSploit module doing just this. And there were some very interesting discussions on Reddit about a year ago, and even a post on NetSPI.Com.
So some bright people pointed it out, and no one really seemed to pay much attention, this is a real shame.
So where to from here? Well, it is really hard to tell to be honest. WinRM has be around for a number of years (almost 10) and yet it isn’t something that has gained a huge amount of attention in the IT community, from an automation or security point-of-view. Brian Krebs wrote late last year on Windows RDP enabled servers to which access was for sale on underground forums. Attackers had gained access to these systems via poorly selected passwords and RDP connections exposed to the internet, whilst it certainly is easy to brute force passwords via RDP, WinRM makes it even easier, yet there doesn’t seem to be much of an appetite.
It could be that we simply do not know about it. It could be the case that a lot of these systems with WinRM exposed could have been taken over my malicious users and we simply don’t know about it. I really hope to see more people looking at why they are exposing WinRM to the internet, and if they have indeed been attacked via it. Perhaps now that we are shinning some light on it, we might really see what is hiding in the dark.
Risky Business: Featuring ME! Kieran Jacobsen
Patrick Gray interviewed me for Risky Business on Wednesday, and on Friday, the whole world got to hear the result. You can find the interview here.
Here is a brief description from the site:
On this week's show we have a look at PowerShell, the Microsoft sorta scripting language admin thingy. As it turns out, PowerShell can be an attacker's best friend when it comes to lateral movement through a network. We'll chat with Kieran Jacobson about that in this week's feature interview. He did a cracker presentation at CrikeyCon where he demo'd owning a domain controller and dumping all its creds with something like five lines of PowerShell. I mean, there are caveats there, but wow... the demotime was food for thought.
I am still working on Video/Paper, and have also been side tracked on another super awesome use of PowerShell + WinRM.
Thank you all for all of your feedback over the past week!