as one of the conditions for which no ICMP reply should be generated.

Figure 4.2. ICMP error message format.

It is also useful to be aware that not all TCP/IP stacks will precisely copy the IP header and following eight bytes. It would seem logical that the embedded information following the ICMP error message, reflecting the first 28 bytes of the offending packet, would exactly match the first 28 bytes of the offending packet. In fact, nmap can be used to discover a remote host's operating system by sending normal and aberrant traffic to a target host. It looks for responses and behavior of the target host that will distinguish it from standard expected behavior to assist in operating system classification. One test in a series of traffic to the target host attempts to send a datagram to a closed UDP port. The desired response to this is an ICMP "port unreachable" message. But, nmap examines several of the fields in the ICMP error message containing the IP header and following eight bytes of the initial probe of the UDP port. It examines these fields to see if they match the fields in the datagram that elicited the error. This information is used to determine the operating system.

Summary of Normal ICMP

In the previous sections, you examined some of the many ICMP messages that you might see while monitoring your network. You also saw many of the different informative ICMP error messages. As you noticed, these can be sent by either hosts or routers that discover a problem.

These sections also discussed the notion that some of the ICMP unreachable errors are best prevented from leaving your network if you are concerned about the reconnaissance information that could be gathered from them.

Malicious ICMP Activity

Not unexpectedly, it was just a matter of time until ICMP became tainted in purpose. Today, ICMP has been corrupted for use in many different types of denial-of-service attacks, and it has been used in a most stealthy attack as a covert channel. This section examines some of these malicious uses of ICMP.

Black Ice

As I was driving to work one wintry morning after a night of precipitation, it occurred to me that the day's commute was much like the philosophy of my job as a security analyst. I cautiously navigated the long, winding, snow-covered driveway; slowed my pace; shifted to a lower gear descending the steep hill out of the neighborhood; and safely drove around the abandoned car in my lane going uphill. I treated the identified hazards with due caution and respect, but it was the unseen dangers such as black ice that worried me.

Each day, as I analyze traffic to our sites, I have this omnipresent uneasy feeling about what it is I am not seeing—the black ice of our networks. I have seen firsthand the persistence, guile, and cleverness that the Internet pirates use to try to find and exploit what they want. As a security analyst, this "What am I missing?" semi-paranoid attitude is one you must adopt. If you become too complacent about the security of your site, your site could spin out of control from the unidentified perils.

Smurf Attack

The infamous Smurf attack, shown in Figure 4.3, preys on ICMP's capability to send traffic to the broadcast address. Many hosts can listen and respond to a single ICMP echo request sent to a broadcast address. This capability is used to execute a denial-of-service attack against a hapless target host or network.

Figure 4.3. Anatomy of a Smurf attack.

First, a malicious host must craft an ICMP echo request with a spoofed source IP to a broadcast address of an intermediate network. The spoofed source IP chosen is that of the victim target host/network. Next, the intermediate site must allow broadcast activity into the network. If it does, the ICMP echo request is sent to all hosts on the given subnet to which the broadcast was sent. Finally, all the live hosts in the intermediate network that respond send an ICMP echo reply to what they believe to be the sender, or the victim host. The victim host or network on which it resides can become choked with all the activity and can suffer a degradation or denial-of-service attack if the following conditions exist:

● The malicious user sends many ICMP requests to the broadcast address.

●The intermediate site allows inbound broadcast traffic.

●The intermediate site is large and has many responding hosts. On the other hand, many smaller intermediate sites might be used to achieve the same result.

●The target site has a slow Internet connection. To be more precise, the Internet connection must be susceptible of being overwhelmed by too many packets for the supported bandwidth. Although it is possible to inundate and clog any Internet connection given enough traffic, slower connections are more vulnerable.

Therefore, this is another reason that you want to deny broadcast traffic from entering into your network. Your site cannot be used as a Smurf amplification network if broadcast traffic is

not allowed.

Tribe Flood Network

The Tribe Flood Network (TFN) attack is another denial-of-service attack that uses ICMP for communication. Figure 4.4 depicts the attack. Unlike the Smurf attack, which originates from one source and uses one intermediate network as an amplification point, the TFN attack enlists the help of many distributed hosts, known as daemon or zombie hosts. Hence, the term distributed denial of service (DDoS) is a more accurate description of the use of dispersed hosts to participate in an attack.

