Apache Killer works by sending partial content requests to Apache httpd. These requests cause the daemon to swap memory to the filesystem, and with enough requests, exhausts the server of its resources.

We did some testing for some of our customers and confirmed that it worked very well with little resources (3G connection was used during the testing to DoS a site).

We edited the exploit script and removed the DoS payload and then used it determine how many sites could be affected.  By running this across the Alexa Top 1000 sites for Australia we identified that 91 were possibly vulnerable. Similarly on the ASX 200 List 26 organisations were likely to be vulnerable.

To mitigate against this in one instance where no other controls were possible (As in a shared hosting environment) an IP tables rule was used to defend against it. However any firewall, WAF or IPS could be configured to prevent this attack.

To test your susceptibility to this attack you could run curl with the following to determine if Partial Content is supported on your Apache Site;

curl -H "Range:bytes=1-" -I http://target.com | grep Partial

A patch for adding support to turn off Partial Content was also found here with a quick google 

http://wejn.org/stuff/apache-partial-content-new.diff.html

Also someone else has posted this video of the DoS in action (albeit in a test environment)

http://www.youtube.com/watch?v=fkCQZaVjBhA

NB:All of the ones I tested used HTTP for the sign in process which was the default setting, Some offered HTTPS but as an additional link to click.

It's a pretty straight forward process;

1) Identify the correct domain 

2) List the cookies sent as part of the session (Normally the ones sent to you after you have authenticated)

3) Identify the section of the page in which the user name is displayed

4) modify the (identifyUser: function). For the sites I looked at it meant I had to change "this.userName   = resp.body.querySelector('changeme').innerHTML;

The changeme value above has to reference where the username value is. So for Whirlpool for example the page source snippet looks like this;

The username is referenced as the following within the script;  

this.userName = resp.body.querySelector('dl.userinfo span').innerHTML; 

One thing I did notice when running Firesheep was the number of third party connectors that sites were running. As these were linked from the news site I was viewing they automatically connected back over HTTP to the service.

In one example it had a bit.ly bookmark extension and a facebook connector. If you had an open session in another window or opted to keep yourself logged in by checking a box (which I guess many users might do) it would connect back and expose the session cookies and hence appear in Firesheep.

I don't condone illegal activity and have provided the above information for people to evaluate their own applications or the applications they legitimately have access to. 

The following firesheep scripts were written with help from RD (Thanks Mate).

Whirlpool Optus Seek

Recently HackLabs was interviewed on ABC Radio. Chris has posted a blog entry with some of the advice and information mentioned in the interview.

Small Business Security Advice

HackLabs is looking forward to 2010 and continuing to offer our clients high quality security services.

Cheers!

The program airs on Monday 17th August 8.30pm

http://www.abc.net.au/4corners/

QLD Police Conference Link

Thanks and we look forward to working with you in the future.