Ok, the other day I blogged about the new vulnerability discovered on OWASP regarding a HTTP DOS attack utilising the POST Content-Length and slow sending data.
Well I finally got a free couple of hours in my schedule so decided to create a very simple tool to test if this really worked. The tool itself can be found at https://github.com/xpn/HTTP-Post-DOS-Tool
. No permission is provided for this tool to be used for malicious purposes. I have intentionally given the User-Agent a obvious ID and any unauthorised use can be easily detected in logs with a simple grep of “XPN HTTP DOS Tester”. You have been warned !
By default it spawns 300 threads all which sends POST data to the HTTP server at a rate of 1 byte per 10 seconds. Almost instantaneously, my test HTTP server I had to hand (an Apache 2.2.13 box with no current traffic) froze with multiple error messages of:
[Thu Nov 25 00:23:57 2010] [info] server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers), spawning 8 children, there are 0 idle, and 250 total children
This confirms with reports on other blogs about the success of this attack. Once this tool was running I was unable to request any pages from the test HTTP server (via GET or POST).
One thing to bear in mind with this attack is that my test server was only configured for 256 simultaneous connections. Obviously sites will have a lot more than this configured (and multiple HTTP servers) which somewhat removes the realism of this test.
The concerning thing I found is that a single machine is quite easily capable of crippling a local HTTP server with ease meaning local Intranet HTTP servers are suddenly very easy prey for a malicious attacker.
Below is a video of this in action.
Today I came across a post over on acunetix.com about a new form of DOS attack against HTTP servers allowing POST requests. This vulnerability was discovered by OWASP and a link to the paper can be found at http://www.owasp.org/images/4/43/Layer_7_DDOS.pdf
This attack seems quite simple in that multiple connections are established with the HTTP server and a POST request is sent with a large Content-Length value. For example:
POST /fake_page HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1;)
If the POST data is then very slowly sent over a long period of time, the victim server blocks until either all of the data is received or the client closes the connection.
Now this attack is very much dependant on the amount of simultaneous connections a server is configured to accept. The vulnerability is that you can hold each connection open for a long period of time therefore disallowing any legitimate users from requesting pages.
For example, if you have a HTTP server which can accept 100 connections at any given time, after 100 connections simultaneously, the server will drop connections. Normally this wouldn’t be an issue as each user would spend a very short time requesting a page and then close the connection, or alternatively the server times out and closes the connection. This new vulnerability means that there is now a way to keep connections open (a ‘valid’ way due to the HTTP standard) which would allow use all of the available connections.
I will hopefully find some time this week to look into this further.