Malicious Fragmentation

There is no rest for the weary analyst when it comes to malicious fragmentation. Fragmentation, it seems, has provided a field day of play and plunder for the hackers, and they have produced a bevy of attacks.

This advice is repeated for other protocols and at other times in this book, but be especially alert and watchful when analyzing fragmentation. Some of the best analysts I know have been mockingly accused of paranoia by envisioning everyone attacking their networks in every different way. Well, I would like to invite you to join the misfits' bandwagon of paranoia when it comes to fragmentation. If your IDS cannot be tuned to give special scrutiny to fragmentation, you might be missing a chunk of the action. If your IDS can correctly maintain state, reassemble fragments, and then make some kind of intelligent assessment, you appear to be well-armed.

One of the most infamous denial-of-service attacks associated with fragmentation, Ping of Death, is discussed in Appendix B, "Denial of Service." The next sections examine a couple of other fragmentation attacks.

TCP Header Fragments

nmap is an excellent scanning tool that runs on many UNIX platforms and is available from www.insecure.org/nmap. It does conventional port scanning to discover what ports are open on a target host and does stealth scanning that looks for open ports, but also makes an attempt to elude detection by intrusion-detection systems. An nmap command-line option (-f) fragments the 20-byte TCP headers in multiple fragments in an attempt to avoid detection. The following TCPdump output was generated using the command:

nmap -f -sS -p 53 target.com

This sends a fragmented SYN connection to port 53 of target.com:

truncated-tcp 16 (frag 25096:16@0+) fragger.org > target.com: (frag 25096:4@16) truncated-tcp 16 (frag 4265:16@0+) fragger.org > target.com: (frag 4265:4@16) truncated-tcp 16 (frag 34927:16@0+) fragger.org > target.com: (frag 34927:4@16)

The preceding TCPdump output shows a scan that fragmented the TCP header. This is a scan from fragger.org that scanned port 53 on target.com using a standard TCP SYN request. This is not obvious, however, because of the small fragments involved.

Looking at the first line of data, you see a fragment with 16 bytes of truncated TCP data. The

minimum TCP header is 20 bytes with no options. Because this is not a complete TCP header, TCPdump reports this as truncated-tcp. In the next record, the additional 4 bytes of

TCP header are sent. It is possible that an intrusion-detection system might not capture or report this kind of stealth scan.

Teardrop

Now that you are familiar with the way fragmentation should work, take a look at the following TCPdump output. See if you can detect a problem with the fragmentation generated by a malicious program known as Teardrop:

evilfrag.com.139 > target.net.139: udp 28 (frag 242:36@0+) evilfrag.com > target.net: (frag 242:4@24)

The first fragment delivered is a UDP datagram that has a fragment ID of 242, a length of 36 data bytes, and an offset of 0. This is represented in Figure 3.10 by the patterned rectangles. It spans bytes 0 through 35, inclusive.

Figure 3.10. Teardrop fragment mutation.

Now, the second fragment comes along. It is associated with the first fragment because of fragment ID of 242, it has a length of 4, and it begins at an offset of 24 bytes into the data portion. It is depicted in Figure 3.10 in the solid color in the middle. As you can see, it actually overlaps bytes 24 through 27 of the first fragment.

The Teardrop attack exploits weaknesses in the reassembly process of fragments. The Teardrop program creates fragments with overlapping offset fields. When these fragments are reassembled at the destination host, some systems will crash, hang, or reboot. This attack was first reported in 1997, yet it provides a good example of how malformed fragments can wreak havoc on a target host.

A malformed or an incomplete set of fragments still presents problems for some hosts. More recently, a program known as Jolt2 that will be discussed in more detail in Chapter 5, "Stimulus and Response," can cause a denial of service via resource starvation simply by repeatedly sending a non-zero offset fragment to Windows hosts as recent as Windows 2000.

So many problems exist because hosts, routers, and intrusion-detection systems have to deal with many aspects of fragmentation. First, they have to make sure that all the fragments in a fragment train are received. Second, they have to make sure that they are properly formatted—none may overlap—and in aggregate, they may not exceed the maximum datagram size of 65,535. Finally, they must check that no shenanigans are attempted by fragmenting protocol headers. This is a tall order because it requires fragment reassembly and detection of mutations. To do this correctly, this requires a commitment of memory and allocation of CPU power, and if not implemented correctly, it can cause denial of service or other problems.