Layer 7 Attacks
In this post I’ll cover three types of Layer 7 attacks; the HTTP GET method, HTTP POST method (a la “RUDY”), and the fragmentation method used by tools like SLOWLORIS. There are other ways to cause DoS conditions at this layer, but I’ll save those for another day because they have to do with a few other methods of web-based exploitation.
The other thing I want to mention about these types of attacks is that they typically don’t require the huge amount of machines or overhead that you would need with the attack styles we’ve previously discussed. In the previous post you can see how having an army of machines would be helpful to you when flooding a server or network with junk packets; but in this case, a single attacker can get his intended effects on the target with significantly less devices and resources at his disposal.
HTTP GET Floods
The GET flood works in a very similar manner to the SYN flood that we covered in the last post, with a slight exception. In this case, the Three-way Handshake at Layer 4 (TCP) is completed; so now this traffic looks much more legitimate than just junk packets being hurled at the system. At the surface level it much more appears to be a legitimate user, which brings us to the next step: REQUEST ALL THE THINGS!
Imagine I’m targeting a specific website, and on that website the admin used a large photo or file somewhere. The idea with this attack is that I’m going to connect and then request that large file….thousands of times. Again, and again, and again, until I exhaust all the servers resources with these requests. So you can see the similarities between this and something like a SYN flood; this just takes the attack a few steps further up the OSI model in order to bypass those Layer 4 protections.
HTTP POST Attack
This method was popularized by a script called “R-U-Dead-Yet?” aka “RUDY”.
The attack involves web-based forms on a website. Imagine a comment field or something; when we want to submit data through that form and back to the website then we would be using the POST method to do that.
Like I’ve said before, that’s fine and dandy when everyone plays by the rules. But instead of being a responsible user and just submitting the data we want in a reasonable way, what happens if we were to drag that process out as long as possible? Enter RUDY.
RUDY performs its attack by dragging out the POST process as long as possible by sending a legitimate POST request with an abnormally long ‘Content-Length‘ header field, after which it starts injecting that form with data one-byte at a time. Here is a quick snippet from the RUDY source code that demonstrates what the ‘Content-Length‘ field looks like in the actual POST request.
As RUDY sends lots of very small packets at such a slow rate (can be ~10 seconds between each byte), it creates a massive backlog of application threads handling it all. On top of that, with such a large ‘Content Length‘ set, it prevents the server from closing the connections.
Servers only have so many connections they can support at any given time. So with RUDY both opening connections AND keeping them open for as long as possible, it quickly consumes every available connection and brings down the server for everyone else. Also as old connections time out or eventually drop, RUDY will just spawn a new connection and keep that next one open for as long as possible. The vicious cycle will just continue.
This attack is a little more sneaky and can go under the “Low and Slow” classification since it’s not hammering a server with crazy amounts of volume like you’d see in a DDoS attack. Defending against this technique also requires paying close attention to server resources since you won’t be seeing crazy amounts of traffic being hurled your way, so it takes a bit more digging.
SLOWLORIS and the Fragmentation Method
The fragmentation method is similar in nature to what we just discussed, however it does its job in a slightly different way.
SLOWLORIS works by consuming all available connections to a server, but instead of holding them open the way RUDY does, it does so by sending incomplete requests. The server sees the incomplete request and assumes that something happened during the request that resulted in it being incomplete. So being the good server it is, it will keep the connection open in hopes that the connecting host will finally send the complete and proper request. We abuse this function until we’re taking and holding every available connection the server has.
I also want to touch on the server side of things of why this attack works so well. Most servers make use of a ‘timeout’ function to kill off incomplete HTTP requests. This is a useful function because if something happens to that connection then there needs to be a way to prune it off in order to make room for the next client to connect. By default, most servers will wait something like 300 seconds before it kills the connection. This counter resets itself when it finally starts to receive some data. So the idea behind this attack is to abuse that function by sending incomplete packets at very long intervals (hence the name Slow Loris). It keeps resetting that counter by trickling in tiny bits of data while also waiting long amounts of time between when it’s sending that data. If you can keep this process going, then eventually it will use all the available connections, keep them open indefinitely, and effectively down the site.
Using this technique a single attacker can down a site with very little resources, time, or effort. Yay!
Hopefully this gave you a basic idea of how some of these attacks work and what’s going on behind the scenes a little. DoS/DDoS attacks are constantly changing so by no means is this an exhaustive guide to every possibility. But what I hope you got from it is understanding the idea of taking a protocol or process, looking at what should be happening, and twisting that in order to abuse it for malicious purposes.
If none of that made any sense though, there’s always the good ‘ol Layer 1 attack!