Figure 4.4. Tribe Flood Network attack.

This attack requires a TFN master host and daemon hosts to be established. These are typically compromised hosts on which TFN was installed. The master TFN host then instructs the daemon hosts to attack a victim host, perhaps simultaneously. The communication between the master and daemon host is done using the ICMP echo reply. The daemons can send the target host a UDP flood, a TCP SYN flood, an ICMP echo request flood, or a Smurf attack. The master instructs the daemon what to do by sending commands in the ICMP echo reply. The ICMP identification number field in the ICMP header of the ICMP echo reply is used to direct the daemons of the action to take. The data portion of the ICMP echo reply is used to send arguments.

You might be wondering why this attack uses ICMP echo replies instead of ICMP echo requests. The reason is that more sites block ICMP echo requests because they are aware of the hazards of allowing them in the network. However, they may allow ICMP echo replies in to get responses from pings to hosts outside the network and because they don't realize the

threats posed by rogue ICMP echo requests.

As you have probably concluded, by using several distributed intermediate hosts simultaneously to flood the target host, a denial-of-service attack against the target network or target host is the anticipated outcome. If you want to read more about TFN, go to www.cert.org

and search for incident IN-99-07.

Self-Inflicted Denial of Service?

It was December 29, 1999. As I prepared to begin my stint at a Y2K center for the Office of the Secretary of Defense, I mulled over the rumors of impending cyberspace doom. The widespread consensus was that there would be massive denial-of-service attacks directed against infrastructure services such as power and transportation. Despite the hackers' promised plans of drunken celebration with the masses, the prevailing sentiment was that the release of distributed denial-of- service tools such as TFN coincided with the arrival of the new millennium.

In response to the perceived threat, many sites all but shut down or greatly restricted access to their networks. The irony of this was noted by a coworker who said, "It seems rather funny to avoid a denial-of-service attack by turning off the services yourself."

WinFreeze

The WinFreeze attack essentially causes a susceptible host to attack itself—an ugly kind of self-

mutilation:

router > victim.com: icmp: redirect 243.148.16.61 to host victim.com router > victim.com: icmp: redirect 110.161.152.156 to host victim.com router > victim.com: icmp: redirect 245.211.87.115 to host victim.com router > victim.com: icmp: redirect 49.130.233.15 to host victim.com router > victim.com: icmp: redirect 149.161.236.104 to host victim.com router > victim.com: icmp: redirect 48.35.126.189 to host victim.com router > victim.com: icmp: redirect 207.172.122.197 to host victim.com router > victim.com: icmp: redirect 113.27.175.38 to host victim.com router > victim.com: icmp: redirect 114.102.175.168 to host victim.com

The ICMP redirect message informs a sending host that it has tried to use a nonoptimal router and tells the sending host to add a more optimal router to its routing table. The WinFreeze attack can cause a vulnerable Windows NT host to suffer a denial of service by flooding it with ICMP redirect messages. This is executed on a network on which the victim host resides and purports to send ICMP redirect messages from the router. When the Windows host receives a flood of these messages, it attempts to add these changes to its own routing table and could suffer from degraded performance.

In the preceding output, the router is informing victim.com to redirect its traffic to many different random IP numbers to itself. The host victim.com might be overwhelmed when trying

to apply all those changes to its own routing table.

Loki

Probably the most subversive and destructive use of ICMP to date is known as Loki. In Norse mythology, Loki was the god of trickery and mischief. So too is the Loki exploit the master of trickery. As you have seen, ICMP is intended to be used to inform of error conditions and to make simple requests. As such, intrusion analysts prior to the release of Loki regarded ICMP as a fairly harmless protocol, except for the denial-of-service attacks generated using it and for the network mapping information it could provide if not blocked.

Loki uses ICMP as a tunneling protocol for a covert channel. A covert channel is one that uses a transport method or data field in a secret or unexpected manner. In other words, the transport vehicle is ICMP; but operationally, Loki acts much like a client/server application. If a host is compromised and a Loki server is installed, it can respond to traffic sent to it by a Loki client. For instance, the Loki client could send a request to the Loki server to cat/etc/passwd to display the password file. The Loki client user then would see the output from the display,