Denial of service 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 deinal of service attacks can be classified into two categories: traffic-based, which will be the focus of this post, 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 seand 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 resourcs 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 speace on the victim until resources are exhausted.

Traffic-based denial of service attacks have become less effective in recent years, networking equipment manufacturers come preconfigured to silently drop ICMP directed broadcasts. Many network firewalls have preconfigured 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 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 I’ll cover is 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 ToS (Type of Service) 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 Voice over IP phone 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 infastructure responsible for delivering traffic to that host. One of the most common mistakes made when configuring QoS services is to only to configure policies based on 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 Google search for some tech info indicates that voice traffic from this system is by default marked with a DSCP value of cs3. The network engineers responsible for this network have most likely configured the infastructure 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 seperate 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 virances 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 accross 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 intrustion 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 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 a constant stream of malicious payloads from the IPs of Google, or a company’s known business partner. A company could 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. Until next time happy reading….

Powered by Qumana