Hack 49 Detect Ethernet Sniffers Remotely

Detect potential spies on your network without having to trust compromised machines.

Ethernet sniffers are one of the most powerful tools in your network security arsenal. However, in the wrong hands they can be one of the biggest threats to the security of your network. It may be an insider or it could be a malicious intruder, but, nevertheless, once a system has been detected they will most likely begin sniffing the local network. This network reconnaissance will help these "spies" find their next target, or simply collect juicy bits of information (such as usernames and passwords, email, or other sensitive data).

Not too long ago, it was commonly thought that only shared-medium Ethernet networks were vulnerable to being sniffed. These networks employed a central hub, which would rebroadcast every transmitted packet to each port on the hub. In this type of setup, every frame sent by any network node is received by every other node on the local network segment. Each node's network interface then performs a quick check to see if it is the node that the frame is destined for. If it is not, the frame is discarded. If it is, the frame is passed up through the operating system's protocol stack and is eventually processed by an application. Because of this, sniffing other systems' traffic on the network was trivial. After all, since all the traffic was reaching each system, one only needed to disable the check that the network interface performs, and the system would have access to the traffic meant for others. This is usually referred to as putting the network interface into promiscuous mode, which usually can be done only by a privileged user.

Eventually, switched Ethernet networks became prevalent and the shared-medium aspect no longer applied. Thus, the main facilitator of sniffing was removed. Unlike hubs, Ethernet switches will only send traffic to the device that it is destined for. To do this, an Ethernet switch learns which network device's MAC address corresponds to what port on the switch as traffic passes through the switch. When the switch sees an Ethernet frame with a certain destination MAC address, it will look up which port on the switch corresponds to it and forward the frame to only that port. In doing this, the switch effectively creates a virtual dedicated connection from the sending station to the receiving station every time an Ethernet frame is transmitted on the network. Thus, only the machine that the frame was originally intended for is able to see it. This would be fine, but certain aspects of the Ethernet specification and the TCP/IP can cause problems.

One problem is that switches can memorize only a limited number of MAC addresses. The maximum number will often be several orders of magnitude higher than the number of ports that the switch has, which allows switches to be connected to each other hierarchically. In order to do this efficiently, each switch must memorize the MAC addresses available on the switches to which it is connected. For example, suppose you have a 24-port switch (switch A) with 23 machines plugged into it, and the 24^th port is occupied by another switch. This other switch (switch B) has 48 ports, with the 47 other ports being occupied by machines. In this situation, switch A will learn the MAC addresses of the 47 systems on switch B and associate it with its 24^th port, and switch B will learn the MAC addresses of the 23 systems connected directly to switch A and associate it with its own 48^th port. Even though the average switch can memorize upwards of several thousand MAC addresses, it is still possible to overflow the switch's MAC address table by generating large amounts of traffic with fake MAC addresses. This tactic is desirable for a malicious user because many switches will revert to behaving like a hub once their MAC address tables have been filled. Once this happens, the network is no different than a shared-medium segment using a hub. A malicious user will then be able to sniff the network by simply putting her network interface into promiscuous mode.

