Slowloris, a new type of "HTTP flooding" attack
Date : July 06, 2009
The tool can perform denial of service attacks on vulnerable servers in a very little amount of time, but also without requiring skills or knowledge in network or security. That is why we thought useful to inform our community about the existence of such a tool. Despite the lack of report for massive exploitation of this vulnerability, we published the VulnCoord-2009-008 message called "SlowLoris web DOS tool".
Slowloris in few words?
Slowloris is a "DOS" attack tool. Its goal is to make a vulnerable web or WAF server unreachable. To do this, it tries to exhaust available connections (sockets) on the target server. However, Slowloris is not a "TCP DOS" traditional attack, which is to flood a server consuming all the TCP sockets that can be opened.
The idea is not new, if one remembers the “SYN Flood” attacks, which keeps the TCP connections opened until the target is saturated and cannot deliver any network activity.
The technique used here is the same, except that it focuses on HTTP connections and not on TCP connections. It is to maintain HTTP connections to the target server in a “connected” state as long as possible, and repeat the connection requests in order to soak the server, preventing any new connection.
From a technical point of view
Unlike a ”TCP DOS” attack, the TCP connections of Slowloris will be established normally (the well known "3-way handshake"). They are not left in a “half-open” state and are therefore fully established (SYN -> SYN-ACK -> ACK). On the other hand, HTTP sessions are maintained in the “open” state in order to make the vulnerable server unable to allow anymore connection. Therefore this shows a kind of similarity between the two attacks.
To maintain the connections opened, rather than sending random data to the target server (as many tools do), Slowloris sends queries to the server with incomplete HTTP headers (GET commands…). This makes the target server to wait indefinitely for the arrival of the end of the pending header. Then Slowloris maintains the opened connections by sending the server partial headers with bad data.
Repeating these connection requests and keeping them active as long as possible, Slowloris overloads the server which reaches its connection limitation quickly, causing the denial of service.
Slowloris Why is it different from others?
As we said earlier, there is nothing new in this vulnerability exploitation, since in 2007 a SecurityFocus article ("a cheesy Apache / IIS DoS vuln") already described the feasibility of this attack, but without providing any demonstration tool (PoC) at that time.
However, although there are many DOS tools, Slowloris has the particularity of not requiring a very high network bandwidth. This was not the case of already known tools, which in "flooding" attacks generally require sending a large number of IP packets (often several thousand) to cause the denial of service.
Slowloris, only requires the sending of hundreds of HTTP requests to the server, thus preserving network bandwidth. This makes possible attacks from low bandwidth connections.
Moreover, it allows a targeted denial of service; that is to say to the web service only. Indeed, contrary to what a classic "TCP DOS" attack allows, which causes a denial of service on a vulnerable system (no more network connectivity), Slowloris only exhausts the targeted web server. Other hosted services on the machine, continue to operate. This is often what an attacker wants, in order to pursue its malicious activity.
Slowloris can also change the data in the headers it sends to the server. This technique can be seen as a way to hide. It makes it more difficult to filter or to analyse traces.
It may also be stealthier than others because of the way the logging system of an Apache server works. Indeed, the logging of events by an Apache server only occurs when closing HTTP sessions. By keeping them opened, the Apache log files will be written only when Slowloris stops its job. Therefore, as the tool works, events and errors connection (Error 404) will not be immediately transmitted to the system logger. This allows a kind of camouflage of the denial of service.
How do we protect?
It is often difficult to give advice or recommendations to address implementation vulnerabilities. Indeed, beyond the fact that these flaws are often affecting multiple vendors, patches or workarounds may not apply equally.
Although the vulnerability exploited by Slowloris seems to affect only the web servers using processes based on "Thread" as Apache, Squid and others (IIS does not seem to be affected). It is clear that this new attack poses many problems.
Many questions arise; "Does a load balancing solution protect a vulnerable server?", "Are my filtering routers or firewalls able to block the Slowloris attack?", "Does my WAF solution protect me?". It is indeed legitimate to ask all these questions.
Unfortunately, there are no answers. The difficulty is inherent in the way the attack occurs. From a TCP point of view, the attack is legitimately "orchestrated". Indeed, the TCP connection establishments are legitimate. The HTTP headers are also legitimate (initially at least). Therefore this makes any filtering difficult since everything seems legitimate. The only "abnormal thing" here is the HTTP connection elapsed time. In most cases, the HTTP sessions to a server are for a short period of time. Reduce the opening time of the sessions could maybe reduce the effects of the attack but it could also have side effects on vulnerable servers used to transfer large amounts of data (e.g. file transfers).
One way to mitigate is to alter the "Timeout" parameter for HTTP sessions, as pointed out in this article from the SANS Institute. For Apache, it would be to change the "Timeout" variable (300s by default) as advised by the security page from Apache. However, be aware that this may have side effects for people with low bandwidth connections, for web applications which need to transfer high volume of data and which might require a high "Timeout" value. This parameter must be chosen knowingly.
Another solution is to act on the number of allowed connections per IP address on the vulnerable server. The advantage of this solution is also its main defect. It implicitly limit the traffic through proxy servers or make any "reverse proxy" useless.
Another low-cost solution is to increase the number of connections allowed on the server. However this technique is likely to remain a vain attempt as Slowloris will permanently try to consume all the allowed connections.
Another solution is to use a non-vulnerable "reverse proxy" in front of a vulnerable server. In the present state of vulnerable systems, it would probably be to set up a Microsoft server (e.g. ISA server) to protect an Apache server. This might lend to smile. There is also a solution which is to install the free relay and "load balancer" called "Haproxy" which has a specific configuration providing protection against Slowloris.
A final solution could come from the IPS, if one can identify signatures allowing HTTP stream inspection (to detect exchanged headers maintaining HTTP sessions opened). For the moment, unfortunately, these signatures do not exist. Other alternatives or at least “home-made” solutions appeared with script files that would periodically check the state of HTTP sessions with a too long uptime. However, it is necessary to develop such solutions being aware of the use of the web server traffic, including web applications, before cutting sessions which might be legitimate.
Meanwhile, the vulnerability has not been corrected yet. We follow it with the FA-2009.0112 reference in the “flaws under investigation” section of our web site.
