- Introduction
- Application DoS Overview
- Application DoS Attacks
- Conclusions
- Acknowledgement
Application DoS Overview
Application DoS attacks exploit flaws in the bespoke application design and implementation to prevent legitimate access to the victim's services. They represent a subset of potential attacks on such applications, as they are aimed specifically at disrupting operation rather than subverting the application controls.
Attacks based on exploiting these flaws can offer the attacker a number of advantages over traditional DoS attacks:
The attacks will typically not be detectable or preventable by existing security monitoring solutions1 – Since the attacks do not consume an unreasonable amount of bandwidth and could, in many cases, be indistinguishable from normal traffic.
Application attacks are more efficient – The attacker may not need as much resource at their disposal to successfully complete the attack. Application level attacks target bottlenecks and resources limitations within the application and do not require many compromised "zombie" systems or a large amount of bandwidth. Furthermore, they can be targeted at the weakest link in an environment – for example if a web-farm of a hundred servers relies on a single back-office host to authenticate users, an application attack may be able to directly target it.
Application attacks are harder to trace – Application level attacks normally use HTTP or HTTPS as their transport. Proxy servers can therefore be used to obfuscate the true origin of the attacker; and many are available for an attacker to redirect his malicious traffic. Many of these proxy servers do not keep logs of connection attempts and could therefore successfully hide the true origin of the attacking host.
Root Causes
Application security flaws exist due to flawed design and implementation, often as a result of incorrect assumptions made during the development process.
Reasonable Use Expectations
Applications are designed and built based on expected use criteria. Capacity planning and load-testing are typically based on these criteria of expected and maximum use.
As with network DoS attacks, this narrow view of how the application may be used exposes it to disruption when those expectations are exceeded.
Application Environment Bottlenecks
Applications are becoming increasingly complex and often reside in distributed environments. The traditional approach to providing adequate capacity has been to focus resources on the client-facing tier, e.g. having a large web-farm. Often, back-office functionality such as authentication and database access have far less resource allocated.
Whilst the front-end may therefore be able to cope with far more than the expected or possible demand, there may be hidden bottlenecks elsewhere within the environment that, while not accessible to an attacker via the network, can be targeted through the application itself.
Implementation Flaws
Most existing DoS attacks have been designed to crash COTS applications or services. This same class of application attack is equally, if not more, likely to work on bespoke applications. An attacker may be able to crash application or middleware components using buffer overflow style attacks, for example. This could be due to a poorly implemented software module such as an ISAPI filter failing when sent excessive input data.
Poor data validation
Another common mistake is to implicitly trust input from the client side and user. In many cases, the application acts as a structured portal through which users interact with back-end services and databases. If these functions do not sufficiently validate client-input, it may be possible to disrupt those back-end services through attacks such as Database (SQL) or Script (XSS) insertion.
Application DoS Attack Vectors
Automated Data Submission
Web application architects and designers frequently assume that the user of the application is a person and not an automated script. This assumption often leads to vulnerabilities that can be exploited by attackers who craft automated tools to attack the application.
A simple example would be a dictionary attack on the authentication process. If a username is known, an attacker may automate the login process using passwords from a dictionary of common words until a match is found. There are many tools available to perform dictionary attacks on various protocols.
Similarly, variations on this theme can be used to attack specific weaknesses in the application's design, for example by overwhelming application functions, invoking race conditions or systematically attacking multiple entities.
Data Manipulation
Any data sent from the client-side may be manipulated by an attacker, from obvious form elements that are completed by the user to hidden fields, cookies and bespoke data channels.
Commonly, manipulation of this data before sending it to the server results in errors or unusual application behaviour – even as a result of simple modification such as sending letters instead of numbers. These back-end errors may in turn lead to exploitable vulnerabilities.