DoS 101: The Ping of Death

You are probably familiar with DoS attacks (Denial of Service). They're all over the news. They may have even affected popular services you've used. DDoS and DoS attacks are very disruptive and typically serve no other purpose other than bringing sites and services off the network. They've been known to bring entire corporations to their knees in a PR sense (for a short time), like Sony and Paypal. They cost these larger corporations millions of dollars in lost revenue and damages. The average cost of a DDoS or DoS attack is $40,000 per hour. In some of the biggest corporations I've worked in, we've estimated the cost in the 6 digits per minute range, depending on what network were to be hit. If you hit a billing or charging platform for an $80 billion a year company, that will cause some serious financial damage. The best strategy to mitigating DoS and DDoS attacks is to understand them (and to call Prolexic/Level3 or whatever other upstream you're using, heh).

DoS vs. DDoS:

I see this one mixed up a lot on everywhere from news articles to forums. A Denial of Service (DoS) is typically run from a single source to attack a specific target. A Distributed Denial of Service (DDoS) is run from many systems to attack a specific target. It can be explained by throwing those foldable steel chairs:

Figure 1: Santa experiencing a DoS attack.

Figure 2: A Wrestler experiencing a DDoS attack. 

Ping of Death; The Old School Cool.

The Ping of Death is hardly a new attack. In fact, it's probably the oldest trick in the book: You ping the crap out of someone with an over-sized IPv4 packet until their interface or the system itself crashes and is no longer reachable. Back in the days of limited bandwidth and large botnets, ping of death and smurfs were serious attacks. The Ping of Death would not flood a victim with so much traffic it couldn't cope, like the smurf attack. The crash condition is mitigated now, but ping floods by sending large amounts of over-sized pings can still be a threat to an unwary victim - like someone hosting a small ventrilo or web server. Understanding this Denial of Service attack will help you understand the core concepts behind them when we move onto more modern attacks.   

PING...PONG...

Below is our PoD.py code:

Running this from one VM to another is a ton of fun to watch your wireshark go berserk with the sheer raw amount of seemingly random traffic you'll get hit with. 

***Note, to run this (at least on Ubuntu) you need be root (sudo su), then run python PoD.py.***

Let's take a look at a sample attack from my Ubuntu VM at 10.0.2.5 to my Kali VM at 10.0.2.15:

Figure 3: En garde! We start flooding 10.0.2.15 with a bunch of traffic

Figure 4: Our server at 10.0.2.15 starts eating a ton of ICMP traffic. Oh noes! It's a DDoS... Or is it?

It appears we are receiving a DDoS attack. But if you look closely at the Ethernet II headers... the originating MAC address is the same. So this isn't a DDoS at all! It appears only a single host is attacking us but spoofing their address. That is because we are on the same subnet. ICMP works like this: 

Figure 5: Anatomy of a PING.

When you send an ICMP echo request, you first send an ARP request. When a host first tries to connect to another host on the same subnet, it will send an ARP request, and cache that response. If you have wireshark running before you launch your ping of death attack, you will see this request. Once that is cached, all the ICMP Echo Replies will be sent back to that MAC - Even if we aren't actually at that IP.  

You can verify this by looking at the Rx/Tx on the attacking machine and comparing it to our server:

Figure 6: Our server at 10.0.2.15 is under attack. We can see a nearly equal amount of incoming and outgoing traffic.

Figure 7: After 39 seconds of attack our server was hit with about 56 mb of traffic. 

Figure 8: Our client at 10.0.2.5 is recieving ICMP echo replies because we are on the same subnet.

Figure 9: Our client both sent and received about an equal amount of data. Not good to DoS ourself too.

So how could this be avoided? Well generally you don't attack things on the same subnet. But a simple fix would be to create a mac_spoofer() function in our code, and build the Ethernet header too, with random MACs. However, over a WAN this is not needed. When we send the traffic over a WAN the replies won't go to us... They'd go to the address you spoofed.

Figure 10: You can see we are only sending traffic, not receiving. I slowed down my interface so I'd send a small amount of traffic. 

This brings up an important topic now: amplification. It wouldn't do us any good to attack ourselves with a flood of traffic now, would it? We also don't want to send the same amount of traffic as our target receives. If we sent out 700kbps of traffic, about what the PoD.py script can send out on my VMs, we also don't want to waste our precious bandwidth and the target to recieve just 700kbps of traffic. We would just be arm wrestling their connection, and whoever had more bandwidth would win. Chances are, most websites have a bigger connection that what is cheaply available commercially. We also want the target to eat more bandwidth than we are sending, so we need a way to amplify our traffic. We could try sending from multiple machines, but that would be similar to just multi-threading the problem. We need ways to send large traffic by using small traffic. 

Pings and Amplification: The SMURF Attack

Notice how in our first example, our server was readily sending ICMP echo replies back to what it thought it was the sender? We can leverage this to achieve our amplification in the smurf attack. Our attacking machine just hast to send a ping packet with a spoofed source address to that of the victim. Our receiving machine gets this request and sends the reply to another remote machine. When dealing with Denial of Service attacks, you have to consider more than just download speeds, you also have to consider upload speeds. Usually your pipe only has so much bandwidth. Back in 1995~1997 when these attacks were serious business, your typical pipe for a server was measured in kbps. Additionally, trying to parse a massive (for the time) 60,000 byte packet would sometimes cause a buffer overflow condition and the server to crash. Yikes! These days the PoD and Smurf attacks are just a comically cute attack on most corporate infrastructure thanks to advances in network speeds and security controls. 

That being said, it's still possible to take down low powered hardware (RaspPI) or low bandwidth systems trivially with a flood of large ping packets.  

To amplify our target, we can either spoof our address, and let them just receive and relay large 60,000 byte IPv4 packets back to another target (which only amplifies by a really lame amount), or we can leverage the broadcast address. Thus we are brought to the smurf attack. In the timeline of Denial of Service attacks, we are around 1998/1999.  

Figure 11: A SMURF Attack

You send an ICMP Echo Request (1), with the source address spoofed to that of your target, to the broadcast address of several routers (2). The systems behind those routers all send their ICMP Echo Replies to that of your target (3), since you spoofed the address in step 1. 

We tweak our PoD.py code just a bit and we can perform a Smurf attack.

Figure 12: Pinging the broadcast address causes the Echo request to hit everything on the subnet (both our Kali and Ubuntu VM)

Figure 13: Running our smurf attack from our Virtual Lab Network.

Notice how we received the ICMP Echo requests but never sent any replies? This is because the virtual interface for Virtual Box has ip-directed broadcast disabled. As a matter of fact, nearly every router has this disabled by default now. The smurf attack was such a problem in the late 1990s, the industry all but eradicated it. If ip-directed broadcast were enabled, we'd be sending echo replies straight back to our target.  

What to take away

Denial of Service attacks are one of the most feared type of cyberattacks by businesses today - even though there are far worse attacks. They cost tons of money, you often have no idea who is performing one, and often the attackers want no demands or results other than to see you go down. They don't want your customer data, intellectual property or your money. Business tends to fear that kind of logic, and that's exactly why DDoS is the weapon-of-choice for hacktivist groups.  

Moving forward I will like to demonstrate some more modern Denial of Service attacks that achieve HUGE amplification: The now antiquated DNS Amplification and the newer NTP Reflection. Stay tuned!