Slow HTTP Denial of Service: Analysis, exploitation and mitigation
Slow HTTP attacks are based on the fact that the HTTP protocol, by design, requires the server fully receive requests before processing them. If an HTTP request is not complete, or if the transfer rate is very low, the server keeps its resources busy waiting for the rest of the data. If the server keeps too many resources busy may be we can cause a denial of service in target host. Since we will be preventing another user from connecting or creating a session through the protocol.
In short, the attackers send legitimate HTTP request headers to a web server. In these headers, the message body sizes are specified correctly. However, the body of the message is sent at an extremely slow speed. These speeds can be as slow as one byte every two minutes, but not slow enough to time-out the client-server transmission and consequently cause the session to be closed.
Since the message is handled normally, the destination server will do its best to follow the rules, consequently the server will subsequently slow down considerably. When attackers launch hundreds or even thousands of Slow HTTP attacks at the same time, server resources are consumed in almost seconds, causing legitimate client connections unreachable.
These types of attacks are easy to execute because a single machine using minimal bandwidth can establish thousands of connections in a very short period of time (a maximum of 65539), generating thousands of unfinished HTTP requests.
The scary part is that these attacks can be difficult to differentiate from normal traffic. Since they do not require a large amount of resources at the application layer, they can be started from a single computer, which makes them very easy to start and difficult to mitigate. Traditional speed detection techniques will not stop such an attack. Perhaps one method is to update the availability of the server, the more connections available there are on the server (max_clients = worker_processes * worker_connections for nginx), the less likely an attack will overwhelm that server. Unfortunately, in many cases, the attacker will simply scale up the attack to try to overload as much capacity as possible.
These attacks may be like legitimate requests that are taking a long time, making it difficult to detect and prevent them using traditional anti-DoS tools. I leave you a note where through this attack the page of:
How it works
Analyzing HTTP GET request helps to better explain how and why a Slow HTTP DoS attack is possible.
A simple request looks like the following:
Something that is of particular interest is the [CRLF] in the GET request above. Carriage Return Line Feed (CRLF), is a non-printable character that is used to indicate the end of a line. Similar to text editors, an HTTP request would contain a [CRLF] at the end of a line to start a new line and two [CRLF] characters (that is, [CRLF] [CRLF]) to indicate a blank line.
HTTP protocol defines a blank line as the ending of a header. A Slow HTTP DoS attack takes advantage of this by not sending a trailing blank line to complete the header.
To make things worse, intrusion detection systems (IDS) do not typically detect a Slow HTTP DoS attack, as the attack does not contain malicious code requests. The HTTP request will appear legitimate to the IDS (Intrusion Detection System) and will pass it to the web server without perceiving the attack.
Exploitation
An important piece of information when it comes to fine-tuning the technique is to determine the maximum time that the connections are kept alive on the server (seconds), which will allow us to optimize our resources as attackers.
A Python script will do the job (Thanks jbeduino!):
In the first attempt, our window size is 75 seconds, the 8th debug message tells us that the connection was closed by the server, therefore that is not our value, we would be wasting 1 second as attackers to start another new connection. Therefore, we tested with 74 seconds and successfully the sessions were kept alive.
Based on these tests, our command will look like this:
slowhttptest -c 65539 -H -g -o report.csv -i 10 -r 200 -t GET -u https://targethost.com:443 -x 74 -p 3 -l 1800Explanation:
-c 65539 // Maximum number of simultaneous connections to launch
-H // SLOWLORIS MODE - SLOW HTTP
-g // Generate statistics in CSV and HTML formats
-o report.csv // Path and / or name of the custom output file, effective if -g is specified
-i 10 // Interval for sending information in seconds, per session, this means that when the HTTP session opens, it will wait 10 seconds to send information and so on.
-r 200 // connection ratio, launch 200 connections at a time, they are cumulative, in 5 seconds depending on the processing speed of the attacking server, we will have 1000 live connections.
-t GET // HTTP method to use in the attack
-u https://targethost.com:443 // Destination URL, the same format you type in the browser
-x 74 // Maximum duration of the session, value obtained from the first keep alive test
-p 3 // request probe, which is used to monitor if the server is responding normally during the attack, 3 seconds is established as the maximum waiting time, if it doesn't answer after the stipulated seconds, the server is considered DoSed.
-l 1800 // Specify the duration of the attack in seconds (in this case 30 minutes)
The Request Probe took more than 3 seconds to respond, so it is considered DoSed.
Therefore, we are going to visit the site to check that it is not working as the script indicates:
Indeed, we exhaust the server’s resources, therefore it stops accepting legitimate connections, so much so that the DNS service in which the host is registered indicates that the routing is going well, until it reaches the server and it produces an HTTP 522 error. The 522 code represents a connection time out that arises when verifying that the TCP connection is mutually agreed between the web server and DNS.
