A Man In The Middle (MITM) attack is a popular network based attack in order to hijack a connection or to sniff traffic. A MITM attack actually covers a variety of different methods. A MITM attack is literally positioning yourself as the attacker between the two communicating parties. Whether you do that via an ARP attack, some type of cryptographic attack, or a physical attack depends on the requirements and scenario. As a security consultant it is important to ensure that the network and it’s communications are as secure as possible against this type of attack. I will cover a simple physical MITM attack, then an ARP attack, and then prevention techniques.

Assume a setup of a number of PCs connected to a switch, and a regular DSL router connected to the switch providing internet access. This is typical of the majority of home and office based setups.

A physical MITM attack is simple. I can create a network bridge on my laptop which would require two NICs in this example. I’ll unplug the router, and plug it into one of my laptop’s NICs, then plug my laptop’s other NIC into the switch. Bridging is a Layer 2 technology, and therefore your Layer 3 devices, i.e. the router, your IP stack, etc. will know nothing of it. You can then sniff traffic quite easily with tcpdump. Perhaps along the lines of tcpdump -ibr0 -A -s1500 or similar. As for additional NICs on your laptop, there are plenty of linux compatible USB to Ethernet adapters. I personally use the “Startech USB 2.0 to 10/100 Mbps Ethernet” one.

ARP Poisoning is another method by which a MITM attack can be carried out. The basis of carrying out an ARP poisoning attack, is to broadcast illegitimate ARP packets to the network associating my own MAC address with the IP address of the node I wish to attack, in this case, the default gateway.  There are actually a number of methods of performing this type of ARP attack. A common method, is that whenever we receive a broadcast ARP request from a node asking ‘What’s the MAC address for 192.168.1.1 (default gateway), i.e. which machine has it?’ rather than ignoring it as we should, we reply informing the host that we do. We also do it frequently to ensure that the legitimate owner of the IP does not get much traffic directed towards it. We can attack more aggressively and simply keep sending ARP packets out to the network regardless of receiving a request informing other nodes that we have this IP, and we can send them out as slowly or as quickly as we choose. Explaining how to practically conduct an ARP attack is not within the scope of this article though.

The disadvantages to such an ARP attack, are that the actual results are often unpredictable. Certain switches and other networking hardware do not respond well and can freeze/require restarting, certain other unexpected network anomalies can occur, and we may not necessarily get ALL the traffic that we were hoping to catch, as the real IP’s owner can often step back in for a period of time.

Once however, we do initiate the attack, we can simply use tcpdump as above to sniff data. Here’s another reason to use SSL and even Self Signed Certificates between our hosts if we’re on an untrusted network.

There is no way to prevent a physical attack, other than to lock down your equipment. When it comes to ARP Poisioning though, using Layer 3 managed switches that lock down a specific MAC to a specific IP will prevent such an attack although such switches can be more expensive than the basic types. Certain switches will block illegitimate ARP packets, others will shut the switch port off alltogether.

MITM aside, if you are on an untrusted network, establish encrypted connections. Whenever I find myself on any public network, such as a hotel or other wifi hotspot, as well as Client’s offices, before accessing anything sensitive, I’ll fire up OpenVPN and establish an encrypted connection to one of my trusted machines at my data center. Traffic between myself and my trusted machine is now encrypted, however traffic from that point and beyond is obviously not, so the trusted machine and the datacenter and their uplinks all the way to the target host must of course all be trusted.