Chapter 8: Passive Reconnaissance Techniques - Building.Open.Source.Network.Security.Tools.Components.And.Techniques [Electronic resources] نسخه متنی

Chapter 8: Passive Reconnaissance Techniques

One of the most powerful tools in a network security analyst's toolbox does not generate any network activity whatsoever. In fact, you can gather such a large amount of information from simply listening to the medium (making more advanced probing techniques unnecessary). Such passive reconnaissance techniques occur through capturing unsolicited information from one or more sources in what is considered an untraceable or unnoticeable manner. Wiretapping, present in the fields of international espionage, law enforcement, and computer security, are implementations of passive reconnaissance. This chapter focuses on computer security.

Packet Sniffing

Packet sniffing (also called packet interception) is the idle capturing of traffic as it traverses a network. The content or ultimate destination of the traffic is irrelevant; all that matters is that the packet sniffer can see it. As we will see later in the chapter, whether or not a sniffer can see the traffic generally ties to Layer 2 specifics. Packet sniffing is a simple yet powerful technique in its own right, but it is also critical to understand the method in the context of a fundamental building block in more complex tools. While you can perform packet Chapter 2.

It is important to note that if built properly, a packet sniffer is completely undetectable. Various behaviors associated with the operating system, however, sometimes lead to vulnerabilities that can make the process remotely detectable. Tools such as @Stake's Antisniff analyze how systems react to spoofed IP packets and how associated processors load in order to detect active sniffing tools. Traffic elicited through ARP, ICMP_ECHO, and other types of packets can lead to remote detection, as well.

Packet Sniffing on Ethernet

Ethernet is a protocol based on the work done on the ALOHA wireless network developed at the University of Hawaii in 1970. In 1972, Bob Metcalfe incorporated ALOHA's method of broadcasting, collision avoidance, and collision recovery into the design of a wire-based network. Packet sniffing on Ethernet networks is easy to understand and execute due to its broadcast nature, where stations broadcast their traffic to every other station on the link. The reader should note that this broadcast is not at Layer 2 but rather it is a Layer 1 physical specification of how the electrical signal is sent down the wire. The individual station on the network must be a good neighbor and only look at traffic destined for it. In order to eavesdrop on this traffic, the network interface enters "promiscuous mode," which instructs it to pass all frames that it receives to the packet sniffing application. A typical packet sniffing application places the network interface in promiscuous mode, receives all of the traffic on the local network, and then performs some form of programmer-defined processing.

It is important to note that packet sniffing only works on a local network segment in a particular collision domain. That is, switches, bridges, routers, or other Layer 2 or 3 segmenting devices form boundaries beyond which packet sniffing is generally not possible. The wide-scale deployment of this hardware in locations where hubs are traditionally utilized has dramatically reduced the simplicity associated with packet sniffing. Of course, it is possible to cause some of these devices to fail open and extend the range of the packet sniffer, but that is beyond the scope of this book. The massive emergence of unencrypted 802.11 networks in both urban and suburban areas has led to a resurgence in the use of simple packet sniffing tools and shows that the elimination of these tools from the security analyst's arsenal would be quite premature.

Packet Demultiplexing and Protocol Decoders

Any packet sniffer worth its salt has some sort of packet demultiplexing and protocol decoding logic. Demultiplexing is the process by which an incoming Ethernet frame pulls apart and passes to the appropriate upper-layer protocol module. Decoding is the actual processing and dissection of the protocol at a given layer. To put it another way, packet sniffers employing this logic approximate an IP stack or endpoint application—parsing the frame, packet, datagram, or segment and making sense of it. Early tools did little beyond snatching frames from the network and collecting them for the user to puzzle over, while conventional tools like Ethereal have hundreds of protocol decoders comprising more than 90 percent of the codebase. Atypical demultiplexing starts at the beginning of the captured frame, looking at key header fields to determine what sort of packet it is.

Figure 8.1 illustrates a sample demultiplexing of a 42-byte Ethernet frame captured by a packet sniffer (technically, the frame is 54 bytes, but almost every Ethernet driver will strip the preamble and trailer from the frame before passing it to the application). Initially, all it knows is that it has some sort of Ethernet frame with 28 bytes of payload. So, the first thing the packet sniffer has to do is determine whether the frame is an IEEE 802.3 Ethernet frame or an RFC 894 Ethernet II frame. The two header formats are identical for the first 12 bytes (destination and source address). The 2 bytes following the source MAC address are different for each specification; 802.3 frames use this space to define a 2-byte length covering the rest of the frame, while Ethernet II frames have a 2-byte type field indicating the Layer 3 protocol. Fortunately, the IEEE maintains the Ethernet type database and has reserved values from 0x000-0x05dc (0-1500) bytes. All widely used Ethernet II types use an orthogonal number space, eliminating the likelihood of contention. Because the frame contains 0x0800 in the length/type field, the well-known Ethernet type for IP version 4, the packet sniffer knows that this frame is an Ethernet IIx frame. This process also lets the packet sniffer know that the frame contains an IPv4 packet, which can then be passed onto the IP demultiplexing and decoding module.

