My next class:

Apache HTTP DoS tool released

Published: 2009-06-18. Last Updated: 2009-06-18 13:06:45 UTC
by Bojan Zdrnja (Version: 1)
4 comment(s)

Yesterday an interesting HTTP DoS tool has been released. The tool performs a Denial of Service attack on Apache (and some other, see below) servers by exhausting available connections. While there are a lot of DoS tools available today, this one is particularly interesting because it holds the connection open while sending incomplete HTTP requests to the server.

In this case, the server will open the connection and wait for the complete header to be received. However, the client (the DoS tool) will not send it and will instead keep sending bogus header lines which will keep the connection allocated.
The initial part of the HTTP request is completely legitimate:

GET / HTTP/1.1\r\n
Host: host\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)\r\n
Content-Length: 42\r\n

After sending this the client waits for certain time – notice that it is missing one CRLF to finish the header which is otherwise completely legitimate. The bogus header line the tools sends is currently:

X-a: b\r\n

Which obviously doesn't mean anything to the server so it keeps waiting for the rest of the header to arrive. Of course, this all can be changed so if you plan to create IDS signatures keep that in mind.

According to the web site where the tool was posted, Apache 1.x and 2.x are affected as well as Squid, so the potential impact of this tool could be quite high considering that it doesn't need to send a lot of traffic to exhaust available connections on a server (meaning, even a user on a slower line could possibly attack a fast server). Good news for Microsoft users is that IIS 6.0 or 7.0 are not affected.

At the moment I'm not sure what can be done in Apache's configuration to prevent this attack – increasing MaxClients will just increase requirements for the attacker as well but will not protect the server completely. One of our readers, Tomasz Miklas said that he was able to prevent the attack by using a reverse proxy called Perlbal in front of an Apache server.

We'll keep an eye on this, of course, and will post future diaries or update this one depending on what's happening. It will be interesting to see how/if other web servers as well as load balancers are resistant to this attack.

--
Bojan
 

Keywords: apache dos
4 comment(s)
My next class:

Comments

Interesting to see if anyone has tried this with the FreeBSD accf_http kernel module. It has been around since Fbsd 4.0 and apache 1.3.22, but at a glance I find few (as in none) benchmarks of it.
Kernel buffers are still a limited resource, but apache should not see the connections until a full finished http header has been recieved.
accf_http would rather create more trouble (no mbufs) - as far as i remember the accf_htp code doesnt kill-for-reuse bogus connections. the accf framework may be used tho to create a custom handler for this type of problem. plus there is the POST problem
although the original article (written 2 years ago?) wasnt meant to be a bug/flaw report it still describes in detail the way one would drive a successfull attack on (probably most of the) web servers: http://pub.mud.ro/~cia/computing/apache-httpd-denial-of-service-example.html
There is also another layer-7 DoS tool named:
R-U-Dead-Yet
It uses the recent HTTP POST form field attack.
Read more and download at:

http://chaptersinwebsecurity.blogspot.com/2010/11/universal-http-dos-are-you-dead-yet.html

Diary Archives