COMMON DOS ATTACK TECHNIQUES | Hacking Exposed 5th Edition

When planning your DoS mitigation strategy, it is of course helpful to know what you are up against. This section expands on the major themes of DoS already outlined in our introduction, and it provides countermeasures we've seen deployed in the real world to mitigate such abuse.

Note	We're only going to discuss remote network DoS techniques because these are overwhelmingly the most common and the most threatening . If you've got local users DoS-ing your machine, you've got bigger problems than DoS.

Old-School DoS: Vulnerabilities

As noted earlier, in the mid-to-late 1990s, DoS was limited primarily to software vulnerabilities in common operating systems. Like most of the vulnerabilities we've discussed in this book, these are simple programming flaws that result in a failure of hardware or software to handle unexpected conditions. These exceptions normally result when a user sends unintended data to the vulnerable program. The most devastating of these "old-school" DoS techniques were single-packet exploits that targeted the TCP/IP stack of a specific operating system. Some of these classic attacks are listed here:

Oversized packets One of the earliest DoS attacks, this is typically implemented via the "ping of death" (ping -l 65510 192.168.2.3) on a Windows system (where 192.168.2.3 is the IP address of the intended victim). Another example includes jolt, a simple C program for operating systems whose ping commands won't generate oversized packets. The main goal of the ping of death is to generate a packet size that exceeds 65,535 bytes, which caused some operating systems to crash in the late 1990s.
Fragmentation overlap By forcing the operating system to deal with overlapping TCP/IP packet fragments , this attack caused many OSs to suffer crashes and resource starvation issues. Exploit code was released with names such as teardrop, bonk, boink, and nestea.
Loopback floods One of the classics, early implementations of this attack used the chargen service on UNIX systems to generate a stream of data pointed at the echo service on the same system, thus creating an infinite loop and drowning the system in its own data. Later approaches used TCP/IP packets with the victim's IP address in the source field as well as in the destination field (these went by the name Land and LaTierra).
Nukers These attacks were related to a Windows vulnerability of some years ago that sent out-of- band (OOB) packets (TCP segments with the URG bit set) to a system, causing it to crash. These attacks became very popular on chat and game networks for disabling anyone who crossed you.
Extreme fragmentation TCP/IP by its nature can be fragmented into segments as determined by the sender. When the maximum fragmentation offset is specified by the source (attacker) system, the destination computer or network infrastructure (victim) can be made to perform significant computational work reassembling packets. The Jolt2 attack was based on sending a stream of identical packet fragments.
NetBIOS/SMB Microsoft's proprietary networking protocols have had various issues over the years, including buffer overflows that resulted in DoS and NetBIOS name overlap attacks that obliterated the ability of Windows machines to participate in a local area network.
Combos To save time figuring out which of the myriad different malformed packets a victim might potentially be vulnerable to, some hackers cobbled together scripts that simply blasted a target with all types of known DoS exploits, in many cases leveraging the canned exploits we've covered here (jolt, LaTierra, teardrop, and so on). We've used combo tools such as targa and datapool effectively in the pastagainst authorized targets of course!

As noted in the introduction to this chapter, most if not all of these vulnerabilities have been patched for several years now, and for the time being, it doesn't look like this flavor of DoS will reemerge as a serious threat anytime soon. Unfortunately, as you will see next , malicious hackers now have more effective DoS techniques to turn to.

Tip	To download the tools mentioned here, and many more like them, try http://www.antiserver.it/DenialOf-Service.

Modern DoS: Capacity Depletion

Now on to the more modern DoS techniques that actually do represent a serious threat to online infrastructures today: capacity depletion attacks (a.k.a. bandwidth consumption attacks). Because the early attacks, aimed at starving a victim of resources, have largely been patched, these modern attacks take a more direct route and simply seek to use up all capacity in order to deny use by legitimate users. We will focus our discussion on the two most important classes of capacity depletion DoS: infrastructure layer and application layer.

Infrastructure-Layer DoS

In parallel with the development of the DoS vulnerabilities we discussed previously, some attention was being paid by malicious hackers to capacity depletion. One of the early capacity depletion techniques (and to this day one of the most successful) was the TCP SYN attack, which because of its ongoing prevalence, we will discuss at some length next.

SYN Floods The TCP/IP network protocol suite was designed to be used in an open and trusted community, and the widely adopted current version (IPv4) has inherent weaknesses. One of the most widely used DoS exploits of one of these inherent vulnerabilities is the SYN flood. To understand SYN floods in more detail, let's first examine the underlying TCP/IP mechanisms.

When a TCP connection is initiated, a three-step process (often referred to as a threeway handshake) occurs. This is illustrated in Figure 10-1.

