UPDATE: Amit Klein pointed me to a post written by Adrian Ilarion Ciobanu written in early 2007 that perfectly describes this denial of service attack. It was also described in 2005 in the “Programming Model Attacks” section of Apache Security. So although there was no tool released at that time these two still technically deserves all the credit for this. I apologize for having missed these.
As you may recall at one point a few weeks back I talked about how denial of service can be used for hacking and not just yet another script kiddy tool. Well I wasn’t speaking totally hypothetically. A month ago, or so, I was pondering Jack Louis (RIP) and Robert E Lee’s Sockstress, and I got the feeling that other unrelated low bandwidth attacks were possible. Then I randomly started thinking about the way Apache works and figured out that it may be possible to create something similar to a SYN flood, but in HTTP.
Slowloris was born. It basically uses a concept of keeping an HTTP session alive indefinitely (or as long as possible) and repeating that process a few hundred times. So in my testing, against an unprotected and lone Apache server, you can expect to be able to take it offline in a few thousand packets or less on average, and then you can let the server come back again as soon as you kill the process. It also has some stealth features, including a method of bypassing HTTPReady protection. Why is this noteworthy?
Typical flooding attacks require tons and tons of packets and end up denying service to other applications as a result. By creating a flood of TCP requests, sure you can take down an upstream router, or a web server, but it’s overkill if you really just want to take down a single website. Slowloris does this without sending an overabundance of TCP or HTTP traffic, and it does so without increasing the load significantly, or in any other way hurting the box (assuming other things aren’t tied to the HTTP processes - like a database for instance). This appears to only affect certain types of webservers (generally those that thread processes, like Apache, but not like IIS).
So I contacted Apache a week ago, because I was a little concerned that I hadn’t heard much about this, other than one conversation with HD Moore about a similar attack he encountered using a different payload. I expected a well thought through response, given their dominance in the server market and the fact that I gave them an early copy of the code. Alas:
DoS attacks by tying up TCP connections are expected. Please see:
[httpd.apache.org]
Regards, Joe
Yes, that was the entire response. So, while RTFM is a perfectly valid response on the Internet, it’s also extremely short sighted, because almost no servers are configured properly - or if they are, it’s as a side effect of needing load balancing or something upstream that happens to protect them. Also, if you actually read that Apache.org page, it really doesn’t cover this attack at all. And Joe sorta totally missed the boat or at least mis-typed in his brevity, because this isn’t a TCP DoS, it’s an HTTP DoS. If your server used UDP and I re-wrote Slowloris to speak UDP it would work too. The best example of how this differs from a TCP DoS is the fact that other unrelated services are unaffected, and you can still connect to them like you normally would.
The reason this works is because the web server will patiently wait well beyond what is reasonable, allowing an attacker to consume all of the available threads of which there are a finite amount. That makes it a web server problem, not a OS or networking problem, although there may be OS or network solutions to Apache’s default configuration issues. This is further evidenced by the fact that IIS isn’t vulnerable to Slowloris in it’s current incarnation. Even if Apache and IIS are on the same physical box, Apache will be affected but IIS will not. That would lead me to believe it’s a architectural flaw in Apache’s default web server’s design. Though this isn’t just Apache’s problem, to be fair. Other web servers are vulnerable as well, although none come close to the size of Apache in terms of market share. You can find more information on the Slowloris page.
Anyway, I hope this gets people thinking about better web server architecture. That’s especially true if this is “expected” behavior of their web server, and at least offer a default configuration that can protect from this sort of attack, instead of having to jump through a bunch of convoluted hoops. I thought it would be better to open this up for discussion, so I encourage you to try out the tool in QA or staging and see how your web server handles it. The software is very beta though, so do not use this against anything in production - I make no warranties about its ability to do anything outside of a lab environment!
