Detection of sniffing in switched networks

Detection of sniffing in switched networks

Sniffing in switched networks is typically conducted using one of two methods: MAC flooding or ARP spoofing. However, unlike sniffing in traditional, hub-based networks, both these methods are active and so can be detected - though sometimes this is not easy.

Unlike a hub, a switch sends frames only between specific ports - the ones the sender and recipient are connected to. Each decision to send incoming data to a certain port is made using a table stored in the memory of the switch, containing mappings of MAC hardware addresses to port numbers. Throughout its operation, a switch continues to learn the hardware addresses of the devices it serves by monitoring addresses in incoming frames.

Putting network traffic through a switch prevents the sniffing of open traffic, since frames are only sent to their rightful recipients, and not to other users. Two other methods are used instead: MAC flooding and ARP spoofing. Any network administrator is sooner or later bound to run across a script kiddie who repeatedly attempts to sniff traffic using one of these methods (see Inset MAC flooding and ARP spoofing). Fortunately, such active sniffing can be detected. Let's see how this can be done, starting with the easier of the two - MAC flooding.

Look out - flood's coming!

A MAC flooding attack involves flooding the network with frames containing spoofed source addresses, typically sent either to the broadcast address or to a non-existent hardware address. The frames will reach our network adapter regardless of whether the attack was successful or not (frames sent to another system will reach us only if the switch has indeed been flooded). In other words, whenever we receive frames coming from an unknown hardware address, we're probably dealing with a flooding attempt. The only way to make sure is to check the actual MAC addresses of all the hosts in our network.

It is also possible for frames addressed to hosts unknown to the switch to appear in our network, causing the switch to act as an ordinary hub and send the frame to all its ports. However, in reality this should never happen - before any frame is sent to a specific host, the sender has to query for the recipient's hardware address (for the TCP/IP protocol stack, this is done using a broadcast ARP request) and receive a suitable ARP reply, from which the switch will learn the location of that host. All this means that if our network adapter receives a frame (or many frames) addressed to another host, we can well suspect that our switch has fallen prey to a successful MAC flooding attack.

Detecting MAC flooding requires the analysis of all frames arriving at our network adapter. Under normal circumstances in a switched network, we should only receive broadcast and multicast messages and frames addressed directly to our computer. Any conscientious administrator should always have a list of all their hosts' hardware addresses handy, but human memory being what it is, it would be convenient to have a program which would use ARP to query all local IPs for their MAC addresses and then proceed to monitor all traffic incoming to our network adapter.

 

We can detect MAC flooding using the MACManipulator utility included on hakin9.live - a free application for automating the tasks listed above. MACManipulator also makes it possible to conduct a simulated MAC flood, so you can easily test whether your switches are susceptible to this attack method. Using the utility requires the WinPcap library to be installed (see Inset On the Net) - WinPcap 3.0 is included in the installation package. To check whether your switch is under attack, run the AntyMACflooding subprogram - you should see the window shown in Figure 1.

Figure 1. AntyMACflooding subprogram window

 

Before running the actual test, we need to select a network adapter to be analysed by choosing the appropriate entry from the list of all adapters in the system. We can also specify the desired time for data (i.e. MAC address) collection from hosts within the network and the time period for analysis of frames received by the adapter - longer times yield more accurate results.

Once the program has complete information concerning hardware addresses, it will proceed to capture and analyse incoming frames. After the specified time, the results are displayed. Incoming frames are divided into the following categories:

- broadcast frames,

- multicast frames,

- frames addressed to the local network adapter,

- frames addressed to other hosts.

Frames whose destination addresses don't match any known hosts within the network (the frames suspected of a flooding attempt) are marked in red. The program itself generates no alarms, but the frame statistics themselves can definitely be alarming - the sample results in Figure 2 show that nearly half of all the captured frames were sent from unknown MAC addresses.

Figure 2. Sample analysis results for the antyMACflooding utility

 

