Menu
We don’t get many Lorises (or Lemurs for that matter) in the AppCheck offices – probably something to with the climate – so we don’t know much about them, other than that with a top speed of 1.2 miles per hour going flat out, you’d probably not be backing one in a race against anything much other than their even-tardier distant cousins, the two-toed sloth.
But since we’re in the vulnerability-scanning game here at AppCheck, we’re going to take a look at the web application vulnerability that is the namesake of this insectivorous tropical quadruped.
Denial-of-service (DoS) attacks are used by malicious attackers to attempt to deny access to legitimate users of a website or other Internet service, by causing the service to become unresponsive or to crash. They typically perform this through the use of attacks that cause exhaustion of resources that have been assigned in some finite capacity on the service, such as network bandwidth, memory or CPU (processing) capabilities. The most basic attacks are performed by techniques including flooding that essentially use brute force to have slaved client hosts send large numbers of network packets to the service in a volume greater than it can process in a given timescale. This requires large amounts of resources by the attacker, and typically is described as a Distributed Denial of Service attack, making use of compromised victim clients that together form a botnet.
Denial of Service attacks are a major problem for service operators and organisations since no specific vulnerability needs to be in place in order for an attacker to launch a distributed brute force attack. A well-organised attacker may take a victim offline in a demonstration of force, and then contact the organisation demanding a ransom (typically paid in untraceable form such as Bitcoins) to not continue with further attacks.
However DDoS attacks are detectable by IDS and can be mitigated more easily than in the past using CDN proxy mitigation to block them close to their origin. It is almost relatively easily for mitigation efforts to block volumetric sources either reactively or proactively based on request volume, and compromised botnets can be “burned up” in such attacks in that once the host is identified as malicious and blocked it may be of little further use to an attacker, who is then de-fanged until they can compromise further victim clients to enrol in future attacks.
More sophisticated Denial of Service attacks may exploit the ability to make fewer (but still-significant) numbers of requests to a service, but using some form of amplification attack, typically exploiting a weakness at the application rather than network layer. This permits an attacker order to ensure that each request is significantly more expensive for the server to service than it is for the client to request. For example, an attacker may locate a URL that accepts parameters in a query that is computationally expensive for the service to calculate and return data for, such as a report generation service that permits custom date ranges. The parameters from the front end are used in SQL queries to fetch and calculate transformations on large volumes of data. By varying the parameters submitted continuously, an attacker may submit a large number of requests which each consume huge amounts of CPU until the server becomes overloaded and stops accepting new requests.
However, attacks such as the above require locating a vulnerable endpoint that can be accessed on the server and so are specific to individual organisations. They can also be thwarted by simply removing routing to the vulnerable URL once an attack starts.
SlowLoris is an application-layer denial of service attack that doesn’t rely on volumetric transmission of packets (and so is more difficult to detect and mitigate), but equally doesn’t reply on application- or organisation-specific vulnerabilities, so can be targeted against a broad spread of websites. This combination of amplification-like behaviour (not purely reliant on brute force) with widespread vulnerability to the attack among websites makes it popular among attackers. It is an interesting variant that exploits a design approach of many web servers, allowing a single machine to take down another machine’s vulnerable web server with minimal bandwidth. It makes use of HTTP GET requests to occupy all available HTTP connections permitted by a web server. It does this by taking advantage of a vulnerability in thread-based web servers, which wait for entire HTTP headers to be received before releasing the open connection. How exactly does this work?
Essentially, by exploiting the behaviour of some HTTP webserver software, a malicious user can open many connections to a vulnerable server by initiating HTTP requests, but not closing them. A webserver will typically close connections that are left open in this way, after a timeout is reached. However in a SlowLoris attack, the attacker is able to exploit server behaviour in that the connection timeout is not total for the entire request, but is reset or extended each time any data – no matter how small – is received.
By keeping every HTTP request open by “teasing” the server with tiny dribbles of data that are delivered in individual packets just before timeouts are reached, the HTTP connection will remain open, constantly extending the timeout but making no progress towards resolving the request. If an attacker occupies all available HTTP connections for a web server and keeps them busy waiting, legitimate connections cannot be processed by the server and this causes a denial of service to legitimate users, who are unable to get a response from the server to their requests.
The method used to prevent the target server from timing out the connections is for the attacker to send partial request headers to the target in order to keep the request alive – in essence saying, “I’m still here! I’m just slow, please wait for me!”. There is no way that the receiving server can know how many HTTP request headers a client may be sending, so it has to simply keep waiting. Since it cannot timeout, the connection would only be freed up if the total request size eventually exceeded the total permissible limit – this is typically 8192 bytes (8 KB) for GET requests, but can be up to up to around 2 GB for POST requests.
The default next-packet timeout during an HTTP request is often configured to be several minutes, or least several seconds long, to account for network delays. This means that a SlowLoris attack tool can keep one connection tied up for up for some time – measurements in one experiment indicate that a vulnerable Apache webserver with a timeout configuration of 5 seconds requires a bandwidth of only around ~45 kb/sec – minimal – to perform a Denial of Service attack on a similarly-specified target host. This means that even a single typical home-user computer with a 10mb internet connection may have sufficient bandwidth to take a major site offline using a SlowLoris attack within just a few minutes.
So how exactly does this attack work and why? We’ll dig into the underlying technical implementation to understand what mechanisms are being exploited here and how the attack can be mitigated.
In addition to alphanumeric characters, computer files and command sequences used in network communication protocols can contain special characters to signify specific actions. Two such characters that are relevant here are the “The Carriage Return (“<CR>”) character (0x0D, r) and the “Line Feed” (“<LF>”) character (0x0A, n). The names survive from an earlier era referring to the mechanism or lever on a mechanical typewriter in which type element were fixed and the paper pulled through the typewriter vertically and laterally in a moving carriage as needed- and the names still make sense in this context. “Carriage Return” moves the cursor to the beginning of the line without advancing to the next line (returns the “carriage” to its starting point); and “Line Feed” moves the cursor down to the next line (but without returning the carriage), “feeding” the page up by one line. Using both characters in sequence essentially means “move the cursor to the start of the next line”.
The HTTP protocol specification (RFC 2616) states that a blank line must be used during a client’s HTTP request in order to indicate the end of the request headers and the beginning of the request payload, if any. The web server may use the presence of the blank line to indicate that the client request is complete and it should process the request and format and send its response.
A valid HTTP request would therefore contain a <CR><LF> sequence at the end of a line to start a fresh line and a <CR><LF><CR><LF> sequence to denote the end of the headers with a blank line.
We now have all the pieces to perform an analysis of an HTTP GET request helps further explain how and why a slow HTTP DoS attack is possible.
First, lets consider a “regular” complete HTTP GET request example, albeit a reduced one with minimal headers:
GET /index.php HTTP/1.1<CR><LF>
Host: example.com<CR><LF>
Connection: Keep-alive<CR><LF>
Accept: */*<CR><LF><CR><LF>
However, in a slow HTTP DoS attack the client never sends a finishing blank line to complete the HTTP header, keeping the server stalled indefinitely;;
GET /index.php HTTP/1.1<CR><LF>
Host: example.com<CR><LF>
Connection: Keep-alive<CR><LF>
Accept: */*<CR><LF>
X-Header1: 1<CR><LF>
(pause 5 seconds)
X-Header2: 2<CR><LF>
(pause 5 seconds)
X-Header3: 3<CR><LF>
(pause 5 seconds)
(etc)
The servers that are most vulnerable to SlowLoris attackers are webservers that are “threaded” in operation – that is, by design they handle each request with a new thread (or process) and these threads or processes consume memory when created, and continue to consume memory even when inactive, and consume CPU cycles in being polled. To remain manageable the threads are strictly finite in number – and so too, in direct proportion are the number of simultaneous connections they can handle. This architecture includes webservers such as Apache 1.x and Apache 2.x, and the inability of this architecture to scale became known as the “C10K” (10,000 connections) problem. Even at a maximum of 10,000 concurrent connections, an attacker can exhaust the available connection pool quickly with minimal resources.
This (theoretical) connection limit was solved through the evolution of event-loop (asynchronous) architectures in webservers such as Nginx. These do not spawn a process or thread for every connection but instead operate a number of worker processes that accept new requests from a shared “listen” socket and execute a highly efficient run-loop inside each worker to process thousands of connections per worker.
To explain via a simple analogy – Apache is a coffee shop with 3 tills and 3 workers – each worker takes an order and then goes to make the order. As soon as 3 orders are received, all 3 workers are busy making coffees and no new orders can be taken. Denial of service has occurred. In an “event-based coffee shop”, there are still 3 workers, but one manages the till in a dedicated fashion, simply noting the order and passing it back for processing before turning to the next customer – new customers can place orders no matter how many orders have already been taken.
Nginx and other event-driven webservers are still vulnerable to SlowLoris attacks, however the degree of “amplification” is much reduced and the resources needing to be expended by the attacker to inflict Denial of Service is several orders of magnitude greater.
One approach is to constrain the total amount of time a client connection is permitted to stay open without completing. In the Apache web server, a number of modules can be used to limit the potential for SlowLoris attacks; the Apache modules mod_limitipconn, mod_qos, mod_evasive, mod security, mod_noloris, and mod_antiloris have all been suggested as means of reducing the likelihood of a successful SlowLoris attack. Since Apache 2.2.15, Apache ships the module mod_reqtimeout as the official solution supported by the developers.
These measures provide some mitigation against the vulnerability but cannot eliminate it entirely, but using a firewall to limit the number of connections from a single host is generally a more robust approach, but is necessarily reactive, in that high connection levels have to be seen before the firewall can react. Perhaps the most robust approach involves the proactive screening of origin servers using the reverse proxy technology within Content Delivery Networks (CDNs). Since these operate at network edge (ie nearer the attacker than the server itself) they can mitigate attacks more successfully and at source. They generally buffer incoming requests before starting to send anything to the origin server as part of their design, so the origin server will never even be aware that a SlowLoris attack was initiated against it.
AppCheck performs comprehensive checks for a massive range of web application vulnerabilities from first principle to detect vulnerability – including SlowLoris. AppCheck also draws on checks for known vulnerabilities in vendor software from a large database of known and published CVEs. The AppCheck Vulnerability Analysis Engine provides detailed rationale behind each finding including a custom narrative to explain the detection methodology, verbose technical detail and proof of concept evidence through safe exploitation.
As always, if you require any more information on this topic or want to see what unexpected vulnerabilities – not always relating to tropical, tree-dwelling quadrupeds – AppCheck can pick up in your website and applications then please get in contact with us: info@appcheck-ng.com
No software to download or install.
Contact us or call us 0113 887 8380
