Elusive Thoughts: Bloody Death DoS-ing

Introduction

In this article I am going to explain how to perform an amplified Denial Of Service (DoS) attack on a Web Application in a high level manner, but you should be aware that these are real world scenarios that I have implemented during costumer penetration tests. A successful DoS attack on a Web Application should happen in three different layers, the Web Application, the Web Application platform and the Web Server itself. It is common knowledge of course that you don't have to attack all three layers to successfully compromise the availability of a Web Server, but optimizing a DoS attack should be desirable from the perspective of an attacker. By using the word optimize I mean three things:

Reduce to minimum the amount of the machines generating malicious traffic.
Increase the amount Web Server downtime.
Increase the amount of remediation time (e.g. recover time).
Increase collateral damage (e.g. break the database).

But first I should explain what DoS attack means, in computing, a denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS attack) is an attempt to make a machine or network resource unavailable to its intended users. Although the means to carry out, motives for, and targets of a DoS attack may vary, it generally consists of the efforts of one or more people to temporarily or indefinitely interrupt or suspend services of a host connected to the Internet.

Why talk about DoS/DDoS attacks

These attacks have become much more widespread and common in recent years and it is not just the major corporations that are being targeted. Many are now being focused on small and medium businesses as it is here that they stand the most chance of launching a successful attack as well as bringing the most havoc and chaos. The truth is that there is probably a vast majority of websites that do not currently have some type of DDoS attack protection and they will only suffer as a result.

Network-layer DDoS attacks are a popular tactic among hacktivists because they are generally low-tech and easy to carry out. The attacks typically employ a barrage of requests directed at a web server at a high frequency which can cause disruptions, rendering the targeted website inaccessible. Analyzing traffic can be a laborious undertaking, and reducing the volume of data to sift through with a first line of defense can prove advantageous in maintaining a robust network security stance.

Financial firms were in the crosshairs of cyber-attackers during the first three months of 2012, while a threefold increase in DDoS attacks was recorded. DDoS mitigation biz Prolexic reports that the growth in the number of attacks against its clients in banking and insurance was accompanied by a 3,000 per cent increase in malicious packet traffic (up from 14 billion packets of malicious traffic in Q4 2011 to 1.1 trillion in Q1 2012).

Methods of performing a DoS or DDoS attack

A "denial-of-service" attack is characterized by an explicit attempt by attackers to prevent legitimate users of a service from using that service. There are two general forms of DoS attacks: those that crash services and those that flood services.

A DoS attack can be perpetrated in a number of ways. The five basic types of attack are:

Consumption of computational resources, such as bandwidth, disk space, or processor time.
Disruption of configuration information, such as routing information.
Disruption of state information, such as unsolicited resetting of TCP sessions.
Disruption of physical network components.
Obstructing the communication media between the intended users and the victim so that they can no longer communicate adequately.

A DoS attack may include execution of malware intended to:

Max out the processor's usage, preventing any work from occurring.
Trigger errors in the microcode of the machine.
Trigger errors in the sequencing of instructions, so as to force the computer into an unstable state or lock-up.
Exploit errors in the operating system, causing resource starvation and/or thrashing, i.e. to use up all available facilities so no real work can be accomplished.
Crash the operating system itself.

Note: The definition of the DoS and DDoS attack was taken directly from Wikipedia (the link can be located at the bottom of the article). Wikipedia has a very good definition of what DoS and DDoS attack is, what is missing is how can these conditions (1 through 5) can happen in 2012 (which I think it is out of scope of the wiki article anyway), meaning that the article is outdated and does not cover all conditions because it is reducing the attack surface to the machines surrounding the victim machine, the operating system (OS) of the victim machine and hardware of the victim machine.

Defining a valid DoS and DDoS attack surface

When I am referring to the attack surface of a DoS or DDoS attack I mean the components someone should be attacking in a Web Application. The components are:

The Web Application.
The Web Application Platform.
The Web Server.

Note: Each component has it own peculiarities and has to be treated differently in order to have the best possible outcome.

Special care should also be taken into consideration when attacking each layer separately and of course a detailed auditing of the engaged technologies must be conducted before launching the attack. What I mean is that based on the type of the attack planned and the way the Web system behaves a relatively complex customized DoS or DDoS attack can be launch in a highly effective manner (you will understand later what I mean by saying that).