Luckily this approach is fairly invasive in order for it to work, the network will need to be flooded with bogus traffic, which is something that can be detected passively with tools such as Arpwatch [Hack #31] . A flood of bogus MAC and IP address pairings would cause Arpwatch to likewise flood your system logs. As long as you're good about monitoring your logs, this attack should be fairly easy to spot. As mentioned in [Hack #31], Arpwatch is also capable of detecting ARP table poisoning. That makes it an effective tool for detecting the two most common types of ARP attacks that are usually precursors to data logging: ARP flooding and targeted ARP poisoning.

Another way to monitor switched networks is to simply change the MAC address of the Ethernet card in the system that is going to be used for sniffing. In Linux and many other Unix and Unix-like operating systems, this can be done with the ifconfig command:

# /sbin/ifconfig eth1 eth1      Link encap:Ethernet  HWaddr 00:E0:81:03:D8:8F           BROADCAST MULTICAST  MTU:1500  Metric:1           RX packets:0 errors:0 dropped:0 overruns:0 frame:0           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:100            RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)           Interrupt:11 Base address:0x1c80  # /sbin/ifconfig eth0 hw ether 00:DE:AD:BE:EF:00 # /sbin/ifconfig eth1 eth1      Link encap:Ethernet  HWaddr 00:DE:AD:BE:EF:00             BROADCAST MULTICAST  MTU:1500  Metric:1           RX packets:0 errors:0 dropped:0 overruns:0 frame:0           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:100            RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)           Interrupt:11 Base address:0x1c80

The purpose of doing this is to trick the switch into forwarding the traffic to two different nodes on the segment. This is sometimes a hit-or-miss deal, since different switches will behave differently when there are duplicate MAC addresses in use on the same network. The switch may forward traffic to both ports, distribute the traffic unpredictably between them, stop passing traffic altogether, or raise an error. All of these methods can be detected and stopped with more expensive managed switches, which allow you to specify what MAC addresses are allowed on each individual port. This feature is sometimes called port security.

However, even if attackers choose not to employ these methods, they can still gather quite a bit of information by just putting the network interface into promiscuous mode. For example, broadcast traffic such as DHCP and ARP requests will still be sent to every port on the switch. This traffic is not as easy to detect, unless you already have the infrastructure in place to do so.

One tool that can help to detect promiscuous interfaces on both switched and unswitched networks is sniffdet (http://sniffdet.sourceforge.net). For a tool that really only serves a single purpose, sniffdet is fairly versatile, as it can detect sniffers in several ways. The main difference between sniffdet and a tool like Arpwatch is that sniffdet actively scans for sniffers. That is, if you suspect that a machine may be running a sniffer, you can simply run sniffdet and point it at that machine to determine whether its network device is in promiscuous mode.

To build and install sniffdet, you will first have to obtain the libnet packet injection library (http://www.packetfactory.net/projects/libnet/). Make sure to download the latest 1.0.x version the 1.1 versions of libnet are incompatible with programs written for the 1.0.x versions.

To compile libnet, unpack the source distribution and go into the directory that it creates. Then run this command:

$ ./configure && make

After it has finished compiling, become root and type make install.

Building sniffdet is a similar affair. Like libnet, you will need to unpack the source distribution and change to the directory that it creates. Then, to build and install it, do the same thing you did for libnet.

sniffdet has several methods for determining whether a target machine is running a sniffer. However, only two of the methods that it employs will work with repeatable and predictable results. These are the ARP and DNS tests.

The ARP test relies on how the sniffing system's protocol stack deals with ARP queries while in promiscuous mode. When running this test against a target machine, sniffdet will send out an ARP query to the target machine. This request has fake source and destination MAC addresses but uses the correct IP addresses of the machine being checked. If the target machine is in promiscuous mode, the ARP query with the fake MAC address will be passed up the protocol stack, and the target machine will send a reply. If the machine is not in promiscuous mode, this ARP query will be quietly discarded. This method is effective on both switched and unswitched networks.

Let's look at a sniffdet scan against sirius (192.168.0.2) from colossus (192.168.0.64), two machines that are on the same switched network.

Here are the results of running sniffdet against sirius:

colossus # sniffdet -i eth0 -t arp sirius ------------------------------------------------------------ Sniffdet Report Generated on: Wed Dec 31 03:49:28 2003 ------------------------------------------------------------ Tests Results for target sirius ------------------------------------------------------------ Test: ARP Test (single host)       Check if target replies a bogus ARP request (with wrong MAC) Validation: OK Started on: Wed Dec 31 03:49:08 2003 Finished on: Wed Dec 31 03:49:28 2003 Bytes Sent: 252 Bytes Received: 0 Packets Sent: 6 Packets Received: 0 ------------------------------------------------------------ RESULT: NEGATIVE ------------------------------------------------------------ ------------------------------------------------------------ Number of valid tests: #1 Number of tests with positive result: #0 ------------------------------------------------------------

Now start a sniffer on sirius and run the scan again:

sirius # tcpdump -i le0 arp tcpdump: listening on le0 06:58:00.458836 arp who-has sirius.nnc tell colossus.nnc 06:58:00.458952 arp reply sirius.nnc is-at 8:0:20:81:a4:a3 06:58:00.466601 arp who-has sirius.nnc (ff:0:0:0:0:0) tell colossus.nnc 06:58:00.466928 arp reply sirius.nnc is-at 8:0:20:81:a4:a3

Let's look at the results of the scan:

------------------------------------------------------------ Sniffdet Report Generated on: Wed Dec 31 06:58:01 2003 ------------------------------------------------------------ Tests Results for target sirius ------------------------------------------------------------ Test: ARP Test (single host)       Check if target replies a bogus ARP request (with wrong MAC) Validation: OK Started on: Wed Dec 31 06:58:00 2003 Finished on: Wed Dec 31 06:58:01 2003 Bytes Sent: 84 Bytes Received: 60 Packets Sent: 2 Packets Received: 1 ------------------------------------------------------------ RESULT: POSITIVE ------------------------------------------------------------ ------------------------------------------------------------ Number of valid tests: #1 Number of tests with positive result: #1 ------------------------------------------------------------

The DNS test works very well, particularly on shared-medium networks such as hubs or wireless LANs. However, it does rely on name resolution being enabled in the sniffer. When performing DNS tests, sniffdet will send bogus packets that contain IP addresses that are not in use on the local network segment. If name resolution is enabled, the sniffer will attempt to do a reverse lookup in order to determine the hostname that corresponds to the IP addresses. Since these addresses are not in use, sniffdet will determine that the target machine is in promiscuous mode when it sees the DNS queries.

This test can be performed just as the ARP test, but instead of using -t arp, use -t dns.