Denial-of-service (DoS) attacks are possibly the most advertised of all hacker attacks, with the exception of Web site defacements, but can be more sophisticated—and more costly—than acts of cyber vandalism. DoS attacks and tools have been the bane of the security profession. The purpose of this chapter is to help you become more familiar with how DoS tools work. In addition, DoS attacks can and at some point should be incorporated into penetration testing. It is better to find out your site is susceptible to a DoS attack during a scheduled test than during peak production times when a hacker brings down the site.
The concept of a DoS attack is to do whatever it takes to make a service unavailable to those users (humans or machines) that wish to use it. The most commonly used method is to flood the target in order to exhaust its resources (which are generally its memory, buffer space, or CPU). The exact resource being flooded depends on the target.
In addition to the flooding technique for performing DoS attacks, several attacks seek to achieve the same result by sending packets that are confusing to the target. While trying to process these packets, the system crashes, generally due to some bug in the target. Attacks exploiting bugs in the TCP/IP stack have been a popular type of DoS attack. However, while still prevalent, there has been a reduction in such attacks since TCP/IP stack implementation has improved.
There was a time when successfully performing a DoS attack was something akin to a rite of passage for aspiring hackers and was used as an act of revenge on organizations or individuals. DoS attacks are now more commonly performed to disable servers or applications and possibly gain unauthorized access. The popularity of DoS attacks within the hacker community has slowly been replaced with Web site defacement. There are also perceptions in the security community that DoS attacks require little skill and are typical of script kiddies.
Given this trend toward using DoS as a component of gaining access to a network, there is a movement toward targeting specific applications or services rather than entire systems. For example, if a firewall falls into a DoS condition, it may forward packets without applying its filtering rules. Similarly, overloading an IDS may allow activity on its portion of the network to go undetected.
DoS attacks themselves have become significantly easier to perform. A majority of the attacks discussed in this chapter can be downloaded from various hacker sites across the Web, compiled as is—without even a single modification (save to remove HTML headers that may have also been downloaded)—and then run. They are generally run with a single command at either the command line or through a Windows GUI.
In addition to those mentioned here, there are DoS scripts available to anyone with an Internet connection. With more people getting high-speed access to the Internet, the reach of these attacks has grown.
Along with downloadable scripts, a collection of DoS attacks can be launched by commercial vulnerability scanners such as CyberCop and ISS Internet Scanner. The attacks included in this collection are geared toward NT, several flavors of UNIX, and various pieces of hardware, such as Ascend or Cisco routers and even Hewlett Packard's LaserJet printers.
When and if you plan to use DoS attacks in your penetration testing, it is strongly suggested that you thoroughly experiment with and gain a full under standing of those you wish to use before employing them in a production facility. Performing these attacks is against the law—you must have clear permission before using them.
We are rarely asked to employ DoS attacks, primarily because most organizations' networks are in production while we perform our penetration testing. They cannot afford to have these systems damaged or brought down. Additionally, there is the fear that the DoS attack will cause more damage to the target system than a simple reboot will fix.
If you are requested to incorporate DoS attacks or even to scan for potential DoS vulnerabilities, we recommend you make sure this is clearly spelled out in your legal contract with the organization. It may even be advisable to specify in writing which hosts and applications the client wishes you to target and with which sort of DoS attack.
As for testing DoS tools, you should attempt to mimic real-world architecture as much as possible. We have seen DoS testing between two machines sitting on the same hub. This is certainly fine for gaining experience with the tools, however, they will not likely be as successful when used on targets behind firewalls, with multiple routers, and across the Internet. The more your testing environment resembles the real world, the better an understanding of its real-world capabilities you will have. One of the first signs of the potential effectiveness of these DoS attacks is that pings to the targets become less frequent and have a longer round-trip time.
In this chapter, we present several resource exhaustion attacks, IP fragmentation attacks, distributed denial-of-service (DDoS) attacks, application-based DoS attacks, and tools that can launch multiple DoS attacks. The general procedure for the use of these tools is to simply download the tools, compile them in whatever language they may be in (typically C or Perl), and aim them toward the target of choice. Several of the Windows-based tools are executables that can be run with a simple double-click.
One additional note: This book is not intended as the definitive guide to DoS tools. We present several tools and briefly describe them to demonstrate which tools have been successful.
Executing resource exhaustion is generally done by occupying so much of the available resources of a service, application, or operating system that it is not available to process further data. Usually, this calls for flooding the target with a great deal of useless traffic so that it cannot respond to other, legitimate traffic.
Client OS: Available as C code and also in a Linux-specific version
Target OS: TCP/IP networks
Description: The DoS tool Papasmurf is a modification of the original Smurf attack, which gained great fame as a DoS tool and even spawned a class of hackers, “Smurfs.” These Smurfs are generally novice hackers who attempt to flood their targets into submission with ICMP ECHO_REQUEST (broadcast ping) packets. Papasmurf incorporates UDP traffic as well. In this sense, it is a merge of Smurf and the Fraggle DoS tool, which uses only UDP traffic and is based on Smurf.
The command structure looks like this:
#> ./smurf5 <srcIP> <broadcast file> [options]
Where the options are:
-p
| Comma-separated list of target ports. |
-r
| Use target ports randomly. |
-R
| Use target and source ports randomly. |
-s
| Specify the source port (use the number 0 for a random port, which is default). |
-P
| Protocol to use (ICMP, UDP, or both). |
-S
| Packet size in bytes (default is 64). |
-f
| File name containing the packet data (this is optional). |
-n
| Number of packets to send (use 0 for continuous, which is default). |
-d
| Delay between packets in milliseconds (default is 10,000). |
Papasmurf allows hackers to specify target hosts along with a list of target ports, the number of continuous packets to send (specifying 0 causes continuous transmission), which protocols to use (ICMP, UDP, or both) and, optionally, a file to attach to the messages. The tool can also be configured to use randomly selected source and target ports. Further, the time between successive packets can be set. This attack can be an effective way to achieve the DoS condition in which the target is flooded with traffic and becomes unusable by regular users.
It is becoming more popular to find ICMP traffic blocked at firewalls as the risks associated with ICMP traffic are more recognized. Several programs have turned, in response, to flood target networks with Internet Group Management Protocol (IGMP) traffic.
Client OS: Available as C code (tested on Linux)
Target OS: Windows 98/95/NT/2000
Description: Trash2 floods the target with ICMP and IGMP packets from spoofed source addresses. This tool has been known to create DoS conditions even when run from a dial-up connection. It is executed with the following command:
#>./trash2 <target_IP> <# of packets>
When running this tool, the following lines are printed to the screen:
trash2.c – misteri0@unet [outlaw] Status: Connected....packets sent.
If the attack does not complete (for example, if the network connection is taken down while packets are being sent out), an error message will be shown. However, the status line does appear as shown even in instances when the target IP address doesn't exist.
Client OS: Available as C code (tested on Linux)
Target OS: TCP/IP networks
Description: As the name plainly states, Igmpofdeath.c uses IGMP messages to cause a DoS condition in the target. Igmpofdeath is based on Trash2 and incorporates the usage of type 2 IGMP packets from the DoS tools Pimp and Pimp2. The command to execute this attack is:
#>./igmpofdeath <target_IP> <# of packets>
We don't like to compare DoS tools with one another, but we have noticed that Igmpofdeath has been more effective than Trash2 when attacking Windows NT 4.0 machines with Service Patch 6 installed.
Client: Available as C code (tested on Linux)
Target OS: Windows 95/NT and Linux kernels
Description: Fawx incorporates the use of type 8 IGMP packets with fragmentation by sending oversized, fragmented IGMP packets. The cumulative effect of these large packet fragments is to cause the target to freeze (Windows targets) and/or to lag (Linux). When a target lags, so much of its processor has become occupied (in dealing with the DoS attack) that executing additional commands takes far longer than normal. The command to use Fawx is the following:
#>./fawx <srcIP> <target_IP> <# of packets>
While it may be tempting to enter the largest number of packets you could, it is wise to resist this temptation. You want to send an amount of traffic that your systems can handle and that will be successful in causing a DoS condition. And really, you don't want to send more. The more traffic you send, the more likely that your activity can be tracked and captured.
Blocking ICMP and IGMP traffic at the firewall or border router helps defend against these attacks. Additionally, the network can be configured not to respond to ping requests from external hosts; this limits the exposure to ICMP-based DoS attacks.
Client OS: Available as C code (tested on Linux)
Target OS: OpenBSD version 2.6 and earlier
Description: Attacking ARP is an up-and-coming means of performing DoS attacks. It has not gained a great deal of popularity yet because there are very few successful ARP-based DoS attack tools currently available. However, such tools are being developed as of this writing, including OBSD_fun. This is a DoS tool tailored for the OpenBSD operating system (version 2.6 and below). In truth, OpenBSD is a very safe, well-designed OS, and the particular issue exploited by OBSD_fun has been fixed in version 2.7.
The tool attempts to flood the ARP table past its memory, causing the system to freeze. This is done by flooding the target machine with spoofed packets at a rate of over 1,000 per second. The target tries to respond to these packets; however, since they do not exist, it winds up waiting, creating an entry in the ARP table. Once the ARP table is full, the system crashes.
This attack can be executed with the following command:
#> ./obsd_fun <target IP> <network> <count>
where target _IP is the IP address of the target, network is the first address of the network segment on which the target lies, and count is the number of hosts from which to spoof. We recommend you keep the count a high value, in the range of 65K.
This DoS attack can also be run from the local network. There is only one change to the above command:
#> ./obsd_fun <network> <count>
In this case, the spoofed packets are sent to random IP addresses within the network segment, whether they are valid IP addresses or not. This also causes the targets to fill up their ARP tables, trying to keep up with all the ARP-related traffic on the network.
A countermeasure for this DoS attack is to upgrade to the latest version of OpenBSD.
TCP and UDP ports are common targets of resource exhaustion attacks. There are several DoS attacks that focus on exhausting the target's ability to create connections over a particular port. These attacks not only attempt to make these ports unusable but also raise the CPU to 100 percent usage by having to manage all the connection requests on the ports under siege.
Client OS: Available as C code (tested on Linux)
Target OS: TCP/IP networks
Description: Mutilate can be used with the following command:
#>./mutilate <target_IP> <port>
Mutilate can also perform a port scan by using the -s flag in place of a target port number. The port scan allows you to determine open ports against which to then run this DoS tool.
Client OS: Available as C code (tested on Linux)
Target OS: TCP/IP networks
Description: Pepsi5, a modification of the original Pepsi DoS tool, targets UDP ports with a specifiable number and size of datagrams. Pepsi5 can run in the background and can mask the process name under which it runs (through the stealth option).
You can counter this attack by blocking all unused ports at the firewall.
SYN flooding has been a successful way to cause a DoS condition through resource exhaustion. Although this attack is being used less and less in the face of more sophisticated IP fragmentation and DDoS attacks, SYN flooding is still worth discussing.
SYN flood attacks involve sending the target multiple TCP SYN messages with no intention of following with an ACK. This forces targets to process the SYN messages, send out the SYN/ACK messages, and maintain a half-open connection while waiting for the ACK that never arrives. (It is called a half-open connection since only one side is waiting for the session to be completed.) Therein lies the potential for a DoS condition. The goal is to force the target to maintain so many of these connections that it is not capable of accepting any further connection requests. In order to do this, the attacker needs to continue sending SYN messages from nonresponsive, spoofed source IP addresses.
Client OS: Available as C code (specified for the Linux environment)
Target OS: TCP/IP networks
Description: A nice pun along with being an effective SYN flooder, Synful sends SYN packets to specified ports and targets IP addresses from randomly spoofed source IP addresses and ports. The following command is used to execute Synful:
#>./synful <target_IP> <port> <number_of_times>
If a port is not specified, HTTP port 80 is used by default. Again, it is important to use a number that is effective without resorting to overkill. If the number of times is not supplied, a default of 1,000 is used.
Client OS: Available as C code (specified for the Linux environment)
Target OS: TCP/IP networks
Description: Many consider this tool to be one of the most effective SYN flood DoS attacks available. Synk4 performs random IP spoofing along with sending out a barrage of SYN messages to a specific range of ports. The command is:
#>./synk4 <srcIP> <target_IP> low_port high_port
If you enter “0” as the source IP, Synk4 will perform random IP spoofing. The port range is specified by entering a low port and a high port.
Reducing the window during which half-open connections are maintained serves as a countermeasure for this attack. This allows the target to drop connections faster, which forces the attacker to have to issue more SYN requests in order to cause the DoS condition.
Client OS: Available as C code (specified for the Linux environment)
Target OS: TCP/IP networks
Description: Naptha is a more recent DoS tool, having surfaced in late 2000, and it features an interesting twist to a SYN flood attack. As mentioned above, SYN flood attacks are becoming less popular. However, this DoS tool combines the basic concept of a SYN flood with components of other attacks, employing SYN flooding techniques with the capability to incorporate and coordinate distributed agents. In addition, Naptha replies to the target's SYN/ACK message with the appropriate, but spoofed, ACK messages in an effort to force the target to maintain TCP connections in the ESTABLISHED state in place of the half-open connections that are usually caused by SYN floods (in a few cases with Naptha, the connections are held in other states, but the attempt is to have the target maintain connections in the ESTABLISHED state). This causes the target to maintain these idle connections even longer since the time-out for an ESTABLISHED state connection is longer than that for a half-open connection. The component sending the appropriate ACK commands must reside on the LANs on which the spoofed IP addresses reside. As these connections build up, they begin to consume available memory and CPU power on the target, leading to its failure.
Naptha is representative of a modified, perhaps second-generation SYN flood attack. Also, since it can work in a distributed manner, it can be considered a DDoS tool. We include it here because it is a sort of bridge between SYN flooding and DDoS attacks since it does not strictly require zombies or distributed agents.
Another popular style of DoS attacks is the IP fragmentation (IP frag) attack. There are generally two ways these attacks work. First, attackers can create large packets and send them out in fragments. When the target receives all the fragments and attempts to put them together, the resulting packet is too large for the target (server or application) to handle, causing it to lock up and crash. Jolt2 is an example of attacks of this type.
The second kind of IP fragmentation attack sends overlapping packet fragments and exploits bugs in the reassemble process. For example, suppose one fragment containing the packet header is sent to the host containing a HTTP Get request. As subsequent fragments arrive, one of these may overwrite the original header.
When this packet is reassembled, the target executes something other than the expected HTTP Get request. This is sort of a Trojan horse method to get the target to execute potentially damaging code.
This attack does not necessarily have to overwrite the header of the overall packet. There are other bugs within the packet reassembly process that can be exploited as well. The basic issue is to find a way to have the packets compromise the processing capability of the target and cause it to crash. Teardrop and Newtear are examples of such attacks and are also discussed below.
Client OS: Available as C code (specified for the Linux environment)
Target OS: Windows 9x/NT/2000 (NT up to Service Pack 6)
Description: Jolt2 is an IP fragmentation attack that uses either ICMP or UDP traffic. The command to execute Jolt2 is straightforward:
#> ./jolt2 –s <srcIP> –p target_port target_IP
Jolt2 allows you to specify a target port and the target IP address. If a port is specified, Jolt2 will send UDP traffic to that port, and if no port is specified, Jolt2 will send ICMP traffic.
We should express one note of warning with Jolt2. It can occupy up to 50 percent of the tester's own CPU. When we used Red Hat Linux version 6.2 running on a 266MHz Intel P2 processor with 128MB of RAM, it took up 50 percent of the CPU. However, the target was slowed significantly in a matter of tens of seconds. When testing Jolt2, we recommend using two instances of the attack from two separate machines.
A modification of Jolt2, Jolt2mod, has the same basic operation but employs rate limiting. This is also an effective DoS tool, but we recommend using several strings of this attack for it to be most effective. While Jolt2 claims to allow IP address spoofing and even allows users to enter a fake IP address in the command line, it does not actually spoof the IP address.
Another side note: If your target is a Web server, there is a good way to check to see whether the DoS attack is affecting the target. View the target through the Web browser. As the DoS attack starts to take affect, it should take longer and longer to load the Web pages stored on that server.
Though still potentially vulnerable, installing Windows NT Service Pack 6 or higher helps defend against this attack.
Client OS: Available as C code (specified for the Linux environment)
Target OS: Windows 95/NT (possible), Caldera Linux version (prior to 2.0.32); some older versions of Sun and NetBSD may also be vulnerable to Teardrop.
Description: Teardrop was originally designed to target Windows 95 hosts, but it has been known to affect some older versions of NT and several versions of Linux as well. While many systems are now patched against Teardrop, we mention it because of its position in history as one of the original IP fragmentation attacks on which several newer attacks are based. Its command structure is:
#> ./teardrop <srcIP> <target_IP> [-s src_prt] [-t target_prt] [-n number_of_packets]
It is not necessary to select source or target ports; they will be selected at random. Teardrop exploits bugs in the fragment reassembly process through which, while attempting to reassemble received fragments, the target's buffer is filled up, leading to its crash. Keep in mind, as previously mentioned, you don't want to send out more packet fragments than necessary. Sending out too many helps your activities get caught and can slow down your own box. Teardrop attacks have been known to be thwarted at border firewalls.
Client OS: Available as C code (specified for the Linux environment)
Target OS: Windows 95/NT
Description: Syndrop is a modification of Teardrop that exploits Microsoft's SYN sequence number bug. Also, this attack uses TCP rather than UDP. Syndrop features the same execution command structure as Teardrop.
#> ./syndrop <srcIP> <target_IP> [-s src_prt] [-t target_prt] [-n number_of_packets]
In our experience, exploiting Microsoft's SYN sequence number bug does add to the attack. However, this is also an attack that can be intercepted at the firewall or border router.
Client OS: Available as C code (tested on Linux)
Target OS: Windows 95/NT and several Linux kernels
Description: This is a modification of the original Teardrop DoS tool and representative of the second type of fragmentation attacks.
Again, the execution command structure is the same as that for Teardrop and Syndrop.
#> ./newtear <srcIP> <target_IP> [-s src_prt] [-t target_prt] [-n number_of_packets]
There are not significant differences between Newtear and Teardrop. The primary modifications are mentioned in the header of the commonly available version of the attack file. Specifically, the attack reports a larger-than-actual UDP length. Similar to Teardrop, this attack can also be intercepted at the firewall.
As systems have increased their processing capabilities over time, adding memory and processor capability, performing DoS attacks has also required additional resources. Further, individual machines can have trouble generating the necessary traffic to perform a successful DoS attack. Therefore, hackers have in corporated multiple hosts into the fold. Multiple hosts simultaneously performing an attack on a target(s) is termed a distributed denial-of-service (DDoS) attack.
DDoS attacks are quickly becoming more and more common as many networks and service providers move toward load-balanced, Web server farms with each individual server having a great deal of capacity and redundancy solutions. Using multiple hosts is a natural modification to these countermeasures. The trick, of course, is to find multiple machines, get them to take part in an attack, and then coordinate the whole operation.
DDoS attacks generally involve a controlling authority (hacker) in one location with many “zombie” machines that perform the actual DoS attack. A daemon or an agent resides on the zombie machines and carries out the will of the controlling authority, thus the name “zombie.” To further distance the hacker from the attack, zombies are controlled not directly but through intermediary devices, often called clients, that simply relay commands from the hacker to potentially multiple zombies.
These zombies and intermediary devices can really be placed anywhere on the Internet, as long as the machine is under the control of the hacker and has a high-speed Internet connection. Contrary to popular belief, this does not always have to be UNIX machines on university campuses (though they are common targets). Many corporations are concerned only with filtering incoming traffic and allow outbound traffic to pass through their firewalls unabated. Daemons can be effective when placed on UNIX or Windows machines on such a network, where they will be able to endlessly transmit packets. As a side benefit, the target will then think the DDoS attack is originating from the infected company or university, rather than the true hacker. In such a scenario, not only has the infected network been made an unwitting accomplice, but it is also more difficult to trace the attack back to the actual hacker. Another common target for use as a zombie are personal computers connected to the Internet through DSL or cable modems. Often these systems are neither protected by firewall software nor configured with security in mind. Users frequently leave these systems connected to the Internet all the time, making them easy targets for hackers. Figure 21-1 illustrates a possible DDoS scenario.
We discuss a few of these DDoS attacks that have been gaining popularity and a bit of press recently, namely Tribe Flood Network 2000 (TFN2K), Trin00, and Stacheldraht. These attacks are considered cousins due to their similarities and are believed to be the DDoS attacks successfully launched against Yahoo, Amazon.com, eBay, and other sites in early 2000.
Client OS: Available as C code for the UNIX environment
Target OS: TCP/IP networks
Description: TFN2K is a modification of the UNIX-specific Tribe Flood Network (TFN) DDoS attack that now also works on the Windows environment. This attack features a client (the intermediary device) that sends messages (which include the identity of the target) to various daemons (zombies). These zombies then carry out the actual attack by flooding the specified target with TCP/SYN, UDP packets, ICMP ping, or Smurf (broadcast ping) traffic.
One TFN2K client can work with numerous zombies all focused on the same target, thus making this a DDoS attack. The zombies can be located on different networks all across the world. Often the TFN2K client is located on a network separate from any of its zombies. (It is also possible to conduct a DDoS attack on multiple targets at once by splitting up the zombies between the targets.)
TFN2K is a sophisticated DDoS attack. A client sends out packets designed for zombies, instructing them which type of traffic to use. They can even alternate between all types. In order to remain inconspicuous, each zombie is silent, meaning it does not reply to or acknowledge the client's message; therefore, the client issues the commands up to 20 times in the hopes that one will reach the zombie. This is a modification over previous versions. Further, the client sends decoy packets to random IP addresses between actual instruction packets destined for the zombies. Communication between the client and all zombies is encrypted with a key-based CAST-256 algorithm as defined in RFC 2612 and is transmitted under spoofed IP addresses. The key serves as a password and is generated when the client is compiled.
Zombies are capable of running under a spoofed process name by manipulating the contents of the argv[0] variable. This makes detecting the presence of the zombie by looking at all the processes running a bit more difficult.
The effect of the attack, if successful, is that the target host is flooded with traffic and eventually crashes.
The best defense against TFN2K is, of course, to not have a machine on your network become infected and turned into a zombie. However, in the event that your systems have become infected, there are some steps you can take. Attacks are carried out by child processes spawned by the TFN2K zombies. The daemons attempt to hide the process name by making it difficult to identify through analysis of the process list. Still, comparing the process list of two machines (one possibly infected and one clean) during an attack may allow you to identify the child process. Also, by comparing the process list of the potentially infected machine during times when you think a daemon is conducting a DDoS attack and a “normal” time may also help. Further, there are a few signatures within TFN2K packets. These include a TCP header length field that is always set to zero and a UDP packet length field set to a value of three greater than the actual packet length. Both the UDP and TCP checksum values are incorrect in all TFN2K packets.
Identifying and locating TFN2K clients and daemons on your machines is possible but may be difficult. Default client files are under the name tfn while daemons are called td. However, these names can be changed by manipulating the source code. There are a few identified strings that appear within the files; chief among these are security_through_obscurity (both tfn and td) and tribe_cmd (only td). There are additional strings as well. We hesitate to present them here since there is a likelihood that they can be modified by a hacker using this tool, and they will likely be modified in future releases of this DDoS tool.
Client OS: Available as C code for the UNIX environment
Target OS: TCP/IP networks
Description: The Trin00 DDoS tool is generally targeted toward the UNIX OS, but it does have Windows versions as well. Trin00 features the same basic, three-tier architecture as TFN2K, however the language used to describe the components is different. In Trin00 terminology, hackers control masters who then control the actual zombies, called broadcast or bcast daemons, who carry out the attack. A hacker can control multiple masters, each of which can control multiple bcast daemons.
Although Trin00 is similar to TFN2K, one of the key differences is that bcast daemons do respond to masters, letting them know that they are alive and also responding after successfully receiving commands. Another difference is that Trin00 attacks send only UDP packets, of configurable size and on random ports, to the target host(s).
Masters and daemons are password protected so that a Trin00 network does not fall under the control of a different hacker. However, when initially beginning communication, these passwords may be transmitted in clear text, somewhat diminishing the value of this feature.
The effects of Trin00 can be similar to TFN2K in that a successful attack floods the target to the point where it crashes.
The Trin00 Trojan has been known to be called service.exe, but it can be easily renamed.
There are default ports and passwords used for communication between the various components. However, these can be changed in practice with modifications to the Trin00 source code. Attackers communicate with masters over TCP port 27665 and use the password “betaalmostdone.” Masters themselves are started with the password “g0rave.” Masters communicate via UDP port 27444 to daemons and use the password “144adsl.” Daemons reply to masters over UDP port 31335. These ports can be closed and/or monitored for unauthorized usage. One note of warning: since these ports can be changed by knowledgeable hackers, the fact that no traffic is passing over these ports is not necessarily a reliable indication of no Trin00 activity. If you sniff all the traffic on your network, you can look for these passwords. They will appear in clear text during a Trin00 attack.
The Zombie Zapper software from Bindview can look for and delete Trin00 zombies from your network. If you suspect that you have been infected with this DDoS attack, we strongly recommend that you make every effort to purge your network of this infestation.
Client OS: Available as C code for the UNIX environment
Target OS: TCP/IP networks
Description: The Stacheldraht DDoS attack is built on the original TFN code and bears a resemblance to Trin00 as well. As in TFN2K, attacks can be performed with TCP/SYN, UDP packets, ICMP ping, or Smurf (broadcast ping) traffic. As with both TFN2K and Trin00, Stacheldraht features a three-tier architecture. In this case, the names of the various pieces are again different. Hackers communicate through encrypting clients to handlers, who instruct the agents, which ultimately conduct the attacks. (This terminology is courtesy of the CERT, but different terminology has been used in the Stacheldraht code. Of course, the names that appear in the code can also be easily changed by a hacker.) Each handler can control up to 1,000 agents; in fact, this value has appeared in the code. While it too can be changed, there is evidence, found in comments within the code, that this may be more consistent.
Communication with the handlers is through encrypting clients, who accept as input the IP address of the handler and send an encrypted message to the handler's address. It then requests a password (the default is “sicken”), and if correctly entered, the hacker has access to the Stacheldraht DDoS network. Communication occurs over a telnet, rlogin, or other such connection on TCP port 16660. Again, in an effort to be undetected, handlers can be located on different networks and machines than those directly under the control of the hacker.
Upon a successful connection, the handler informs the attacker how many agents are currently active and how many are not listening.
Communication between handler and agent is conducted over TCP port 65000 and with ICMP ECHO_REPLY messages. It is further encrypted with the blowfish encryption algorithm and password protected with a password generated by the crypt() algorithm. The default passphrase used for this encryption is “authentication.” Again, we present these defaults only for edification since they may change with modifications to the code. In fact, the code allows users to alter various settings, such as the target port ranges for the SYN flood, the UDP and ICMP packet size, and the port over which to bind the root shell.
Unlike TFN2K, Stacheldraht agents do communicate with their handlers. On start-up, agents send an ICMP ECHO_REPLY message to each handler that may potentially control them. The IP addresses of default handlers are included within the agent source code. This message contains a 666 in the ID field and the string skillz in the data field sent from the agent to the handler. The handler then replies with an ICMP ECHO_REPLY message with an ID of 667 and a data string of ficken. These messages, if the network allows, use spoofed source IP addresses.
A possible means of detection lies in the agents/handler communication over ICMP messages. These messages are in the clear and reveal the IP address of the agents. While attempting to ascertain whether or not IP spoofing will be successful on the particular network, the agent will send an ICMP ECHO_REPLY message with an ID of 666 and a default source IP address of 3.3.3.3 along with the agent's actual IP address within the data field to the handler. If spoofing is successful, the handler will receive the packet and reply with an ECHO_REPLY of their own with the phrase spoofworks in the data field (and an ID of 1000). Such unencrypted communication can allow Stacheldraht to be discovered. However, we strongly recommend using Zombie Zapper (mentioned in Section 21.5.2) and vigilantly blocking all unnecessary ports.
The best defense overall for a network under a DDoS attack is to employ load balancing and redundancy to withstand the amount of traffic that is generally sent during a DDoS attack. Further, having a secure firewall that effectively blocks unwanted traffic will be helpful, as will running the latest releases of all operating systems and applications running on the network. Periodically looking for the client zombies that conduct such attacks with the appropriate Zombie Zapper software will help speed detection and eradication of the zombies.
In the interest of space, we will walk through the usage of one of these tools, rather than all three. As mentioned above, they are similar. Once you get the hang of one, you should be pretty comfortable adjusting to another. We discuss the Stacheldraht DDoS tool. The fact that we discuss Stacheldraht should not be seen as an endorsement of this tool over either of the other two.
To run any of these DDoS tools, you first need to identify machines that will serve as clients/masters/handlers, those that will act as zombies/daemons/agents, and those that will serve as targets. It is one thing to have a few test machines within your own network act as targets, but we certainly do not recommend or suggest testing your skills with DDoS tools on live systems, your own or those of other companies.
Once you have identified machines to act as the necessary components, download the DDoS tool of your choice and compile the relevant pieces on the relevant hosts. Stacheldraht is developed for the Linux and Solaris operating systems. The code contains Makefiles for the client, handler, and agent components and can be compiled with either gcc or cc.
Before compiling the code, we recommend going through it and editing it for your purposes. First, ensure that all specified ports are open, or change the defaults to known, open ports. Second, change the passwords from the defaults to those of your own choosing. We also recommend changing the default master servers (handlers) in the agent code, td.c, to the IP addresses of the handler(s) you will use.
Depending on how much you want to be able to avoid detection, you can endeavor to make additional changes to the code. Changing the default IP address, 3.3.3.3, used when determining whether IP spoofing will be successful, is a good idea. Remember, the changes need to be coordinated in all pieces of the code.
Once all the pieces are in place, connect to the handler through the client with the following command:
#> ./client <IP_address>
You will be asked for the passphrase (the default is “sicken”), and upon entering it, you will be at the Stacheldraht prompt. The initial prompt will also show you how many agents are currently listening. Stacheldraht comes with a help function which lists the available commands.
For instance, an ICMP ECHO_REPLY attack can be launched against internal address 172.25.5.4 with the command:
Stacheldraht> .micmp 172.25.5.4
SYN flood attacks on ports 20 through 7000 can be launched against 10.10.10.45 with the commands:
Stacheldraht> .sprange 20-7000 Stacheldraht> .msyn 10.10.10.45
All DDoS activity can be stopped with the command:
Stacheldraht> .mstop all
Let us make our warning once again. Feel free to use these tools against your own noncritical systems. However, any experimentation of these tools on critical systems and/or systems belonging to other people can be seen as an illegal act and is strongly discouraged.
The attacks in this category are targeted toward individual applications rather than hosts. Any representative sample of the DoS tools in existence today will reveal that there are DoS attacks for almost any application that has any kind of widespread use, including, but not limited to, mail servers, DNS servers, Web servers, firewalls, and routers.
As DoS attacks have started to target individual applications and services, it does raise the question of what resources are being exhausted. Generally, when targeting a host system, the goal is to force CPU usage to reach 100 percent. When a particular application is being attacked, one can simply occupy the memory or buffer space attributed to that application or send it more data than the application is capable of processing. Further, it is possible to cause an application to stop working without exhausting its available resources but by exploiting a bug within its code. We illustrate several examples of this below.
We look at tools targeting specific applications in this section since sometimes our clients want to maintain a particular application and ask us to evaluate their vulnerability to DoS attacks.
Client OS: Windows executable on Windows 95/NT/2000
Target OS: Windows 95/NT and several Linux kernels
Description: A popular way to perform a DoS attack is to take down an e-mail server. A significant period of time can pass before an e-mail server comes back up and e-mail is correctly processed (received/sent) again. Also, e-mail has become such an important part of our professional and personal lives that losing it affects everyone in the organization.
Up Yours has a Windows-based GUI that is packed with configuration and usage information (especially the configuration screen, shown in Figure 21-2).
Virtually every component of an e-mail can be configured. It allows you to send multiple (fake) headers from a fairly large collection of e-mail headers (under the X-Mailer setting tab). In addition, the subject, e-mail text, and recipient(s) can be configured by editing the subject.txt, insults1.txt and insults2.txt, and hatelist.txt files, respectively. The target can also be specified through the GUI directly. The tool is distributed with a list of servers through which e-mail is bounced to help avoid detection. An attacker would have to check this list (servers.txt) to ensure that they are still up. However, we recommend that you go further and use servers that you know are usable.
These configurations can also be performed by selecting the appropriate listing under the Settings pull-down menu. The Advanced option pulls up the Settings screen, seen in Figure 21-3
On this screen, the number of active windows within the program conducting the actual mail bombing (under the General tab) can be configured. The maximum is ten. The various e-mail headers can be selected under the X-Mailer settings tab. Under the Advanced Settings tab, servers through which e-mail is routed can be selected. Finally, under The Good Stuff tab, an option, Use the mass mailings, will send each e-mail to each recipient the specified number of times. This option can magnify the potential damage Up Yours can cause. This tool should be used in a controlled environment.
Client OS: Available as C code for the UNIX environment
Target OS: Windows 95/NT
Description: This DoS tool focuses on crashing WinGate proxy servers. WinGate is a proxy server firewall that allows multiple computers to share one or more Internet connections.
#>./wingatecrash <target_IP> [port]
The default port is the telnet port, TCP port 23, and does not need to be specified.
Client OS: Windows executable
Target OS: Windows 95/NT
Description: WinNuke is a local or remotely executable DoS attack that uses the out-of-band (OOB) bug in Windows 95/NT to crash the target hosts. This attack, available as a C program, winnuke.c, sends packets with the OOB flag set but without any data following the flag. Unpatched boxes do not know how to handle such packets and therefore crash. NetBIOS connections over port 139 are specifically targeted for this.
Unlike DoS tools that attempt to flood the target with traffic (which is both the original style of DoS attack and still the most popular), WinNuke is among the class of DoS tools that attempt to crash the target system with an individual packet (or a small group of packets). This is done (if it works) by creating and sending packets that the target server or application cannot properly handle. This results in confusion in the target server or application and leads to a crash.
WinNuke is available as both C and Perl scripts for various UNIX flavors, as well as an executable file for the Windows OS. The executable allows you to enter the target IP address as well as a message that you can send the target.
This is an old attack for which Microsoft has released a patch. However, it is representative of this kind of attack and has been known to be quite effective and popular, especially with script kiddies.
Keeping current on the patch level and blocking all unnecessary ports at the firewall are the recommended countermeasures for WinNuke.
Client OS: Windows executable
Target OS: Windows 95/NT
Description: BitchSlap is another DoS tool that exploits Microsoft's OOB bug. It is available as an executable that, when performed, pops up a window requesting only a target IP address. It is very easy to find on the Internet and even easier to use.
The countermeasures for BitchSlap are the same as those for WinNuke.
Client OS: DOS command line, executable from Windows 95/NT/2000 boxes
Target OS: Windows 95/NT
Description: This tool is fairly old, but we mention it since it is representative of the very script-kiddy-friendly DoS tools that are easy to find on the Internet today. DOSNuke is simply an executable that allows users to attack a Windows 95/NT system. It asks for only one command in which users can specify the target IP address, port (the default is 139), the number of attacks (default, 10), and the number of packets per attack (default, 1024). The syntax is simple:
#> Dosnuke /Pport_number /Ttarget_IP /Nnumber_of_attacks /Sbytes/attack
This is easy to run but old and may not be as effective as it once was. But more new tools are modeled after this style of DoS tool than one may wish on the computing public.
Client OS: Available as C code
Target OS: UNIX syslog version 1.3 daemons
Description: Shutup is a script that attempts to overload a syslog daemon by opening so many socket connections (up to 2,000) to /dev/log that syslog cannot respond. This script attacks the local host and therefore only needs to be compiled and executed. It doesn't require root-level permission.
This tool is fairly representative of the kinds of DoS attacks written for UNIX daemons. It basically overloads the target's ability to keep up with demand.
Buffer overflows can be used to cause DoS conditions in place of executing the hacker's egg. Popular targets of such buffer overflow DoS attacks in today's Internet economy are IIS Web servers. These attacks do not necessarily require executable tools or scripts; they may simply require the attacker to send particular input strings in order to work.
Several such exploits have been discovered in the history of Microsoft's IIS Web server application. For example, IIS 3.0 and 4.0 running on Windows 95/98/NT4.0 with Service Pack 4 have been known to be vulnerable to a DoS attack through their FTP server. Those with access to the FTP server (which may be any user if anonymous access is allowed) can cause DoS condition in the IIS Web server by sending approximately 400 characters after the 1s command. (This exploit has been known to work with as few as 316 characters after the ls command.) This occurs because the FTP and IIS servers both use the same DLL.
The process is to connect to the FTP server and issue the following command:
ftp> ls xxxxxxxxxxxxxxxxxxxxxxx . . .(up to 400 characters)
This leads to the buffer overflow knocking out the DLL, which leads to the DoS condition in the Web server.
This is not the only way to attack a Microsoft IIS Web server. The following method of sending multiple characters after the Host command has also been reported to crash IIS (version 4.0 specifically).
Get / HTTP/1.1 Host: xxxxxxxxxxxxxxxxxxxxx . . . (over 200 bytes)
(Enter the above line multiple times.) This can be done over telnet sessions to the Web server on port 80. The exact number of times the Host line must be entered is not known. It is left as an exercise for the reader.
As a security measure, SSL can be an effective way to augment the security of the information on a Web server. However, certain implementations of Microsoft IIS 4 and IIS 3 running on Windows NT are susceptible to a DoS condition by simply replacing the http portion of a URL with https. The bug in these Web servers is that they do not differentiate between secure pages and insecure pages. Given an https request, the server will encrypt the page. This leaves open the possibility that by requesting a sufficient number of https requests for public pages, the encryption overhead can bring the server into a DoS condition.
These attacks are results of bugs within IIS and not necessarily a reflection of the network involved. There are other DoS tools that also make use of bugs rather than networking issues.
The best countermeasure for this DoS attack is to maintain the latest service patches and security patches for both the OS and IIS.
Commercial scanners, such as CyberCop and ISS, check for a target's susceptibility to a collection of DoS conditions. While it is unusual to have clients willing to allow DoS testing, they are more amenable to allowing a commercial scanner to check for DoS vulnerabilities because CyberCop and ISS are intended for network and host scanning and are not seen as hacker tools. Even with these tools, the testing should be coordinated for nonproduction hours since the tests can invoke actual DoS conditions.
Client OS: Available for Windows NT/2000 and UNIX versions
Target OS: A variety of operating systems
Description: This is a commercial product that, in version 5.5, claims to perform over 40 DoS attacks, including the land attack, the ping attack, and various Windows NT attacks, such as an IP fragmentation attack, and an OOB attack. It also checks for DoS conditions in Cisco Web front ends, Ascend routers, Solaris syslog daemon, certain versions of sendmail, and a host of others. All available attacks can be run simultaneously or individually by the scanners. (How to use the scanners and select attacks was discussed when these tools were presented in Chapter 11.) The tool presents a description of the attack as well as suggested countermeasures, as seen in Figure 21-4
When running DoS attacks, we recommend doing them alone, after you have performed any other scanning that you may want to do. Thus, if any of your DoS scans truly work and the target systems must be taken offline and rebooted, you will not have missed the chance to get the other information you want.
Client OS: Available for Windows NT/2000 and UNIX versions
Target OS: A variety of operating systems
Description: As does CyberCop, Internet Scanner scans hosts to determine whether they are susceptible to a variety of DoS conditions and attacks. Version 6.1 contains 74 attacks, with many in common with CyberCop. Internet Scanner does seem to provide more background information on the attacks than CyberCop and they do a better job of categorizing the attacks, by target, for example, DNS servers, FTP servers, firewalls, and so on. Internet Scanner also provides descriptions and countermeasures (Remedy) for the DoS attacks, as seen in Figure 21-5
The usage of these tools is presented in an earlier chapter. We mention them here to make readers aware of the DoS capability of these commercial scanners that are likely going to be a part of a consultant's bag of tools.
In addition to these scanners, there are several scripts one can download that simultaneously or one by one perform multiple DoS attacks. The ability to run multiple DoS attacks at a target with a single command can be beneficial. It can be helpful in benchmarking or testing a target's resistance to DoS attacks overall or to specific types of attack. We have, at times, had clients interested in exploring their resistance to specific types of attack.
Client OS: Available as a shell script (tested on Linux)
Target OS: A variety of operating systems
Description: This is a compilation of a large number of DoS tools, including 123, Ascend-foo, Beer, Biffit, Boink, Bonk, Coke, Conseal, Dcd3c, Fawx, Foqerc, Gewese5, Ice, Jolt, Kkill, Koc, Kox, Kod, Pimp2, Land, Misfrag, Nestea, Newtear, Octopus, Orgasm, Overdrop, Pepsi, Rape, Spiffit, Ssping, Syndrop, Synful, Synk4, Targa2, Targa3, Teardrop, Trash2, Udpdata, and Winfreez. Further, it can send multiple attacks simultaneously. It is executed with the following:
#> ./toast.sh srcIP target_port | -s target_IP attack
The target port, along with the spoofed source and target addresses can also be specified. The -s option is best used with the queso option. This attack comes with an optional port scanner and queso, an OS detection tool, which together can help select the DoS attacks to use, based on the OS and open ports of the targets. The attack argument is a number selected from the following list:
1
| Syn floods |
2
| UDP floods |
3
| Port floods |
4
| Linux attacks |
5
| BSD attacks |
6
| Windows 95 attacks |
7
| Windows 98/2000/NT attacks |
8
| Automatic attack selection (Install queso, good with -s) |
9
| All attacks |
Naturally, option 9 offers the most comprehensive attack. We recommend launching a more focused attack, which Toast allows you to do by organizing the attacks in various categories. Option #8 requires queso to be installed as well. Toast is one of the more comprehensive of the multiple DoS attack tools available.
Client OS: Available as a shell script (tested on Linux)
Target OS: A variety of operating systems
Description: Spike.sh5.3 is release 5.3 of the spike DoS tool, another such compilation that includes the following attacks: 1234, Beer, Boink, Bonk, Coke, Conseal, Dcd3c, Duy, Fawx, Flatline, Gewse, Gewse5, Jolt, Jolt2, Kkill, Koc, Kok, Land, Latierra, Misfrag, Nestea, Newtear, Opentear, Orgasm, Pepsi, Pimp, Pimp2, Pong, Rc8, Smurf, Spiffit, Sping, Stream, Syndrop, Synk, Targa3, Teardrop, Trash, Udpdata, and Wingatecrash.
The attack is executed with the following command:
#>./spike.sh <target_IP>
A host name can also be entered in place of the target IP address. The individual attacks can also be run on their own. Carrying a few of these group DoS attack tools in your tool kit is a good way to maintain a large and current collection of DoS tools. Though we use DoS only rarely, it is good to keep a set of attacks close at hand.
With these concatenated DoS tools, the countermeasures of each of the individual DoS must be installed. This is what makes these tools so effective.
There is one final point that we would like to mention. It is quite possible that when hackers launch DoS attacks against Web servers, mail servers or other machines located behind a firewall, that the firewall will fall victim to the DoS rather than the intended target.
Often system administrators consider this just as deadly a consequence and overlook the difference. While it certainly is bad for your firewall (or other border device) to go down due to a DoS or any other reason, it is better the perimeter defense machine go down than the hosts it is protecting. In such a scenario, the internal hosts and their data and resources have been taken off-line rather than compromised.
This is not a desirable situation, but can be remedied by rebooting the firewall (or switching to a back-up firewall). When systems are compromised, backup recovery methods must be taken, which are often more complex and time consuming. And they do not address the potential for loss to the organization if sensitive information has been released to the public.
Additionally, having the DoS land on your firewall, DMZ or honey pot allows the system administrator (if they are monitoring the network) time to respond before the hacker reaches their ultimate target, the truly valuable corporate data and internal hosts. The firewall can be rebooted, the servers can be taken off-line, and countermeasures can be enacted. We do not want our defenses to go down, but rather they than the assets they protect.