The following picture shows how different vulnerabilities can be associated with each layer and cause a DoS attack:

Note: The above diagram shows how combined attacks to all three layers of the target server can be used to amplifie a DoS or DDoS attack and make it practically unstoppable. Imagine an advanced attacker launching an attack like that (meaning combining all different type of vulnerabilities).

A generic low tech DoS attack might be easy to defeat when proper countermeasures are taken, but what happens when the attacker knows also the counter measures for the counter measures a defender would use? Well you might be confused now, but hopefully you will understand what I mean later on.

DoS-ing the Web Application Server

A number of well documented and known, but not so interesting attacks can be launched in a Web Server level by simply performing one of the well known and famous attacks named below (this is a sample of the total amount of DoS and DDoS attack types someone can use against a Web Server):

ICMP flood also known as Smurf attack

A smurf attack is one particular variant of a flooding DoS attack on the public Internet. It relies on misconfigured network devices that allow packets to be sent to all computer hosts on a particular network via the broadcast address of the network, rather than a specific machine. The network then serves as a smurf amplifier.

Note: This is an outdated attack and most of the time is not going to be feasible to high profile targets such as important US government web sites for example. But can be used for diversion e.g. flooding surrounding machines along with the target machine might confuse the intrusion prevention middle device (simplistically speaking of course) about the network source of the attackers.

SYN flood

A SYN flood occurs when a host sends a flood of TCP/SYN packets, often with a forged sender address. Each of these packets is handled like a connection request, causing the server to spawn a half-open connection, by sending back a TCP/SYN-ACK packet (Acknowledge), and waiting for a packet in response from the sender address (response to the ACK Packet).

Note: This is an old and well documented attack that is also not very interesting and counter measures exist for years about this specific attack from various vendors.

SSL DoS

SSL-DoS exploits an SSL design flow by overloading the server and knocking it off the Internet.This problem affects all SSL implementations today. The vendors are aware of this problem since 2003 and the topic has been widely discussed. This attack further exploits the SSL secure Renegotiation feature to trigger thousands of renegotiations via single TCP connection.

Note: Establishing a secure SSL connection requires 15x more processing power on the server than on the client, which implies that an asymmetric resource starvation attack will happen.

Buffer Overflow DoS Attacks

The data transferred to a user input buffer exceeds the storage capacity of the buffer and some of the data overflows into another buffer, one that the data was not intended to go into. Since buffers can only hold a specific amount of data, when that capacity has been reached the data has to flow somewhere else, typically into another buffer, which can corrupt data that is already contained in that buffer. This can be elevated to remote command shell that would give the attacker to remotely shutdown or reboot the system or simply crash the underlaying operating system.

Note: Again this type of attack is considered to be a relatively advanced type of attack especially when zero day exploits are used, it also implies that an asymmetric DoS attack can happen.

DoS-ing the Web Application and Application platform