Figure 10-1: In the TCP three-way handshake, the initial SYN leaves the connection in a " half-open " state that can be exploited to deplete capacity on the server.

Under normal circumstances, a SYN packet is sent from a specific port on system A to a specific port that is in a LISTEN state on system B. At this point, the potential connection on system B is in a SYN_RECV state. At this stage, system B will attempt to send back a SYN/ACK packet to system A. If all goes well, system A will send back an ACK packet, and the connection will move to an ESTABLISHED state.

Although this mechanism works fine most of the time, there is a potential problem in that most systems allocate a finite number of resources to connections in the SYN_RECV statethat is, potential connections that have not been fully established (also called "half-open" connections). Although most systems can sustain hundreds of concurrent connections to a specific port (for example, port 80), it may only take a dozen or so potential connection requests to exhaust all resources allocated to setting up the connection. This is precisely the mechanism SYN attackers will use to disable a system.

When a SYN flood attack is initiated, attackers will send a SYN packet from system A to system B. However, the attackers will spoof the source address of a nonexistent system. System B will then try to send a SYN/ACK packet to the spoofed address. If the spoofed system exists, it would normally respond with an RST packet to system B because it did not initiate the connection. Remember, however, that the attackers chose a system that is unreachable. Therefore, system B will send a SYN/ACK packet and never receive an RST packet back from system A. This potential connection is now in the SYN_RECV state and placed into a connection queue. This system is now committed to setting up a connection, and this potential connection will only be flushed from the queue after the connection-establishment timer expires . The connection timer varies from system to system but could be as short as 75 seconds or as long as 23 minutes for some broken IP implementations. Because the connection queue is normally very small, attackers may only have to send a few SYN packets every 10 seconds to completely disable a specific port. The system under attack will never be able to clear the backlog queue before receiving new SYN requests.

