HTTP Gets a New Form Of Attack (Part 2)

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 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.

HTTP gets a new form of attack

Today I came across a post over on 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

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
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1;)
Keep-Alive: 900
Content-Length: 10000000
Content-Type: application/x-www-form-urlencoded

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.

BlackSheep plugin to detect FireSheep users

Following on from my previous post, another plugin has been released to combat the FireSheep plugin… cleverly named BlackSheep.
Unlike the FireShepherd standalone program, Blacksheep is also a firefox plugin that sends out a fake session ID’s onto the network. BlackSheep then monitors the network for anyone else using the fake session ID. As the session ID is fake, anyone else using the ID mush running instance of FireSheep (or another session capturing tool).
BlackSheep can be downloaded from
This is a much better way of protecting yourself against the FireSheep epidemic as it doesn’t rely on a false sense of security like FireShepherd. Unfortunately the actual vulnerability is within the Web 2.0 websites that use non-ssl encrypted sessions to exchange session cookies. Whereas FireShepherd just used a DOS attack on the FireSheep plugin (with no guarantee that the user hasn’t modified FireSheep to protect against this), BlackSheep tells the user of any active active FireSheep users on the network.

Herding FireSheep with FireShepherd

FireShepherd offers a temporary solution to the current threat of people sniffing Web 2.0 cookies with the FireSheep plugin.

The description of FireShepherd provided by the author is:
“FireShepherd, a small console program that floods the nearby wireless network with packets designed to turn off FireSheep, effectively shutting down nearby FireSheep programs every 0.5 sec or so, making you and the people around you secure from most people using FireSheep.”
The sourcecode for this little utility is very simple and can be downloaded here:
It works by preparing a HTTP GET packet:

GET /packetSniffingKillsKittens HTTP/1.1
User-Agent: Mozilla
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: is,en;q=0.7,en-us;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: lsd=spsse; c_user=666660000; sct=01010101; sid=0; xs=3randomhashyes666666666; asdf=??????????????!!!!!!!!!!!!!!!!!!!![MALFORMED_DATA]

This packet is sent onto the network to be sniffed by FireSheep. By providing a malformed cookie to be captured, the current version of FireSheep causes an error and ceases sniffing.
This by no means provides a perminent fix to the current issue of session-hijacking, but provides a DOS attack until a workaround (or another version of FireSheep) is released.

Google Promotes Responsible Disclosure With A Cash Incentive

Today I came across a post on the Google Security Blog that Google are offering cash for any vulnerabilities discovered within their security applications. This includes the full range of Google applications (, and also their sister sites (,
This is a fantastic way to promote computer security in a responsible manner and I guess saves Google a ton in revenue.
Imagine you’re a black-hat who has just found some small XSS vulnerability in a Google application. You could go through the time of phishing, and social engineering your way to a few accounts, but who not instead cash in on the vulnerability to make some money legally.
The Pro for Google: A disclosed vulnerability that can be fixed without media attention.
The Pro to the black-hat: CASH !
I am happy that this is the method that Google has taken as it also introduces new starters in the security field to the concept of responsible disclosure.
Maybe this is something that the likes of Twitter should be doing?