Denial of service (DoS) attacks are the bluntest of tools in the web application exploit arsenal. The coarsest of attacks employ nothing more than a flood of packets that overwhelm the target’s capability to handle such an amount of traffic. Most likely, the web application itself never sees the full effect of the assault because the network stacks of the underlying operating system and network devices fall over before legitimate traffic percolates up to the application.
DoS appeared on the original OWASP Top 10 list from 2004 (entry A91) with allusions to bandwidth and server resource consumption. At the TCP layer, most DoS attacks are agnostic of the target’s services. Bandwidth flooding, packet fragmentation, and similar techniques apply either to the protocol itself (TCP, UDP, or even ICMP) or take advantage of vulnerabilities in an operating system’s network stack. As a consequence, such attacks typically fall out of the purview of web application developers or are treated as parallel issues that cannot rightfully be addressed at the application layer.
On the other hand, the class of DoS attacks that target resource consumption (CPU cycles, memory, database contention, etc.) can and should be addressed by the web application (and by extension the web server and database engine). These types of attacks don’t have universal applicability that most network layer attacks do, but that is of little consolation if you’re in charge of the targeted web site.
In The Book’s chapter about SQL injection (Chapter 3, p. 48) there’s an example of how a vulnerable link was used as leverage in a DoS attack against the RIAA’s web site. Instead of attempting to pilfer data or compromise the system, the SQL attack executed MySQL’s BENCHMARK command millions of times in order to spike the CPU’s utilization.
These resource consumption attacks place a lopsided burden on the victim’s system relative to the attacker’s. In contrast, bandwidth-based attacks tend to require a roughly equivalent amount of resources between the attacker and victim. (Keep in mind that distributed denial of service, or DDoS, require the attacker to have active or “zombie” cohorts of compromised systems to launch the attack.) The previously mentioned SQL statement can be delivered in a single GET request from the attacker, but the effects last much longer on the victim’s side.
Resource consumption attacks need to exploit a specific vuln. Instead of looking for SQL injection vectors an attacker might simply look for search-style functionality on the target web site. If the search ends up causing the equivalent of a full table scan in a database, or hits an otherwise unoptimized query, then the attacker could hammer that particular link to sink the target. Sites that execute user-supplied regular expressions expose themselves to a similar problem. Regex patterns can be equally inscrutable, deathly recursive, and inefficient. Good developers spend time crafting concise, effective patterns, but an adversarial user might create a pattern that leads the regex engine down the path of heavy CPU use.
Interesting attacks also target protocols. The stateless nature of UDP, for example, makes it trivial to spoof packets. HTTP lays atop TCP, which severely limits the success of spoofing attacks, but exposes trickier scenarios that combine TCP and HTTP properties to create a hybridized attack in which a few well-crafted, valid packets can lead a web server to set aside large amounts of memory for only a handful of requests.
A recently released tool, slowhttptest2, demonstrates this so-called “Slow HTTP” or “slowloris”3 attack. Check out the tool’s documentation and its related links for insight on how the attack works. The tool also demonstrates the “Apache Killer” attack that showed up in the last few weeks.4
This isn’t a tech-heavy post about DoS and protocol analysis. Instead, I wanted to highlight some recent noise that’s been made about this kind of attack. This also leads to the larger issue of “securing to the checklist” or focusing on the attacks made popular at security conferences vs. attacks occurring in the wild.
It’s easy to dismiss bandwidth consumption attacks as intractable problems for web apps that lack the server distribution and resources of sites like Facebook, Microsoft, Yahoo!, Google, or Amazon. Many site developers simply don’t have the means to react effectively.
Resource consumption attacks are another matter. (Bandwidth doesn’t count as a resource for this purpose.) The emergence of adversarial groups like Anonymous, Antisec, and Lulzsec demonstrate the continued utility of blunt DoS as well as how apparently easy it is to find SQL injection vulnerabilities. (…and unencrypted passwords.)
These groups launch DoS attacks from ideological motives that seem to boil down to fighting noise with greater noise; silencing opposition rather than amplifying their own message. Regardless of the drive, the desire to continue DoS attacks should be evident and will likely lead to tools that reach higher into the protocol layer than crude packet stuffing. (Determining the merit of this approach belongs in another post, so we’ll depart this aspect of the discussion for now.)
Most DoS attacks are neither new nor particularly innovative, although there are clear improvements on the theme as shown by tools like slowhttptest and Apache Killer. The “slow” attacks and protocol abuse as demonstrated by these tools show how web developers can in fact improve their architecture and web servers to be more resistant. The continued presence of SQL injection, despite clear, simple, effective countermeasures reveals that not everyone pays attention to advances in security.
Web security seems to favor the attacker — look at the prevalence of “Yet Another XSS Exploit” at security conferences vs. the amount of discussion on countermeasures. (Perhaps also due to the perspective that attack is fun and defense is boring.) DoS attacks don’t have to move beyond the LOIC5 to be effective in taking down most sites, but the nature of the attack will be sure to improve and it would behoove site developers to keep this in mind as they configure and deploy web applications.
=====
1 https://www.owasp.org/index.php/A9_2004_Application_Denial_of_Service
2 http://code.google.com/p/slowhttptest/
3 http://ha.ckers.org/slowloris/
4 http://seclists.org/fulldisclosure/2011/Aug/301
5 http://sourceforge.net/projects/loic/