You may have already surmised why this attack is so devastating. First, it requires very little bandwidth to initiate a successful SYN flood. Attackers could take out an industrialstrength web server from nothing more than a 14.4 Kbps modem link. Second, it is a stealth attack because the attackers spoof the source address of the SYN packet, thus making it extremely difficult to identify the perpetrator. Ironically, this attack had been theorized for years by many security experts and is instrumental in performing trusted relationship exploitation (see http://www.phrack.org/show.php?p=48&a=14). Today, SYN floods remain the primary capacity depletion mechanism for large-scale DoS attacks, and they have taken on a frightening new dimension when amplified via DDoS.

UDP Floods Due to the unreliable nature of UDP, it is relatively trivial to send overwhelming streams of UDP packets that can cause noticeable computational load to a system. The udpflood tool from Foundstone provides a simple way of illustrating this technique. There is nothing technically extraordinary about UDP flooding beyond the ability to send as many UDP packets as possible in the shortest amount of time. We rarely see UDP flooding as a problem at online organizations we've worked with, and we normally recommend blocking most (if not all) UDP ports at the network edge anyway, so this shouldn't register very high on your radar.

Caution

Some UDP services may be mission critical (for example, DNS on UDP 53 and IKE on UDP 500), and we of course recommend exercising caution in restricting any network protocol.

Amplification: Smurf and Fraggle The Smurf attack was one of the first to demonstrate the use of unwitting DoS amplifiers on the Internet. The amplification effect is a result of sending a directed broadcast ping request to a network of systems that will respond to such requests. A directed broadcast ping request can be sent to either the network address or the network broadcast address and requires a device that is performing layer 3 (IP) to layer 2 (network) broadcast functionality (see RFC 1812, "Requirements for IP Version 4 Routers"). If we assume this network has standard Class C or 24-bit address allocation, the network address would be .0, whereas the broadcast address would be .255. Directed broadcasts are typically used for diagnostic purposes to see what is alive without pinging each address in the range.

A Smurf attack takes advantage of directed broadcasts and requires a minimum of three actors: the attacker, the amplifying network, and the victim. An attacker sends spoofed ICMP ECHO packets to the broadcast address of the amplifying network. The source address of the packets is forged to make it appear as if the victim system has initiated the request. Then the mayhem begins. Because the ECHO packet was sent to the broadcast address, all the systems on the amplifying network will respond to the victim (unless configured otherwise ). If an attacker sends a single ICMP packet to an amplifying network that has 100 systems that will respond to a broadcast ping, the attacker has effectively multiplied the DoS attack by a magnitude of 100. We call the ratio of sent packets to systems that respond the amplification ratio. Thus, attackers who can find an amplifying network with a high amplification ratio have a greater chance of saturating the victim network.

To put this type of attack into perspective, let's look at an example. Suppose attackers send 14K of sustained ICMP traffic to the broadcast address of an amplifying network that has 100 systems. The attackers' network is connected to the Internet via a dualchannel ISDN connection, the amplifying network is connected via a 45 Mbps T3 link, and the victim's network is connected via a 1.544 Mbps T1 link. If you extrapolate the numbers , you will see that the attackers can generate 14 Mbps of traffic to send to the victim's network. The victim's network has little chance of surviving this attack, because the attack will quickly consume all available bandwidth of its T1 link.

A variant of this attack is called the Fraggle attack. A Fraggle attack is basically a Smurf attack that uses UDP instead of ICMP. Attackers can send spoofed UDP packets to the broadcast address of the amplifying network, typically port 7 (the Linux/UNIX ECHO service). Each system on the network that has ECHO enabled will respond back to the victim's host, thus creating large amounts of traffic. If ECHO is not enabled on a system that resides on the amplifying network (which is the norm nowadays), it will generate an ICMP unreachable message, still consuming bandwidth.

DDoS Although Smurf and Fraggle enjoyed brief popularity, they gradually fell out of vogue as network service providers began blocking the directed IP broadcasts upon which they relied (we'll talk about exactly how directed IP broadcasts are restricted in the section "DoS Countermeasures," later in this chapter). Unfortunately, malicious hackers quickly turned to another amplification scheme that was just as effective, and much harder to block: distributed denial of service, or DDoS.

When the first edition of Hacking Exposed debuted in September of 1999, the concept of distributed denial of service attacks was mostly theoretical. Then, in February 2000, the first mass DDoS attack came. Launched against Yahoo! first, then E*TRADE, eBay, http://www.Buy.com, http://www.CNN.com, and others, the attack took down over seven major websites that we know of and countless others we'll never hear about.

The most stunning feature of the new attack paradigm was that it appeared to emanate from multiple sources, not all of which were obviously directly owned or controlled by malicious parties. Much of the 2000 DDoS attacks were traced back to poorly protected and unpatched computers in university labs. More recent attacks emanate from broadband consumer networks such as Comcast (formerly @Home and AT&T Broadband) and international regions where broadband penetration is high (for example, Korea and other Asian countries ). Slowly, it began dawning on the world that keeping one's own systems secure and well- maintained was not sufficient in the shared environment of the Internet; a few rotten apples could be harnessed to cause major inconvenience for the rest of us. The compromised systems, termed zombies within the security research community, were found to be infected with relatively sophisticated software and were first simply called DDoS clients . Some of these clients carried names such as Tribe Flood Network, Trinoo, and Stacheldraht. More recently, the programs used to remotely control compromised zombies have been termed bots (after robot) because they typically rely heavily on remote automation techniques borrowed from Internet Relay Chat (IRC) scripts of the same name. IRC has become the de facto remote control channel of choice for zombie networks. A group of zombies under the control of a single entity is called a zombie network or bot army . The controlling entity (usually a compromised system itself) can thus direct legions of systems to bombard a target computer or network with a SYN flood or other DoS attack. Figure 10-2 shows a simplified diagram of a DDoS attack using a single zombie network.

Figure 10-2: A single zombie network performs a DDoS attack.

Estimates of the size of existing zombie networks vary, from as small as a few hundred systems to nearly 150,000. As illustrated in the introduction to this chapter, the amplifying effects of DDoS can make a zombie network of even a few hundred machines quite dangerous. Today, DDoS has matured to the point where compromised zombie networks are bartered on the Internet at commodity prices. Anyone contemplating a business based on online commerce today must be cognizant of the threat of DDoS and take steps to protect the availability of their resources. We'll talk more about DDoS countermeasures in our upcoming section on generic DoS countermeasures.

DDoS Clients and Bots DDoS tools are evolving constantly, so a complete and up-to-date analysis would be futile to attempt in a publication like this. In this section, we've traced the history of DDoS programs in an effort to highlight common themes that persist to the present. For further details regarding any of the following tools, we recommend checking out Dave Dittrich's analyses at http://staff.washington.edu/dittrich/misc/ddos.

Note	Almost all these tools rely on common techniques for infection, remote control, and hiding unauthorized presence, which we discuss in detail in Chapter 13.

The DDoS tools that gained the most popularity following the 2000 attacks included Tribe Flood Network (TFN), Trinoo, and Stacheldraht. Subsequent tools based on these originals included TFN2K, WinTrinoo, Shaft, and mStreams.

Written by a hacker named Mixter (one of the most feared early DoS technicians), TFN was the first publicly available Linux/UNIX-based distributed denial of service tool (found mostly on Solaris and Red Hat computers). TFN has both client and server components, allowing an attacker to install the server on a remote compromised system and then, with little more than a single command on the client, to initiate a full-scale distributed denial of service attack. Among the types of attacks available with TFN are ICMP, Smurf, UDP, and SYN floods. In addition to the attacking components of TFN, the product allows for a root shell bound to a TCP port.

Similar to TFN, Trinoo works by having a remote control program (client) talk to a master that instructs the daemons (server) to attack. The communication between the client and the master is over TCP port 27665 and usually requires the password "betaalmostdone." Communication from the master to the server is over UDP port 27444. Communication from the server back to the master is usually done over the static UDP port 31335.

A Windows version of Trinoo, called WinTrinoo, was first announced to the public by the Bindview Razor team. WinTrinoo is capable of nearly everything its parent is capable of. The tool is a Trojan horse typically named service.exe (if it hasn't been renamed ) and its size is 23,145 bytes. Once the executable is run, like many other types of malware, it inserts itself in one of the most popular autostart extensibility points (ASEPs) in Windows to ensure that it survives reboots and logoffs by various users:

 HKLM\Software\Microsoft\Windows\CurrentVersion\Run System Services: REG_SZ: service.exe

Caution

Be careful not to confuse the WinTrinoo "service.exe" file with the file "services.exe" ( services, plural).

Chapter 13 has more information about malware infection techniques and ASEPs. WinTrinoo listens on both TCP and UDP port 34555.

Stacheldraht combines the features of Trinoo with those of TFN to provide a featurerich destruction tool that includes an encrypted telnet session between the slaves and the masters. Now the attacker can blind network-based intrusion detection systems to allow unfettered denial of service capabilities. Similar to TFN, Stacheldraht uses ICMP, UDP, SYN, and Smurf attacks. To communicate between the client and the server, Stacheldraht uses a combination of TCP and ICMP (ECHO reply) packets.

The encryption used between client and server employs a symmetric key encryption algorithm. Default password protection is also available with Stacheldraht. One additional feature worth noting is the capability of upgrading the server component on demand using the rcp command.

TFN2K stands for TFN 2000 and is the successor to the original TFN by Mixter. TFN2K is a far cry from the original, however, allowing for randomized communications on ports (thereby eliminating port blocking at your border routers as a prevention countermeasure) and encryption (thereby eliminating network-based IDS as a detection countermeasure). Similar to its predecessor, TFN2K can use SYN, UDP, ICMP, and Smurf attacks. It also can randomly switch between the various flavors of attack. Unlike Stacheldraht's "encryption," however, TFN2K uses a weaker form of obfuscation known as Base-64 encoding.

More recent DDoS variants have relied on IRC bot functionality to manage activities. The most popular is the Agobot/Gaobot family of bots, including Phatbot (see http://www.lurhq.com/phatbot.html).

Note

In Windows XP Service Pack 2, Microsoft implemented some low-level configurations to restrict malicious client code from initiating DoS attacks. Some of these have been circumventedfor example, the restriction on the use of raw sockets can be bypassed by issuing the command net stop SharedAccess, as reported by Juergen Schmidt and Holger Lembke to Bugtraq in November 2004.

Application-Layer DoS

To this point, we've discussed brute-force DoS techniques that simply seek to overwhelm the capacity of the victim. Application-layer DoS, what might be considered the new frontier of DoS, is much more elegant and, if done right, potentially requires much less in terms of brute-force resources on the attackers' side.

The basic scenario is this: An attacker finds a resource on a popular Internet site that requires very little computation for the client to request, and yet causes a very high computational load on the server to deliver. Using perhaps as little as a few queries per second, the attacker can now bring the site to its knees.

What's worse , this sort of attack very much has the potential to fly under the radar of organizations that have deployed anomaly detection gear aimed at large-scale DoS attacks involving millions of queries per second, generating additional investigative time to determine the root cause on the part of technical support staff.

As noted in our introduction, the major Internet search engines Google, Yahoo!, AltaVista (owned by Yahoo!), and Lycos suffered from just such an application-layer DoS attack in July 2004. Actually, it was DDoS, because the attack was caused by an estimated tens of thousands of computers infected by variants of the MyDoom worm (see http://secunia.com/virus_information/10755/mydoom.m) that targeted the four search engines to look up e-mail addresses to send copies of itself to further its propagation. More specifically , when the MyDoom worm encountered an e-mail address on an infected PC, it used the domain name of each e-mail address to query each search engine for additional e-mail addresses in the same domain. As noted by several media outlets at the time, all four search sites suffered availability issues during the attack.

Although this incident was technically related to potentially thousands of machines attempting to query these four search engines at one time, it's apparent that the nature of the queries played a role in the downing of the sites. Clearly, the requests implemented by MyDoom.M and its progeny were computationally expensive (we like to call them "heavy") queries. Of course, the nightmare scenario would be to combine both computationally intense requests with the amplifying effects of distributed DoS. In any case, this is just a shot across the bownow that the world has seen the effect of application-layer DoS, it will only be a matter of time before focused computational attacks start to appear.