Bringing DDoS Emulation into the Lab
At ATI Research Center, we are asked to provide real-world emulation of Internet traffic at scale. Both the good, the bad, and the ugly. Part of this job for Lalithya Divi and me is recreating distributed denial of service (DDoS) attacks in a controlled environment. This enables us to qualify the attacks, figure out how they work, and sometimes make them even more effective. A lot of recent DDoS attacks have included DNS Reflection, Slowpost, and NTP MONLIST Response flooding.
Lalithya did a great job explaining how we implement Torshammer in BreakingPoint the other week. But what we didn't discuss at that time is how you can configure a vulnerable server, and send the attack yourself within a closed environment. This is great for qualifying the attack, verifying it works, and a step we perform before we implement anything in BreakingPoint for you to test with.
Slowpost/Pyloris/Torshammer and other similar attacks all take advantage of the HTTP protocol specification, which in the simplest form looks like this for a REQUEST:
One of the most common requests you've probably seen is the POST request, formatted accordingly.
Slowpost and its cousins abuse this protocol exchange by dribbling in the bytes from the POST sent to the server. So instead of the request in this case taking up one, or maybe at most two, packets, it would instead take up seventeen or more packets, dribbled-in slowly over time like this:
Creating your vulnerable webserver
First you'll need to setup a vulnerable server. The easiest way to achieve this these days is to deploy a virtual machine with Ubuntu or a similarly popular Linux distribution. Once you have Ubuntu installed and setup, make sure you install apache2 with apt-get and have it running:
Downloading your PoC Code
Next up you'll want to download torshammer. The current copy that you can use is hosted at the following github account. But we strongly urge you to exercise caution whenever examining or using PoC code. If you are unsure of what it does, do not run it. Many times you'll find boobytrapped PoC code advertising one thing, but mostly just running rm -rf / across your machine.
When you examine torshammer.py, you'll find it supports both tunneling through the tor network or direct abuse of a server:
Today, we're going to use it directly on our new server and take it down. The easiest way to test if a DDoS attack is working is to poll the service while launching the attack. This doesn't always work in every instance, but this time it is a good fit. The quickest way is with a web browser, but this can be problematic as it is difficult to get solid feedback from the browser when a connection is failing. I prefer to use a quick curl script, like the following:
This will print output once a second, confirming if the site is still up, and report back how long it takes to get the webpage retrieved. If we combine that with our attack, we can see confirmation that the DoS attack is working.
The next steps are to download packet captures of the attack in place, create new Superflows and test scenarios like you saw earlier, and make sure that the behavior of our attack mirrors that of the live PoC. With one important difference: We aim to cause mayhem. So any field or element that can be modified but not change the nature of the attack will be qualified and changed. This makes life more difficult for the defenders by challenging them to write better signatures and algorithms to detect not just this attack, but any variation on it.
Recreating a DDoS NTP Amplification Attack
An NTP amplification attack is performed by constantly sending a "GET MONLIST" command to the NTP server with a spoofed source address of that of the victim's. The reason to use the MONLIST command is that the server returns up to the last 600 IP addresses that last accessed the NTP server as a response to the MONLIST request. Let us illustrate how easy it is to recreate this attack. After some quick research on the Internet, we have found a great tutorial on how to create this attack. All we need are two Linux virtual machines where one of them is configured to be an NTP server and the other to be an attacker.
Configuring the NTP server and making it vulnerable:
Just like all the dangerous NTP vulnerable servers out there, we deliberately misconfigure the NTP sever:
Add # and comment out the highlighted lines. This would enable the attacker to configure the server as well and restart the ntp server once again.
Populating the NTP server
Once we have made the NTP server vulnerable, the next task is to populate it with as many entries as possible. This step helps us increase the amplification factor. As explained in the turtorial, bit-twist was used for sending 600 NTP updates with spoofed source IP addresses. After populating the NTP server, a MONLIST request sent to this server returns a response with all the false addresses that were used to update the NTP server.
In this example, we get an amplification factor of 18.75. Using extrapolation, that implies that with 1Gbps of requests can generate 20Gbps of responses. Once the response received is sufficiently large enough, the same GETMONLIST can be sent to the NTP server with the source IP address modified to be the victim's IP address.
Observing the attack from the victim's perspective, we would see a huge MONLIST response directed to their IP address. This has been implemented in BreakingPoint as seen below.
In this case, our "Client" is the Reflector and the "Server" is the Victim. The MONLIST response is directed from the client to the server. It is even more simplified with the GOTO action in the Superflow. All we do is have one MONLIST response and repeat the iteration desired a number of times to achieve the desired amplification. This way, a DDoS NTP Amplification attack can be configured using BreakingPoint.
Leverage Subscription Service to Stay Ahead of Attacks
The Ixia BreakingPoint Application and Threat Intelligence (ATI) Subscription provides bi-weekly updates of the latest application protocols and attacks for use with Ixia platforms.