Of course, it is also possible that some new hosts joined the network during our capture session or perhaps the network includes systems that use a different protocol stack (such as IPX/SPX) and therefore obviously don't respond to ARP requests and send packets whose origin is unknown to our program. Bear in mind, though, that the utility is specifically intended to be used by administrators, who will presumably be aware of any such behaviour in the networks they run.

As you can see, MAC flooding can be detected quite easily, but the same cannot be said for ARP spoofing - a more complicated attack, requiring different detection methods. Let's see how ARP spoofing can be detected in Windows networks.

 

When two speak as one - ARP spoofing

ARP spoofing is a very effective attack method and can be used for more than just fooling switches (see Inset MAC flooding and ARP spoofing). Essentially, it forces the victim to send their data to a location completely different from the one originally intended, regardless of whether the network is switched or how many intermediate devices it contains. To make matters worse, the creators of the Windows family of operating systems have implemented ARP in a way which makes a spoofer's job much easier:

- each incoming ARP reply can change entries in the local ARP cache (even if the host never sent a corresponding ARP request in the first place),

- any manual changes made by the administrator to ARP cache entries are static only as long as no ARP replies corresponding to these entries arrive.

Let's say we have a list of all the hardware addresses within our network, but we don't have time to check each one for changes (this can be done using the arpwatch utility under Linux or a suitable Intrusion Detection System). All we can do is query all our hosts for their MAC addresses and make sure no duplicate replies arrive. Of course, if the intruder posing as one of our systems disables the target host (either using a DoS attack or physically - for example by cutting the network cable), this detection method won't help us much.

To analyse suspicious traffic, we will use a freeware Windows utility called ARPanalyzer (also included on hakin9.live), which can additionally perform a simulated ARP spoofing attack (though it cannot be used for a real attack, as this would typically require the intercepted frames to be forwarded to the real recipient). Figure 3 shows the main ARPanalyzer window.

Figure 3. The ARPanalyzer utility

 

ARPanalyzer provides three tests for checking a local network for spoofing attempts. The first of these is Quiz from my address which involves querying (using ARP requests) for physical host addresses using the local MAC address. The test can detect an attack attempt if the spoofer selected our particular system for attack. The program queries for a hardware address (e.g. of the Internet gateway) using the local address and checks the number of replies - if more than one answer arrives, we have proof of ARP spoofing.

The second test exploits the fact that an aggressor seldom chooses to attack an administrator's machine, which makes it a good idea to pose as a potential attack victim (the ARP spoofing option) by spoofing our own local ARP request. If we are running a switched network, our switch will of course soon learn that the traffic destined for the attack victim should in fact be directed to our machine, causing the actual target to be cut off from the network (at least until it sends some data and the switch sees it again). The worst-case scenario occurs when the victim participates in heavy traffic, causing the attacker's ARP reply to arrive at their system rather than ours. There is no easy way of dealing with this problem, short of unplugging the suspected victim from the switch for the duration of the test. It is, however, worthwhile trying this method (the test only lasts a few seconds, so the user shouldn't notice any problems), as it can help us avoid a phone call from a scared user whose system just reported an address conflict. If we have no idea who might want to spoof which computer, the only thing to do is to query all the hosts for our own hardware address by sending IP address resolution requests to all the local hosts.

Having started the program and selected a network adapter, we simply need to click Check. The result of each test will be reported by displaying the number of replies received to the request. If the result resembles the one seen in Figure 4, we can be sure we have an intruder snooping around our network. If the program reports no double replies, our network is likely to be secure, although this could also mean we are dealing with an attacker who uses a different attack technique which our tools cannot detect.

Figure 4. The effects of using ARPanalyzer

Summary

Detecting sniffing in Windows is much harder than for *NIX systems. A system like Linux has a vast array of standard tools for sending and manipulating network packets, whereas Microsoft's offerings have no such functionality. One way to remedy this state of affairs is to use the WinPcap library (see Article Full control - low-level access to the network in this issue of hakin9). It was used to create the utilities discussed in this article, and will be invaluable to any Windows network administrator who wants to develop custom applications for manipulating network packets.