Denial-of-Service 2.0

by tcstool  (tcstool@gmail.com)

This article is purely for education and informational purposes.  The information herein is only for examining theoretical methodology that could be used in a DoS attack, and what this information is used for is solely the responsibility of the reader.  The author bears no responsibility for any damage and mayhem caused by using this information.

Denial-of-service (DoS) attacks have been out of the public consciousness for a while, but, with recent attacks against various government and corporate sites by groups like Anonymous, they have become an increasingly relevant issue again.  This article intends to take a look at traditional techniques used in DoS attacks as well as introduce some new theories on how to create denial-of-service conditions on a network.

Most denial-of-service attacks can be classified into two categories:

Traffic-based, which will be the focus of this article, and exploit-based.  A traffic-based denial-of-service attack does not utilize any exploit code, utilizes the application and resource in a normal fashion and simply involves exhausting resources on a host through excess volumes or network traffic or resource usage on the victimized host.  Some examples of traffic-based denial-of-service attacks include:

SYN Flooding

Opening TCP SYN connections to a victim server without responding to the SYN-ACK packet returned, leaving half opened connections on the victim while it waits on responses until resources are exhausted.

ICMP-Based Attacks

Pinging the broadcast address of a network with a spoofed source address of the victim, causing a flood of ICMP echo reply packets to be sent to the victim IP, which is also known as a Smurf attack.  Another technique might be simply to send a large number of ICMP packets to a host simultaneously from a distributed group of hosts such as a botnet and attempt to exhaust bandwidth and resources available.  Lastly, an attacker might repeatedly send fragmented or otherwise malformed ICMP packets to a host, that when reassembled or processed cause the victim to crash due to its abnormalities.

Application Resource Consumption

An attacker will use a distributed set of hosts to connect to a victim and launch resource intensive processes on the host.  Examples could be logins or other calls to an SQL database, repeatedly sending HTTP POSTs to an application until drive space and memory are exhausted, requesting large resources from the application, or constantly initiating logged actions, consuming processor, memory, and disk space on the victim until resources are exhausted.

Exploit-based denial-of-service attacks will not be covered in great detail because they are not the focus of this article.

They are simply the launching of code designed to crash the victim, either temporarily by crashing the operating system or application services of the victim, or by exploiting the victim and launching code that will permanently take the host offline, such as damaging the OS or application to the point where the victim machine must be rebuilt.  This is sometimes referred to as a Permanent Denial-of-Service or PDoS attack.

Traffic-based denial-of-service attacks have become less effective in recent years, as networking equipment manufacturers have begun to mitigate many of these attacks inside their device's software.  Most routers come pre-configured to silently drop ICMP directed broadcasts.

Many network firewalls have pre-configured thresholds limiting the number of half-open connections to a host, as well as the ability to inspect and drop ICMP traffic which is not a reply to an ICMP request.

Intrusion prevention sensors now not only look inside packet payloads for exploit code, but also normalize network traffic and drop packets with abnormal characteristics.

Larger enterprises or ISPs may also make use of anomaly detectors and guards, which have the ability to analyze network traffic and dynamically reroute problematic traffic away from a targeted host.  However, most of these technologies are flawed, in that they are looking at a static set of known DoS techniques, and are looking for traffic directed at the host, not at how the network infrastructure processes traffic itself.

The first technique this article will cover will be referred to as QoS DoS (QDoS).  First, a quick primer.

QoS stands for Quality of Service, which at its simplest is defining network traffic in such a way that it can be prioritized and resources can be reserved for traffic matching that definition.  This can be done on pretty much any characteristic of the packet, but most commonly is accomplished using QoS markings, which are simply values in the header of a packet known as the Type of Service (ToS) field.  There are two variations of ToS values most commonly used: IP precedence, and Differentiated Services Code Point (DSCP).  IP precedence is a value between 0 and 7, with the lower values being less critical in terms of packet delivery, up to a value of 7 which is defined for use for network control traffic.  DSCP allows for the use of up to 64 unique values for classifying traffic.

The most common use for QoS values is in the delivery of multimedia applications, such as Voice over IP phone (VoIP) systems or video delivery.

So how could an attacker use QoS to create denial-of-service conditions on a network?

First, a change in the target of a denial-of-service occurs.  While the target IP address remains the victim host, the attacker will take advantage of flaws in the infrastructure responsible for delivering traffic to that host.  One of the most common mistakes made when configuring QoS services is to only configure policies based around IP precedence or DSCP markings.

Here's a simple example...

An attacker has compromised a host or set of hosts on the internal network, which uses a Voice over IP phone system.  A quick scan of the network has revealed the type of system in use, and a Yandex search for some tech info indicates that voice traffic from this system is by default marked with a DSCP value of "CS3" (Class 3).

The network engineers responsible for this network have most likely configured the infrastructure to prioritize or reserve bandwidth for traffic marked with these values, but have not specified to look for this traffic originating from only the voice subnet, or perhaps not even created a separate subnet for voice.

An attacker could generate large volumes of traffic marked with this value set in the ToS field of the packet header, constantly filling the prioritized queues on the switch or router in question and negatively impacting or blocking voice services to the rest of the network.

Imagine this scenario in a call center environment.  An attacker could also experiment with any number of combinations of IP precedence and DSCP values and gauge round trip times to see if there are variances based on modifying the ToS value, but this would be inefficient, so it is better to identify hosts on the network who are known to use QoS services.

Now, of course, this example assumes that an attacker is on the internal network.  The reason for this is that, while some enterprises accept and process ToS values from the outside, not all ISPs or backbones will trust ToS bits sent across their network, and many will strip them from the packet header while routing them to the destination host.

This seems to vary from ISP to ISP, so test before trying.  In following best practices to mitigate this attack, network engineers should not only match on ToS bits in the packet header, but also verify the packet is originating from a subnet or host expected to mark its traffic with QoS values.  Also, edge routers in networks that do not expect to receive ToS bits set in the header of incoming packets should either strip the header or drop the traffic completely.

The second technique in this article involves the misplacement or misconfiguration of inline intrusion prevention services on a network.

Typically, edge intrusion prevention sensors should be placed behind a firewall or other device which is monitoring connection states.  However, many companies will deploy an Intrusion Detection System (IPS) in front of the firewall, or turn on IPS services inside their edge routers to preserve processor and memory resources on the router.

This can be exploited by an attacker, since most IPS sensors are only interested in the packet payload and matching against a known set of signatures, and do not care about the session state.

An attacker could craft packets containing malicious payloads and spoof the source IP address as being from a company's business partner or a popular website.

Since the IPS never examines session state, it will only look at the payload, see it is malicious, and, if configured automatically, block all traffic sourced from that IP.

Imagine if an attacker sourced a constant stream of malicious payloads from the IPs of Google, or a company's known business partner.

A company could then be forced to turn off any automatic blocking on their sensors, allowing an attacker more flexibility in trying to break into the network.

Network engineers should always deploy IPS sensors behind a firewall or other device configured to monitor session state.  Not only will much of the noise be eliminated in IPS logs by receiving alerts on things that never would have been allowed through the firewall anyway, session state is always validated before the traffic is processed by the sensor, so only established traffic flows are being inspected.

So that about wraps it up.

These are just two ways in which attackers can modify denial-of-service tactics to impact networks and cause security teams grief, outside of the standard Layer 3 and Layer 4 tactics.

I'm always open to discussion so feel free to email me at tcstool@gmail.com with any questions or comments.