Summary

Most of the time, you will find that relying on tools such as Ethereal to decode packets is accurate and pain-free. Ethereal comes with a great GUI interface that allows you to drill down to fields and interpreted values. But, a very rare occasion will arise when more conventional tools are either not available or do not accurately interpret the packet. When you encounter such a situation, you do not want to be intimidated by looking at a nasty hex dump.

Just remember to approach it methodically. You need to get a standard layout for the protocol or header or fields that you want to examine. Then, make sure that you discover the embedded protocol that follows the IP header. Calculate the length of the IP header remembering that the value you find in the IP header field must be multiplied by 4. Then, look at the embedded header and determine the pertinent values in it. Using this approach, you should be able to decipher any hex dump you are given.

Chapter 8. Examining IP Header Fields

This is the first of two chapters that examines fields in the IP packet. This chapter focuses on fields in the IP header, whereas the following chapter looks at fields in the embedded protocol (TCP, UDP, and ICMP) headers. As we continue our journey of looking at traffic from many different perspectives, another view we can assume is to look at the functions of fields in the headers and normal and abnormal values found in those fields. If we are familiar with the purpose of the fields and acquainted with normal values, we should be able to detect mutant or malicious values. When you begin to look at NIDS output or even TCPdump output on a regular basis, this knowledge will come in very handy for detecting problem packets or identifying the nature of malicious traffic.

Insertion and Evasion Attacks

Before we look at individual fields in the IP header, we'll make a digression about types of attacks that might thwart a NIDS' capability to detect malicious activity. As we examine fields in the datagram, we will reference possible insertion or evasion attacks that may be done by manipulating certain field values.

There is a landmark paper written in 1998 called "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection." The authors Thomas Ptacek and Timothy Newsham discuss attacks that can elude detection by the NIDS by using methods of sending traffic that will cause the NIDS and the destination host to interpret packets differently. The paper is an excellent treatise of different conditions that can cause a NIDS to improperly analyze potentially malicious traffic. The authors conducted several different tests against NIDS to prove their theory.

Along with the denial of service of a NIDS, the paper basically discusses the idea of individual attacks to confuse the NIDS. The first is known as insertion. This is where the attacker sends

traffic to a target destination host. One or more of the packets sent is accepted or seen by the NIDS, yet it never reaches the destination host; or if it does, the destination rejects it as faulty. The point that the authors make is that the NIDS and the destination host evaluate traffic differently or perhaps even see different traffic.

A second attack is known as evasion. This involves the same idea of sending traffic to a target destination host. Although the destination host sees the same traffic that the NIDS does, it scrutinizes the packets differently than the NIDS. Perhaps the NIDS rejected one or more packets, but the destination host accepted them. Again, the NIDS and the destination host see the traffic differently. Although the term reject brings up some semantic issues especially when compared with actions of packet-filtering devices, it is the terminology used in the paper itself. An evasion attack is successful because the NIDS fails to analyze the packet or data in the packet as the destination host does, allowing the destination host to see a packet or data that

the NIDS does not.

Insertion Attacks

Examining how an insertion attack might work, let's say we have a NIDS that is on a different network, such as the DMZ, from many of the hosts that it is guarding. Further, let's also say that the NIDS is looking for signatures that might indicate some kind of problem or notable traffic. One of those signatures might be to look for traffic to telnet, TCP port 23, with a content of REWT as a sign of some backdoor account to telnet.

Now, we have an attacker who has remained undetected in planting a Trojan telnet on a target host and now wishes to log in to that host using the REWT account. The attacker has done some reconnaissance on our network and knows more about the network topology and behavior than we care for him to know. It is possible for the attacker to elude notice of the NIDS if he can make the NIDS accept a packet that the end host will not accept or will never see.

In Figure 8.1, the attacker sends three different packets destined for TCP port 23 of the target host, each with one or more characters in the payload. The first contains the letter R, which both the NIDS and the end host receive, examine, and accept. A second character of O is sent that has a bad TCP checksum. Checksums validate the integrity of the packet and if they are not correct, the packet should be discarded. Let's say that the NIDS sees this packet, is not programmed to validate the TCP checksum, and blindly accepts the packet as a valid part of the stream of characters being sent to the destination host. The destination host receives the packet, validates that the TCP checksum is incorrect, and discards the packet. The attacker has managed to insert a character that causes the NIDS to fail to recognize a real attack or action against the end host. Finally, a third packet is sent with a payload of EWT that both the NIDS and the destination host receive and accept.

Figure 8.1. A sample insertion attack.

The NIDS has assembled the TCP stream and concludes it is not a threat because the NIDS does not have a signature for TCP port 23 with a content of ROEWT. Yet, the destination host reassembles this stream as REWT and happily starts a telnet session with a user of REWT that is undetected by the NIDS. Note: This is an oversimplified discussion of this attack; TCP sequence

numbers need to be synchronized correctly for this to work properly.

Evasion Attacks

In the case of evasion depicted in Figure 8.2, the destination host sees or accepts a packet that the NIDS rejects. In this case, we are still looking for a telnet session with user REWT to the target destination host. If the attacker can send the traffic in such a manner that the NIDS rejects a packet that the end host accepts, this eludes detection.

Figure 8.2. A sample evasion attack.

A possible scenario for this attack is sending data on the SYN connection. Although not typical of normal connections, sending data on SYN is valid per RFC 793. The data on a SYN connection should later be considered part of the stream after the three-way handshake has been completed. Let's say we have a first packet that arrives on the network with a SYN packet destined for TCP port 23 of our target host. It has a payload of R in the SYN packet. The NIDS only looks for payload after the three-way handshake has been completed, so it totally misses that data. The destination host receives the same packet and knows to store the R for the stream after the three-way handshake is completed. We then have the packets that complete the three-way handshake, each with no data in them, as expected. Finally, we have a normal packet with the letters EWT as the payload destined for the target host TCP port 23.

The result is that the NIDS reassembles the TCP stream for destination host port 23 with a complete payload of EWT. This doesn't match any signature it knows. The destination host, on the other hand, reassembles the stream as REWT and happily starts the Trojaned telnet session.

To summarize the paper mentioned earlier, there are many techniques that can be used for insertion and evasion attacks against a NIDS. Although the paper doesn't cover application layer attacks such as HTTP obfuscations, we find that application attacks are a growing trend in evasion. Many of the various attacks are successful just because the NIDS cannot predict the reaction of every possible destination host's TCP/IP stack to various attacks. There are many facets of the TCP/IP stacks that differ among operating systems.

Although keeping track of a lot of this information is feasible for the NIDS, understand that as you require the NIDS to perform more functions and duties, the NIDS will become slower in processing all traffic to the point where it might begin to drop packets. Ultimately, it is a tradeoff of functionality and speed, and speed is the current winner. One way to deal with the possibility of evasion or insertion attacks is to install a host-based IDS on resources that require more protection or scrutiny. The host-based IDS sees the same packets that the host sees, but this is as far as its resistance to evasion goes. The host would still need the application-level savvy to handle application-based evasion attacks.

This paper can be found at: www.robertgraham.com/mirror/Ptacek-Newsham-Evasion-98.html.