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:

1. Get list of CHARGEN systems
2. Import list into PowerShell
3. Run a separate PowerShell Job for each server, which:
   1. Runs RawSocketUDP.exe
   2. Sleeps
   3. 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.