Okay, I admit, I haven’t been stressing enough to people just how critical the Slow HTTP vulnerability really is. The Slow HTTP flaw is present on practically every Apache-based system I test and can facilitate denial of service (DoS) conditions rendering even the most resilient web environments useless.
I’m finding more and more that documenting a potential DoS vulnerability in a web security assessment report often falls on deaf ears. The typical mindset around DoS testing and any subsequent flaws that are uncovered is “We haven’t had any trouble” and “We can’t afford to take down our production environment to confirm whether or not the issue really exists”. I can understand the business sensitivity, but the risk of taking down a production system in testing doesn’t make the vulnerability go away in reality. As many people have experienced, ignoring DoS-related weaknesses often ends poorly.
Well, recently I had the opportunity to test the Slow HTTP DoS vulnerability and demonstrate its consequences in a production environment for a group of people who didn’t believe it was a problem. The project sponsor at this organization was the information security manager who had been getting dinged because this finding kept cropping up on periodic vulnerability scans. The information security manager had the hutzpah (and budget) to hire a third party to demonstrate just what can happen when the Slow HTTP flaw is exploited.
It was a relatively short project. A quick scan using Acunetix Web Vulnerability Scanner (a check that was added to the scanner in late 2012) uncovered the vulnerability as shown in the following screenshot:
Once discovered, the Slow HTTP DoS is very simple to exploit using the Slowloris tool (a more feature-rich alternative is SlowHTTPTest). Simply download Slowloris, ensure you have Perl (such as the free ActivePerl Community Edition) running on your machine, and execute slowloris.pl pointing it to your web server using the following command:
perl slowloris.pl -dns ip_or_hostname_of_your_server
If Slowloris is running properly, you’ll see something similar to the following screenshot:
In this situation, the security operations and development teams struggled to find a simple fix given their Apache configuration. Eventually they found the magic formula and the Slow HTTP attack was no longer useful against the server. It was a worthwhile exercise for everyone involved.
A note to remember about the Slow HTTP vulnerability: I’ve found that Apache-based servers with the flaw also happen to take a long time to scan. It’s a very predictable correlation.
You certainly have to be careful performing denial of service testing in production environments so proceed with caution. The good thing about the Slow HTTP DoS vulnerability is that it doesn’t require a system reboot after exploitation. Executing Slowloris causes the HTTP service to hang only when the tool is being run against it. Stop the tool and the HTTP service should free up and the server will be back in business.
The bottom line is, when you see a DoS-related vulnerability make sure it’s pursued further. Let others help you make the decision on whether or not it’s critical to the business.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
