A man in the middle attacks involves an attacker positioning himself between a client (victim) and his intended server. The purpose is usually to either sniff (intercept) data or to modify data as it is being transmitted and received.
Looking at a regular wired ethernet IP network, each host and networking device on the network maintains an ‘ARP table’. This table maintains a list that links MAC addresses to IP addresses. To expand slightly, any networking device that is capable of communicating at layer 2 (http://en.wikipedia.org/wiki/OSI_model) handles ARP data. Hubs for example, do not. IP addressing, TCP ports, HTTP traffic and so on all operate above Layer 2 and have no knowledge of MAC addressing.
Without going too much further in to it, the best explanation is by way of an example. User ‘Bob’ is on a network, and his network adapter has a MAC address of 00-C1-D0-44-EE-A6. He is connected to a switch along with a number of other users, and the switch is connected to a router. The router has a MAC address of 00-83-F2-B6-22-B0. Bob wishes to search Google. He sends a DNS A request to his nameserver IP (22.214.171.124). His local machine will first look to see if that IP is local to him. As his IP and netmask is 192.168.0.55/255.255.255.0, the only IPs that are local to him are 192.168.0.0-255 and this IP is not one of them. He must therefore contact his default gateway (router), configured as 192.168.0.1, and route the packet through that. He He now sends an address resolution protocol (ARP) broadcast out (source 00-C1-D0-44-EE-A6, destination FF-FF-FF-FF-FF-FF), asking who has 192.168.0.1? The router replies (source 00-83-F2-B6-22-B0, destination 00-C1-D0-44-EE-A6), saying, “I have got 192.168.0.1″. Bob now knows his router’s MAC address and can cache it in his own ARP table. Now that Bob has this, he can go ahead and build his packet containing his original DNS request. The packet must then be encapsulated appropriately. His DNS packet containing his request and headers will be encapsulated inside a UDP packet with it’s own headers. This will be encapsulated in an IP datagram with an IP header, and that will be encapsulated in the layer 2 frame with it’s own header. This is then transmitted over the wire. The switch receives this, looks at the layer 2 header and forwards it to the appropriate port. Incidentally, if a hub was in use, it would simply relay anything received on one port to all other ports.
Once the router has this packet, different things will happen depending on whether NAT, PAT or some other type of routing is involved. At minimum though, the layer 2 wrapper will be stripped and rewritten, as this router then passes the packet to it’s own router on it’s journey towards the final destination. The router may have one or multiple routes out depending on destination address or other factors.
Back to the attack however, at the point whether Bob sends his broadcast packet asking for 192.168.0.1′s MAC address, what if Mallory (the attacker), should respond and say ‘I have that IP and the MAC is: 00-B5-65-72-CC-0E’. The router itself will respond at the same time as it would normally have done, but if Mallory keeps sending out ARP packets, then he is likely to cause Bob to incorrectly update his own ARP table to state that 192.168.0.1 is in fact Mallory and not the legitimate router. Further, Mallory does not even have to wait for an ARP request from a host. He can simply flood the network hosts with ARP packets stating that he is 192.168.0.1.
At this point Mallory will be receiving all traffic destined for the router. He can choose to forward them on to the real router, before intercepting and/or modifying what was sent. This is the basis of the man in the middle attack.