A DoS attack can also happen in a Web Application or Web Application platform layer. These types of attacks are usually very rear or do not become public most of the time, I call them low publicity DoS and DDoS attacks. The complexity of these attacks is significantly higher than the previous ones if you exclude the Buffer Over flow and SSL DoS attacks (when you don't use online hacking tools). The concept behind these type of attacks is that the attacker has to have knowledge of the Web Application input validation filters. In order for me to be more clear I will list below the ones I consider the most popular input validation DoS and DDoS attacks:

SQL Injection DoS attack

SQL injection is a technique often used to attack a website. This is done by including portions of SQL statements in a Web Application user or none user entry point in an attempt to get the website to pass a newly formed rogue SQL command to the database, now if the injected command contains a valid SQL shutdown command then the outcome would be to for the database to shutdown, crashing the Web System under attack.

Note: Obviously someone can perform an asymmetric DoS attack of this type. You should also take into consideration the fact that an attacker can exploit the same way also a blind SQL injection. A Web Application firewall would not stop a SQL Injection DoS attack if the attacker obfuscates her SQL payloads (for more information on the subject see previous posts).

Directory traversal DoS or DDoS attack

A directory traversal (or path traversal) consists in exploiting insufficient security validation / sanitization of user-supplied input file names, so that characters representing "traverse to parent directory" are passed through to the file APIs, also directory traversal attacks can be expanded through bad privilege assignment. Being able to request large size files from the host operating system is usually something that is going to slow down significantly Web Application performance and that is something the Web Application was initially not designed for.

Note: This type of attack is likely to be successful in a DDoS type of attack. Imagine multiple users requesting the /dev/random in a unix-like operating system. For more information on obfuscating path traversal check this link.

External Entity Injection DoS attack

An External Entity Injection (XXE) is generally speaking a type of XML injection that allows an attacker to force a badly configured XML parser to "include" or "load" unwanted functionality that compromise the security of a web application. Now days is rear to find this types of security issues. This type of attack is well documented and known since 2002. By exploiting an XXE injection you can perform a similar attack to the directory traversal DoS attack by loading large size documents.

Note: Again imagine an attacker requesting large size file from the hosting operating system and specially in unix-like operating systems the /dev/random file.

Web Application Design DoS Attack

A Web Application design DoS attack (WADD) is feasible when the Web Application does not take into consideration how a Web Application behaves when thousands of malicious payload are send. This type of attack also has to do with Web filter malicious payload processing time, for example a Buffer Overflow payloads would probably increase Web filter processing time.

Note: Imagine an advanced attacker brute forcing Web Application user accounts connected directly to an Active Directory Server. If the Web Application does not have a proper lock out mechanism then Active Directory accounts will be locked.

The picture below shows a schematic representation of all three attacks mentioned above:

Note: See that at the diagram above the Web filter is particularly emphasized.

By now you should be able to understand that in most occasions when someone is fuzzing the Web Application parameters, then the corresponding server http response, to the malicious http request is going to start vary as far as the time delay is concerned. One of the desired side effects of that process would be be the increase of your chance to randomly crash the Web Application if the Web Application is not vulnerable to any of the Web Application layer mentioned above (it should be noted at this point that this is a conclusion based on my experience and I don't keep keep statistics of the crushed Web Applications).

The diagram below shows a schematic representation of how a web filter is DoS attacked:

Note: A Web Application that does not use Web filters at all is possibly vulnerable to one or more of the vulnerabilities mentioned above. A Web Application that does use Web filters might be vulnerable to a Web filter DoS attack.

DoSing the Web filters

Web filtering is very important in a Web Application. Imagine a regular expression performing white list filtering in the server side, filtering thousands of malicious http requests. The processing time of the malicious request can dramatically increase if the implementation of the filter is bad, for example if you have a Web Application field that excepts as an input a three digit number then the Application should stop processing that request after 10 first failed attempts, in fact during none production functional testing (e.g. load stress tests) a Web Application might cause DoS/DDoS attack to itself due to bad Web Application filtering. You may also encounter filters which, rather than blocking input containing the items in the preceding list, attempt to modify the input to make it safe, either by encoding or escaping problematic characters or by stripping the offending items from the input and processing what is left in a normal way. Simplistically speaking an application should understand when it is being attacked and reject incoming traffic from the malicious ip (e.g. bind session with ip).

The following diagram shows a conceptual representation of what I mean:

Note: The malicious http request is rejected immediately after it meets the specific criteria of being characterized as malicious.

Combining all DoS attack types together

An advanced attacker when combining all the DoS and DDoS attacks explained above would definitely have very good results in compromising the availability of the target server. A combined attack would have the desired results listed below:

Decrease of the amount of the attacking machines required to bring down the server, since asymmetric and symmetric types of DoS attacks are engaged.
Decrease of the amount of time needed to crash the server since the attack is multi-layered, taking advantage of a larger number of vulnerabilities identified in the server.
Increase the amount of time of remediation due to the complexity of the attack, therefor increasing the server down time.

Prevention and response

Defending against Denial of Service attacks typically involves the use of a combination of attack detection, traffic classification and response tools, aiming to block traffic that they identify as illegitimate and allow traffic that they identify as legitimate. But in a situation of a combined attack such as the one above there is not much that can be done. My assumption is that a combination of properly configured Intrusion Prevention System, Web Application Firewall and Database Application Firewall might prevent a DoS or DDoS attack such as the one I described above.

References:

Pages

21/10/2012

Bloody Death DoS-ing