Application Layer DoS Attacks Overview

Recent years have been very dramatic in security landscape with emerging threats; the application layer is now a more prominent target.  The new (and deadly) Layer 7 attacks called slow HTTP Denial of Service (DoS) attacks are on the rise.  Although they are not as new as they might sound, anything that is not frequently spoken of in the security world is often new!

In my experience, the common perception of DoS is a volumetric attack that occurs quickly, not slowly.  Traditionally, DoS/DDoS attacks have been volumetric, required a large number of clients and could be geographically distributed.  But slow attacks that consume minimal resources/bandwidth from the attacker side can still bring down your Web server.

Here are the results of using slowhttptest against a vulnerable Apache server in our lab environment.  The snippet below shows the tool in action where new connections are established very quickly with the server.  The Web server becomes unavailable after 5 seconds of launching the attack.

The HTML screenshot below shows the results of the same test.  The tool opens 1000 connections with rate of 200 connections per second, and the server is able to concurrently process only 351 connections, leaving the remaining 649 connections pending.

 

Why is this a problem?

  • These connections look like legitimate user connections.
  • Traditional rate detection techniques will skip them.
  • Existing IPS/IDS solutions that rely on signatures will generally not recognize them either.
  • They require very few resources and little bandwidth for execution.
  • Such attack can bring down a Web server, irrespective of its hardware capabilities.

 

How do these attack work?

Slow HTTP DoS attacks rely on the fact that a Web server will faithfully honor client requests.  The attacker’s motive is to send a legitimate-looking request to keep the server resources busy handling said requests for the longest time possible. If the attacker keeps adding to such long-ended requests, the server can quickly run out of resources.

Slow HTTP Denial of service attacks have different variants, but before we get into the details, let’s review the normal HTTP structure and flow:

 

Request

HeadersPOST /account/login HTTP/1.1 CRLFAccept: */* CRLF

Content-type:  application/x-www-form-urlencoded CRLF

Content-Lenngth: 60 CRLF

Connection: keep-alive CRLF

Host: www.customer.com CRLF

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:22.0) Gecko/20100101 Firefox/22.0 CRLF

Bodyemail=customer%40account.com&password=mypasswrd

 

Response

HeadersHTTP/1.1 200 OK CRLFServer: Apache/2.2.22 (Ubuntu) CRLF

Content-Type: Text/html CRLF

Content-Length: 200 CRLF

Date: Fri, 12 Jul 2013 05:31:32 GMT CRLF

Connection: Keep-Alive CRLF

Body<html><head>

…..

</head>

</html>

 

The different stages of the request flow can be exploited to craft different types of slow attacks:

  • Slow HTTP Headers (Slowloris): In this attack, an attacker sends partial HTTP headers at a very slow rate (less than the idle connection timeout value on the server), but never completes the request. The headers are sent at regular intervals to keep sockets from closing, thereby keeping the server resources occupied.  Below is an illustration of such an attack.

 

  • Slow HTTP Post (RUDY): As the name suggests, an attacker will slowly POST the data to Form fields. The request contains all the headers with a legitimate Content-Length header (usually with a high value) making the server aware of the amount of data expected. The attacker now injects the data in the Form at a very slow rate, forcing the server to keep its resources busy expecting more data to arrive. Eventually the server runs out of resources. Below is an illustration of such an attack.

 

  • Slow Read Attack: The client sends a full request, but when the server responds, it advertises a very small TCP window for accepting response data. Thus the server sends data slowly to the client keeping its sockets open. It keeps probing the client to check its receive windows size while the client always advertises a small window size, slowing down the transfer. The larger the file size, the more time it will take to complete such connections. Multiple such requests for a large file can potentially DoS the server quickly.

 

CREDIT: David Senecal and Aseem Ahmed

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s