Figure 8.1: Demultiplexing of an Ethernet frame.

The next module continues the process by examining the IP protocol field in order to determine the Layer 4 protocol. In this case, the field contains a value of 0x01, the protocol code for ICMP (Internet Control Message Protocol). The IP demultiplexing module then checks the IP header length to see what (if any) options are present. This process enables the code to know how big the IP header is in total and at which offset the ICMP header starts. The IP header length byte is actually split in half, with the upper four bits encoding the version (which is always 0x4 for IP version 4) and the lower four bits containing the number of 32-bit words that comprise the IP header. When no options are present, as is the case in Figure 8.1, the header length is 0x5—indicating that the IP header is 20 bytes in size. The ICMP demultiplexing module performs subsequent work on the packet. It checks the ICMP type, which is 0x08, indicating that the packet is an ICMP echo request.

Bitwise Operations and Byte Ordering Issues

Two concepts that are often confusing to application programmers when developing tools that utilize packet-sniffing techniques are bitwise operations and byte ordering.

Bitwise operations manipulate fields of memory smaller than 1 byte. This situation happens frequently during code optimization jobs and when dealing with network protocols that often have 4-, 2-, and even 1-bit fields that need to be accessed and manipulated.

Byte ordering refers to one of two ways in which multi-byte numbers are stored in memory. Engineers refer to these two methods, and the pro-cessors that utilize them, as being either big-endian or little-endian (in reference to Jonathan Swift's Gulliver's Travels). Big-endian numbers are stored with the most significant byte in the lowest memory location while little-endian numbers are stored with the least-significant byte in the lowest memory location. Different processor architectures natively store numbers in either one format or the other (referred to as "host byte order"), but in order to communicate, everyone must agree on a common format. This agreed-upon "network byte order" is big-endian. For a packet sniffer, this situation means that all multi-byte values pulled from the wire will be big-endian and should be converted to host byte order before parsing. Because host byte order can be either big-endian or little-endian, however, you should write portable code to handle either instance. Fortunately for the application programmer, there are simple macros present in most, if not all, standard C implementations to convert multi-byte data between the two formats. Table 8.1 summarizes these macros.

The handy feature of these macros is that they are always correct for the architecture on which they are running, either big-endian or little-endian host byte order.

The Bit and the Pendulum: Byte Order from Chaos

The following few snippets of code will help the application programmer understand byte ordering and bit manipulations.

You will frequently use the AND (&) operator to test whether certain bits are set. The following few lines of code check the 14th byte of a TCP header, which contains the control flags. In the first conditional, for example, if the bit corresponding to the FIN flag is set (bit 0x01), the ternary operation will return the "F" string to printf():

printf("%s%s%s%s%s%s n",
(packet[13] & 0x01) ? "F" : ", /* FIN flag */
(packet[13] & 0x02) ? "S" : ", /* SYN flag */
(packet[13] & 0x04) ? "R" : ", /* RST flag */
(packet[13] & 0x08) ? "P" : ", /* PSH flag */
(packet[13] & 0x10) ? "A" : ", /* ACK flag */
(packet[13] & 0x20) ? "U" : ");/* URG flag */

You can also use the AND operator to clear out (or mask) certain bits. The following line of code extracts the 4-bit header length from the first byte of an IPv4 header. It uses an AND mask of OxOf to shave off the low-order 4 bits (which, as shown earlier, is the number of 32-bit words in the IPv4 header):

ip_hl = ip_packet[0] & 0x0f;

This code resulted in the number of 32-bit words in the IPv4 header, but it is a bit more useful to convert the value into its decimal representation. The left shift operator (<<) is the simple and computationally efficient way to accomplish this task. By shifting this value two to the left (which you can think of as multiplying the value by 2² or 4), we end up with the size of the IPv4 header in bytes:

ip_hl <<= 0x02;

The OR (|) operator sets certain bits. Consider the following handy line of code that enables the application programmer to extract (and print) the 2-byte packet length from an IPv4 header. The first byte is shifted eight places to the left, and the second byte is set via an OR mask:

printf("(%d) ", (ip_packet[2] << 0x08) | ip_packet[3]);

This line of code is convenient in that it extracts a network byte-ordered value and represents it properly on either a big-endian or little-endian machine without needing to memcpy() or call a byte-ordering macro. It pops up frequently in the sample code at the end of the chapter. The other option is to use the aforementioned byte-ordering macro, as in the following line of code:

printf("(%d) ", (ntohs(*(u_short *)&ip_packet[2])));

While they both accomplish the same thing, the former is more elegant looking and less prone to syntax errors.