Application DDoS: A Primer

With all the fuss around application attack vectors that keep hitting the headlines, there is always one element that evades eyes and ears, Application Denial Of Service (AppDoS). Why?  Mainly because of a generic misconception around what this attack is and how it works.  (The OWASP reference can be found here.)

This attack has seen tremendous growth because:

• It is used by Anonymous.  In fact, the Anonymous DDoS attack tool, low orbit ion canon, defaults to HTTP attack—not TCP/IP.
• Several tools, including LOIC, have been developed for the purpose of application DOS.  One example is RefRef.

For a breakdown of how a distributed-denial-of-service (DDoS) attack works, click here.

In this blog post, we will:

• Define AppDoS
• Show how does it works
• Show the problem that it brings to the table
• How to identify and mitigate AppDoS attacks using application security technologies.

What is AppDoS?
AppDoS, although not a new concept, has evolved greatly in the past few years, especially with the evolution of web applications, and organizations are putting more and more real estate online to serve customers.

Let’s first establish the difference between the Application DoS flavor from the classic network DoS.

In general, DoS is the idea of consuming resources from a service until it has no available resource to offer thereby denying the service’s users from gaining access. A good example for network DoS will the classic “SYN-Flood”, which targets the network service by consuming the server’s available sessions, addressing the TCP handshake directly .SYN is the first step of the three-way handshake.  This attack starts the handshake but never finishes so the attack relies on the server holding open connections and never terminating them.  If a server can provide, lets say, 1000 connections, and we SYN-Flood, it will exhaust its resources quite quickly, not allowing new connections to be established.  SYN-Flood is therefore a Network Denial of Service technique. It is today easily mitigated with most if not all IPS technologies.

Application DoS is somewhat different. It does not address the network resources, or the bandwidth to the service, but the application and the web server itself. Techniques that are included in Application DoS might be SQL Injection, RFI, and the more common service overload. Application DoS will be directed at specific flavors of Web Servers (such as IIS, Apache, etc…) or to specific applications (such as SharePoint etc…) by understanding backend architecture.

How does an Application Denial of Service attack work ?

To demonstrate AppDoS, we must first look at the architecture of a common web service.

Note that the network DoS targets reside in the “Access Zone”, while AppDoS targets reside mostly in the “Application Zone” which includes the web front end and the data store for it.

The building blocks of a successful DADoS attack, are:

1. Bypass ALL of the Access Zone controls in place, address a weakness on the Application Zone
2. Execute a payload that communicates directly with the Web Server to hit either the Application , the Server and/or the backend server. All building blocks are usually wrapped inside an attack tool which has been used by Hacktivists.

For Guts and Glory

To demonstrate a technique of hitting the application service, let’s look at the service stack.

Typically, most of the repeated from a web page is cached by a frontend caching/proxy service, and at the top, an IPS to identify anomalies. Application DoS hackers rely on these facts when building the techniques they use.  How?

Step one: Bypass the mechanisms put in front of us. To do so, Hackers use a mixture of some very common techniques such as header content and order obfuscation, to avoid getting fingerprinted by IPS systems, and Unique Random Value generation on parameter values – to ensure that the request cannot be cached. Generally speaking, by using both techniques, the mechanisms in the access zone will forward the requests as unique and non-harming data, letting it all the way through to the server.

Let’s look at an example request header of a well known AppDoS tool:

In the example above we can clearly identify the techniques to ensure that the request reaches the application server itself and does not get stopped by any perimeter security solution. As highlighted, the header contains some unique random values (in the GET request, and in Referer) has a random Keep-Alive value, asks for no-cache content explicitly, and obfuscates the User-Agent by changing it on every request.

The result – the web service’s own resource pool gets exhausted, because there is no controlling mechanism to throttle down the requests, bringing it down.

What Is My Risk?

The risk with AppDoS boils down to two things: awareness and the lack of mitigation controls.

While most organizations today already address some of the risks of DoS by introducing redundant bandwidth lines, offloads, IPS technologies and the classic access control, they are not relevant to AppDoS in most of the cases.

Most DoS mitigation controls address the weakness of the network stack and bandwidth, looking for network load thresholds, or repeated traffic, which is not what ADoS is all about. Knowing that the problem is application should raise a concern understanding that specific mission controls should be put in place.

As demonstrated earlier, if an attack consists of about 1000-5000 requests, appears unique, does not trigger any policy – it will bypass all network DOS elements, leaving even the most sophisticated networks bare naked. Perhaps one of the best examples will be the techniques that hacktivists have been using, which proven to be effective against even the largest and most secure organizations in the world.

Mitigation Techniques

Application aware security controls are the generic answer here. If its Web, you need a Web Application Firewall; if its VoIP, you need a VoIP security gateway; RPC – application specific controls, etc.

As mentioned earlier, awareness is key here. Knowing that attacks have elevated, means you can start taking measurements to secure your estate.

It is very important that you consult with your Application Security solution provider to make sure that this risk is taken into account in your data center.