My previous post on this topic covered the basics of DDoS in terms of what it is and the most commonly thought of attack type.
This post will cover some of the more interesting DDoS attacks that don’t rely just on the brute force approach of massive traffic volume to bring down a service, which attacks are also known as volumetric attacks.
The two categories of DDoS that will be covered in this post are known as RFC / Compliance Attacks and Compute Intensive Attacks.
RFC / Compliance Attacks
These typically work against vulnerabilities in either network protocols or web servers. Some examples of this form of attack are;
– Ping of Death; attacks and ICMP vulnerability
– Teardrop; works against TCP/IP fragmentation vulnerabilities in many implementations of the protocol suite
– Land; Spoof source address to send SYN packets to the host from it’s own IP address
– Apache Killer; TCP based attack against the Apache web server
– HashDoS (hash collision); attack that creates hashing collisions to DDoS various web and application servers
All of the above attacks exploit vulnerabilities in networking or application implementations and do not require a huge volume of traffic to potentially bring down a service.
As more detailed examples;
– Apache Killer; This relies on the fact that the byte range filter in some versions of the Apache web server allowed attackers to cause a DoS of the sever by sending it a header that covers multiple overlapping ranges.
– Hash DoS involves exploiting hash collisions to exhaust CPU resources. This is cause by the ability to force a large number of collisions via a single, multi parameter request.
Compute Intensive Attacks
These are attacks that typically exploit weaknesses in application workflows / process that allow certain interactions to use huge amounts of server resource or take inordinate amounts of time. Some examples of these are;
– HOIC; attacks by sending very Slow Gets, and Slow Posts
– Darkshell; send SYN, attacks HTTP idle timeout congestions
– Simple Slowloris; sends incomplete headers
– RUDY; Slow posts and long form field submissions
– Tor Hammer; sends very slow posts
These work my sending multiple slow or incomplete requests in parallel, this can quickly exhaust the web or application servers ability to service new requests without requiring a huge amount of bandwidth or resource from the attacker.
How have these evolved over the last few years?
– Initially stated with attacks like the original Slowloris that sends a very slow GET requests where the header is send extremely slowly such that it almost never actually completes. This has been very effective against the Apache web server
– Then there was the slow POST, as with the slow GET, this is a POST that is sent so slowly it almost never completes. This one is also affective against various flavours of IIS
– The most recent addition is the slow Read, where a large object is requested, then downloaded extremely slowly
These all enable the attacker to use up very many connections on the web or application server without the need for large bandwidth to be at their disposal.
There has been further tuning of these type of attacks to be specific against applications and databases that use similar techniques to make ‘legal’ requests of the system that lead to large resource requirements on the server. These can be targeted and fine tunes to cause maximum damage.
These types of attack are much more insidious than the volumetric attacks covered in the previous post as they need less resource at the attacker end so can be easier to launch. In addition the compute intensive attacks make use of allowable, normal application behaviour that is manipulated to cause a Dos condition. As such these attacks can be much harder to detect and block; at what point does a connection that is potentially just over a slow connection be identified as an attack?
This is where you have to start looking at advanced application layer defences that are tuned and configured specifically for the applications they are defending. This is another relatively large topic that I’ll likely cover in a later post, as we have now covered off the three usually identified categories of DDoS attack.