Overwhelming media attention and sensationalism about computer security has created a lot of fear, uncertainty, and doubt (FUD)—some deserved and some not. What exactly can attackers do? What tools and tricks do they have up their sleeves? Can they really compromise a computer simply by touching the keyboard? Not likely. Can they really disable the Internet? That depends. Walk on water? Let’s hope not. One area of penetration testing in particular that seems to be filled with confusion and is the topic of this chapter is network sniffing, which is the attacker’s ability to eavesdrop on communications between hosts.
This chapter explores network sniffing threats and in the process dispels some of the common myths and misunderstandings. These threats are very serious, so early on it’s important to debunk any myths and misunderstandings that could dilute this point. Also, as you read this chapter, think about network sniffing as something attackers will do, rather than as something they can do.
Let’s start by looking at the key concepts of network sniffing. Then the chapter will discuss the following topics:
Common network sniffing myths
Network sniffing threats
Network sniffing countermeasures
On IP networks, data is sent in packets that are broadcasted to all hosts on the local network. Each packet specifies the Media Access Control (MAC) address of the correct recipient of the data. The network interface card (NIC) of the correct recipient will accept the packet, whereas NICs on all other hosts will reject it.
In Figure 19-1 if Host A sends a packet that indicates the intended recipient is the host with the IP address 192.168.1.3 with MAC address CC:CC:CC:CC:CC:CC, every host in this network will receive this packet. However, only Host C will accept the packet because it has the correct IP and MAC addresses, and all other hosts (Hosts B and D) will simply ignore the packet.
NICs, however, can be placed into a state that allows them to receive all network traffic regardless of the intended recipient. This mode is referred to as promiscuous mode and is typically used by network administrators to monitor all local network traffic, especially when debugging network issues such as those related to connectivity or computer worm infestations. As you learned in the chapter introduction, this act of monitoring network traffic is referred to as network sniffing and is done using software or hardware devices called network sniffers. Figure 19-2 illustrates a case of network sniffing.
Unfortunately, attackers also use network sniffers but for more nefarious purposes. Attackers compromise hosts, install network sniffers, and then use the network sniffers to capture sensitive data such as network credentials. They can then use this data to compromise additional hosts or steal personal information such as credit card numbers.
Rumors and myths are like road tacks for the mind: they truly impair your ability to move forward in understanding a topic. The topic of network sniffing is not without its share of road tacks and misinformation. Let’s put an end to the following common myths about network sniffing before moving on to detection and countermeasure techniques:
Attackers can sniff traffic on a network without being local to the network.
Network sniffing is not possible on switches.
A common myth about network sniffing attacks is that attackers on one network can use a network sniffer to remotely monitor the traffic on another. Figure 19-3 illustrates this myth.
Wrong! Network sniffers can monitor traffic only on their local networks. Here’s why: on a local network, packets are broadcasted to all hosts (including any local attackers) in that network. The correct recipient accepts the packet, while all the other hosts simply ignore the packet. Data on this network can be sniffed by attackers because they can see the traffic. However, traffic on remote networks, such as the traffic on your competitors’ networks, is not visible to attackers and therefore attackers cannot eavesdrop on these communications.
As illustrated in Figure 19-4, one way an attacker could eavesdrop on remote network data is by compromising a host that is local on the remote network, sniffing traffic from there, and then sending the packet captures back to the attacker’s machine.
Another possibility is for the attacker to be somewhere in the path of communications of the remote traffic he wants to sniff, as shown in Figure 19-5. The attacker would again have to be local on the network over which the traffic is being sent.
Switches primarily differ from network hubs in that they send data to the intended host on the switch instead of to all hosts. As you will soon see in this section, this behavior can be altered under certain conditions. This myth creates a dangerous false sense of security because organizations mistakenly assume that deploying switches in their networks makes those networks immune to network sniffing attacks. Here are several common ways attackers can defeat switch protection:
Flooding the switch’s MAC table with bogus entries
Spoofing Address Resolution Protocol (ARP) packets
Modifying routing tables
Compromising the switch
Network switches maintain a table of media access control addresses that they have seen on each of their ports. On some switches, when this table reaches its maximum capacity—that is, no more MAC address entries can be added—the switch begins sending all traffic to the port. An attacker could flood the network with thousands and thousands of false MAC addresses. Once the MAC address table space on the switch is exhausted, an attacker could force a susceptible switch to move into repeating mode, allowing the attacker to begin sniffing network traffic.
The address resolution protocol is designed to allow hosts to map an IP address to a physical machine address. If an attacker wanted to receive all the data intended for another host on the switch, say Host B, she could forge an ARP reply indicating that Host B’s IP address maps to the attacker’s MAC address and advertise this packet by sending it to the network broadcast address. Any host on the switch trying to send data to Host B will actually be sending the data to the attacker. Figure 19-6 illustrates this process.
An attacker can be even more insidious and advertise herself as the network’s default gateway. (See Figure 19-7.) Any outbound traffic to remote hosts—for example, HTTP traffic to online commerce sites containing sensitive information such as credit card numbers—would be routed first to the attacker. The attacker could then modify that data and forward it to the correct gateway, creating a man-in-the-middle (MITM) attack. MITM attacks are discussed in more detail in Chapter 21.
Another way attackers can route network traffic on a switch to themselves is by forging Internet Control Message Protocol (ICMP) Redirect (type 5) packets, much in the same way ARP spoofing was used. This type of packet is normally used by routers to inform hosts of more optimal network routes, but it is also commonly used by local attackers to route traffic to themselves.
Note
Microsoft Windows hosts can be protected from ICMP Redirect attacks by setting the EnableICMPRedirect value to 0 under the registry key HKLMSystemCurrentControlSetServicesAFDParameters.
More information about this registry setting can be found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/HTHardTCP.asp.
In the attempt to sniff network traffic on a switch, an attacker might choose to attack the switch itself. Network administrators commonly forget to change the publicly known factory (default) password used to access the switch’s administration console, or they use weak passwords. If an attacker is able to gain access to the switch’s administration console, he commonly will reconfigure his switch port to be a span port (sometimes also referred to as a "mirror" or "monitor" port). These span ports are able to see all traffic on a switch regardless of the correct recipient and are intended for network administrators to use to debug network problems.
When you’re looking for a fox in a henhouse, the trick is to look for telltale signs of the fox (maybe there’s a corner in the hen house where dead hens lie or where other hens refuse to go) or to somehow find a way to lure the fox out of hiding. Likewise, when you’re hunting for an unauthorized network sniffer, the trick is to look for signs of sniffing or to lure the network sniffer out into the open. Here are some useful techniques you can use:
Manual detection
Review network architecture
Monitor extraneous domain name server (DNS) queries
Use the false MAC address and ICMP packet techniques
Use trap accounts
Use non-broadcast ARP packets
Use automated detection tools
Use Microsoft Network Monitor (NetMon) detection
Important
As you can see, there are numerous ways of detecting network sniffers on your organization’s networks. As you read about them, keep in mind that none is always 100 percent accurate, so you should employ a variety of techniques in your penetration tests. Don’t rely solely on any one technique.
If you suspect that a host’s NIC is in promiscuous mode and is sniffing local network traffic, you can manually check this on UNIX systems by reading the output of ifconfig. To do this:
Note
Be wary of this technique. If a host has been compromised, it is likely that several of the common tools found on that host, such as ifconfig and ps, have been replaced with modified binaries designed not to report the correct results. More about how attackers cover their tracks after compromising a system is covered in Chapter 22.
Granted, this next manual detection technique is crude, but you can inspect the link lights on your organization’s switches and hubs for unauthorized machines. This particular method is useful when the network sniffer is attached to your organization’s network using what is called a gag cable, which is an Ethernet cable with the transmission (TX) wire cut. Cutting this wire renders the cable as a read-only cable and thus can completely foil any network, application, or protocol-based method of detecting network sniffers because they won’t be able to respond to any detection probes and expose themselves.
Any network segment in your organization’s network that uses hubs or switches without some level of encryption to protect data is a potential hotspot for network sniffing attacks. You should review these segments and apply the appropriate countermeasures discussed later in this chapter.
When most network sniffers see an IP address they haven’t seen before, they try to resolve the host name of that IP address using DNS queries. Monitoring your organization’s networks for extraneous DNS queries could be used to help identify potential sniffing hosts.
More Info
To increase the accuracy and reliability of monitoring DNS queries, the authors of Hack Proofing Your Network: Internet Tradecraft (Syngress Publishing, 2000) suggest that you inject packets into your network with fake IP addresses. Any host that tries to resolve the host name for those fake IP addresses is running a network sniffer.
If you suspect that a host is running a network sniffer, one way to help confirm this is to use the latency technique. As network sniffers monitor data on the local network, they also often record every packet they capture, which can be a very resource-intensive activity. One method to detect potential network sniffers is to:
If the suspect host is indeed a network sniffer, the time recorded in Step 1 will be shorter than the time recorded in Step 3, because the network sniffer will be resource-strapped trying to record all the data being sent in Step 2, and thus will be slower to respond.
Remember that when the NIC is in promiscuous mode, it will accept all packets regardless of the MAC address specified in the packets. Here’s how you can use this acceptance behavior to get network sniffers to reveal themselves:
Create an ICMP Echo Request (type 8) packet with the IP address of the suspect host and with an invalid MAC address, that is, one that does not correspond to the MAC address of any host on the local network.
Send the ICMP packet to the suspect host.
If you receive an ICMP Echo Reply (type 0) packet, the suspected host is a network sniffer.
Why does this method work? The packet that you created in Step 1 has an invalid MAC address, so technically all hosts on the local network should reject this packet. However, because a network sniffer is in promiscuous mode, it will accept the packet. The suspect host will respond to the ICMP Echo Request packet with an ICMP Echo Reply packet and blow its cover.
Another interesting technique to get attackers to reveal themselves on your organization’s network is to use trap credentials. To do this, you set up a mock server (Telnet usually suffices) and pretend to log on with fake or low-privilege credentials. Regular hosts not in promiscuous mode will simply ignore these packets. However, if an attacker is sniffing the network and captures these credentials, he will later try to log on to that server with those credentials, exposing his presence on your organization’s network.
To use non-broadcast ARP packets to uncover network sniffers, follow these steps:
Send out a broadcast ARP reply packet with your IP address but an incorrect MAC address.
Send out a non-broadcast ARP reply packet with your correct IP address to MAC address mapping.
Send a broadcast ICMP Echo Request (type 8) packet.
Any host that responds with an ICMP Echo Reply (type 0) packet is running in promiscuous mode.
Here’s how this technique works. In Step 1, you sent a broadcast ARP reply packet with an incorrect IP to MAC address mapping. All local network hosts including sniffers temporarily cache this invalid mapping in ARP tables. In Step 2, you sent out a non-broadcast ARP reply packet with the correct IP to MAC address mapping. Because the packet was non-broadcast, only a network sniffer could pick it up and update its ARP tables with the correct IP to MAC address mappings. When the broadcast ICMP Echo Request packet was sent out, only the network sniffing host could reply, because all the other non-sniffing hosts on the network still contained the wrong IP to MAC address entries, exposing the network sniffer.
Several host-based scanning products, such as System Scanner from Internet Security Systems, Inc. (http://www.iss.net), can detect NICs in promiscuous mode. Additionally, free tools such as Antisniff (originally published by the former L0pht Heavy Industries, Inc.) and proDETECT (http://sourceforge.net/projects/prodetect) can be used to detect NICs in promiscuous mode.
To help protect your organization’s network from network sniffing threats, Microsoft Network Monitor (NetMon) can detect other installations of NetMon on the local segment of your network. This feature is unable to detect other types of network sniffers such as Ethereal and Tcpdump, so it will work only if attackers are using NetMon.
To detect other NetMon installations using NetMon, follow these steps:
Open NetMon.
In the Capture Window dialog box, on the Tools menu, click Identify Network Monitor Users.
The names of other hosts on the network that are using Net-Mon to capture data will appear in the Identify Network Monitor Users dialog box, shown in Figure 19-8.
More Info
More information about NetMon can be found at http://www.microsoft.com/windows2000/en/server/help/default.asp?url=/windows2000/en/server/help/cdetect.htm.
Remember that network sniffing attacks are rooted in the attacker’s ability to:
Sniff data off the wire
Decipher the data that was sniffed
Take away either one of these abilities (or both) and you can greatly reduce, if not sometimes eliminate, the threat of network sniffing attacks on your organization’s networks. Here’s how:
Use encryption to protect data. Encrypting data at the transport or application layer (or better yet, at both layers!) is a good counter-measure against network sniffing attacks. For example, instead of using TCP by itself, use secure socket layers (SSL), Secure Shell (SSH), or IPSec for transport-level security when sending sensitive data like credit card information. Or encrypt data at the application level with applications such as Pretty Good Privacy (PGP). Even if an attacker could capture the encrypted data, this data would be essentially worthless to her because she wouldn’t be able to decipher its contents.
Look at the example used earlier in this chapter (see Figure 19-2) on sniffing traffic between a host and a website such as http://www.microsoft.com. Notice that when connecting to the website over an encrypted transport like SSL (http://www.microsoft.com), the captured data is no longer easily deciphered. This is illustrated in Figure 19-9.
Use switches instead of hubs. As you learned earlier in this chapter, the protection against network sniffing provided by switches is not absolute. Attackers can use techniques such as MAC table flooding, ARP spoofing, and routing tricks to eavesdrop on traffic in a switched network. This caveat, however, does not negate the usefulness of switches as a countermeasure against most network sniffing attacks (especially when the switches are configured correctly). Low-skilled attackers perform the majority of sniffing attacks, and switches are sufficient against such attacks.
Secure core network devices. To prevent attackers from compromising core network devices such as switches and routers, be sure to protect the administrative accounts for these with strong passwords (see Chapter 15) and always keep device firmware up-to-date. An even more effective countermeasure is to simply disable the administrative Telnet port and any other way to remotely manage these devices such as Simple Network Management Protocol (SNMP), and use serial console ports for administration.
Use crossover cables. For hosts that need to exchange data exclusively between each other, you can avoid the threat of attackers sniffing data off of hubs and switches altogether by simply using a crossover cable. This defense is a good countermeasure for machines that are sending highly sensitive and personal data such as credit card and social security numbers, because it eliminates the chance of unauthorized hosts being accidentally or intentionally plugged into hubs and switches.
Secure hosts. Network sniffing does not have to take place on the wire. An attacker, for instance, can compromise a host and sniff network traffic as it is being received or transmitted by the host, not just when it’s en route. Think about this scenario as robbing the train at the train station instead of after the train has left the station and is zipping across the country to the next destination. Your organization’s best defense against this scenario is to remain vigilant in securing its hosts.
Policy. Create a policy that prohibits the use of network sniffers within your organization. A strong business reason should be provided before giving any personnel permission to sniff network traffic.
Conduct regular scans. Your organization’s networks should be regularly scanned for unauthorized network sniffers. Unauthorized network sniffers usually indicate that the host has been compromised, and when such a host is found, it should be removed from the network immediately for forensic analysis.
Q. | What are the names of some network sniffers I can use in my penetration tests? | ||||||||||||||
A. | Here’s a good starting point:
| ||||||||||||||
Q. | How about naming some common tools I can use to test my organization’s resiliency to network sniffing attacks? | ||||||||||||||
A. | Dug Song has created a nice suite of tools called dsniff that can be used to test for network sniffing threats, among other things. The dsniff suite can be found at http://monkey.org/~dugsong/dsniff. | ||||||||||||||
Q. | Is there a tool available I can use to detect when an attacker moves one of my NICs into promiscuous mode? | ||||||||||||||
A. | Yes. You could write your own application to monitor the state of your NICs, or more specifically, to monitor when they are set to promiscuous mode; or you could use tools such as ifstatus by David Curry at http://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/ifstatus/ifstatus-4.0.tar.gz, which does this for you. As useful as these tools are, however, be aware that if a system is fully compromised, tools like these might not help because the attacker can install syscall traps in the kernel, which can hide events like this. | ||||||||||||||
Q. | What’s the most important lesson I should take from this chapter? | ||||||||||||||
A. | Actually, there are two. First, don’t rely on switches as your organization’s only defense against network sniffing attacks. In most cases, they can be defeated. Second, attackers will be watching, so always use some form of encryption either at the transport layer or at the application layer to protect sensitive data in transit from one host to another. |