Securebits Blog

Recently, I was trying to do the normal ARP poisoning/spoofing attack to intercept the bi-directional traffic between a Windows Vista machine and the Internet (through a gateway router). To my surprise, I was able to see a unidirectional traffic, which is the traffic coming from outside through the gateway to the Vista machine and I could not see the traffic sent from the Vista machine. I checked the ARP cache of both the gateway router and the Vista machine and found that the poisoning was successful – and by the way, I was using the Ettercap tool. The router cache contains an entry that says the IP address of the Vista machine is located at the MAC address of my (MITM) machine; likewise, the Vista cache contains an entry that says the gateway router IP address is located at the MAC address of my machine (the MITM). However, when I check the sniffer (Wireshark) on the MITM machine, I do not see any traffic from the Vista machine directed to the outside world.

After a little investigation, I discovered that the Vista machine was not using the default gateway IP address to look up its MAC address using normal ARP request, and then use this MAC in all packets destined to the outside world. It was actually sending Proxy-ARP request for every public IP address the system was trying to connect to. In other words, when the system needs to communicate with a public IP address, instead of just using the MAC address associated in the ARP cache with the default gateway IP, the system sends an ARP Request asking for the MAC address of that public IP address. Since this public IP does not fall within the local subnet range, such ARP request is called “Proxy ARP Request” and it will be handled by the default gateway itself. Usually, the gateway will return its own MAC address, and the system will cache a new entry associating this MAC address with the public IP address. The Vista system repeats this process with every public IP address it is trying to communicate with.

For example, let’s say that the default gateway IP is 10.0.0.1 and its MAC AB:CD:EF:12:34:56. Let’s assume that there is already an entry in the ARP cache associating this IP with is MAC. In normal operations, when the system wants to contact a public IP like 65.65.65.65, it simply sends the packet where the destination MAC address is that of the gateway, that is AB:CD:EF:12:34:56. However, in the new Vista operation, the system will simply send a Proxy ARP Request asking for the MAC address of 65.65.65.65, then, the gateway will reply with its own MAC (AB:CD:EF:12:34:56). The Vista system will now cache this new entry associating 65.65.65.65 with AB:CD:EF:12:34:56. When the system wants to communicate with another IP address, e.g. 53.53.53.53, it will cache another entry and so on so forth.

My only impression about this behavior is that Microsoft is trying to minimize the effect of ARP spoofing/poisoning so that normal ARP interception technique may not fully work. Intercepting a unidirectional traffic is not of much interest for an attacker since he/she will miss a lot of important data, besides, many attacks (e.g. SSL Hijacking, RDC Hijacking, etc) implemented after a successful interception may not work properly.

To circumvent this restriction, the attacker needs to poison the ARP cache with fake entries for every IP address the system is trying to connect to. This could be done as follows:

• The attacker sniffs for ARP Requests generated by the target system and asking for MAC address of an IP address that falls outside the local subnet.
• The attacker sends a fake ARP reply saying that the MAC address of such public IP is the MAC address of his/her own machine (MITM).
• The attacker keeps this public IP in a list to keep injecting the fake ARP replies every 1-2 minutes (to keep the cache poisoned)

This process can be automated using a script or a program which will run simultaneously with a tool like Ettercap.

DNS Multiple Race Exploiter (DNS_MRE) tool is now an official FreeBSD Port. The port page is:
http://www.freshports.org/dns/dns_mre/

I would like to thank Tomoyuki Sakurai who ported and is maintaining the port.