Attacking the ARP

[Aerosol]

The Address Resolution Protocol (ARP) is used to resolve IP addresses into MAC addresses (hardware addresses). Computers in a network send messages to each other through MAC addresses. At an initial stage of communication, the computers are only aware of their allocated IP addresses on the network. The ARP plays the role of making an ARP request from the requesting device on the network by querying the IP addresses on a receiving device for a MAC address. The receiving network device replies with an ARP reply for further communication. More technically, ARP resolves from a network layer into a data-link layer of the OSI model.

Resolving IP addresses to MAC with the ARP is similar to how the DNS helps resolve IP address to domain names. One major similarity they both have is that they need to do the resolving job on new network connections. In order to speed up the process and avoid a repetition, a cache is stored. There is usually a DNS cache, and with ARP there is an ARP cache stored on the ARP table.

ARP spoofing is where an attacker pretends to be another computer on a network by telling the network gateway to request for the victim’s MAC address from his/her machine IP address. The same process is repeated vice versa with the victim, making the victim see the attacker’s IP address as the gateway address ARP replies.

The image below illustrates a typical ARP operation:

This image is the same as the process above but with an attacker in the picture:

At this point of interception, the attacker receives every piece of data meant for the victim from the gateway and vice versa. A default result will be disrupted communication between the victim and the gateway. Packets meant for the victim wouldn’t get to him, and the victim may get suspicious. To prevent this, the attacker forwards packets from the gateway to the victim and does the same thing back to the gateway.

Bringing all that to reality! From a Windows machine, running an arp -a

command will list a cache of all neighbour IP addresses with their MAC addresses. This works across Mac and Linux the same way, but our victim machine here is Windows.

While we can see that the IP address 192.168.1.1 resolves into the d4:ca:6d:fc:43:9f hardware address, the attacker will begin an ARP proxy (spoof) against this address. The ARP cache on the victim PC as seen above consists of dynamic and static entries. To monitor how the victim’s machine is communicating with the gateway, I’ll run a continuous ping from the victim machine to the gateway device with the Windows ping -t command.

During this test, the following IP addresses are used:

192.168.216.2 ? Gateway device

192.168.216.129 ? Victim address

192.168.216.130 ? Attacker address

The continuous response from the continuous ping means there is a proper connection between the victim PC and the default gateway.

Since ARP replies contain MAC address replies from a network device, the attacker’s objective is to flood ARP replies to both the target and the remote host. To achieve this, the arpspoof command line utility is used on a Linux box.

The -i switch is used the specify the network interface, -t is for target host, and -r for remote host. Remote host pretends to be the one to be sending the ARP replies, and Target host is the host that receives the reply.

arpspoof -i eth0 -t 192.168.216.2 192.168.216.129

The process is repeated inversely to have a bi-directional packet traffic redirection.

arpspoof -i eth0 -t 192.168.216.129 192.168.216.2

At this point, the communication between the victim machine and the gateway is lost. We had created a ping to the gateway earlier from the victim machine. Requests being made are now timed out.

The attacker enables IP forwarding to allow packets flow from both proxied network devices.

That brings back a network communication with a Man-In-The-Middle of the victim and the gateway host.

The victim now has a poisoned ARP cache

From the figure above it appears that both IP addresses 192.168.216.2 and 192.168.216.130 resolve into the hardware address 00-0C-29-81-19-63 as dynamic entries.

Ettercap can also be used to achieve what we have done with arpspoof, but it’s far less painful to do with arpspoof. To use ettercap we would have had to run:

ettercap -i interface -Tq -M arp:remote /192.168.216.2/ /192.168.216.129/

ARP Cache Poisoning

ARP cache poisoning involves poisoning the cache of a victim user by flooding it with ARP replies containing MAC addresses to a proxy host. This is what has been achieved in the last step above. ARP spoofing is a technique to achieve ARP cache poisoning.

At this point, any kind of network interceptions can be done. You could view images from the victim’s browser by using driftnet, grab mails with mailsnarf, URLs with urlsnarf, IM messages with msgsnarf, sniff files from NFS traffic with filesnarf, and intercept packets with wireshark or ettercap.

While I had driftnet active on the attacker machine, I opened the contributors page here at InfoSec Institute and got the following:

Just to be a more prying attacker, I had a tmux session with mailsnarf, msgsnarf, and urlsnarf monitoring on 3 panes.

I won’t show what the end results of those were, as I’d be putting my privacy in jeopardy by doing so.

Okay, I will be nice enough to show results from urlsnarf and dsniff:

While urlsnarf was grabbing the URLs, I also kept dnsiff monitoring the victim, and there was an FTP authentication attempt that prompted this:

Also, the dsniff suite provides more MITM tools including sshmitm, webmitm, and webspy.

An old way to achieve something similar but not quite specific enough is to use another tool from the dsniff suite called macof, and oh! I didn’t mention arpspoof is also from the dsniff suite. Macof floods switched LAN ports with random MAC addresses.

That looks too noisy, and since it just starts flooding, I only take it for an option when I’m considering ARP spoofing as a Denial-Of-Service asset.

ARP spoofing attacks would be impossible if there was an authentication mechanism for ARP replies.

Mitigating ARP spoof attacks

• Prevent duplicate MAC: This can be achieved by using a good Intrusion Detection System (IDS). It can be set to detect large ARP traffics, duplicate MAC, and MAC floods. Taking a closer look at figure 9, there are two IP address entries with same MAC 00-0C-29-81-19-63 which is something to be prevented.
  
• Keep track of ethernet/IP address pairings. Arpwatch tool or ArpSNMP comes really handy when trying to use this. It is a Unix utility.
  
• Use static ARP entries. As seen above, the affected entries in the victim ARP cache were dynamic entries.
  

Arpwatch and Arpsnmp have been mentioned earlier. Another good tool for a preventive measure on ARP attacks is Arpon.

Before discussing arpon further, I will also like to discuss the arping tool. Arping works just like the ping command line utility. Unlike the ping, which checks if hosts are reachable by their domain names or IP addresses and then resolves domain names into IP addresses, the arping resolves pinged IP addresses into MAC addresses and also allows pinging MAC addresses directly with an interface specified with the -i switch.

ARPON is a ARP handler inspection tool that secures the ARP. It uses two techniques to achieve this. The SARPI (Static ARP Inspection) and the DARPI (Dynamic ARP inspection). The two techniques protect against both distributed attacks and bi-directional attacks as we have demonstrated with macof and arpspoof. To properly use the bi-directional protection of Arpon, it should be installed on both network devices including the target and remote host, which are our victim machine and the default gateway. For the distributed attack prevention, Arpon should be installed on all machines in the LAN.

Arpon has a daemon that runs from boot when installed on a computer. It helps fight against ARP poisoning attacks with the SARPI and DARPI by blocking them, while tools like Arpwatch and Arpsnmp will just point out the attack presence.

Conclusion

ARP attacks seen involved taking advantage of the fact that the ARP protocol resolves addresses from the network layer of the OSI model to the data-link layer without any form of authentication. By sending excess ARP replies, an attacker can fool a target machine that he can be addressed by the hardware address of another machine in the network. One major way to prevent this is to avoid MAC duplication in the ARP cache. Various tools were mentioned for mitigation but Arpon seems to be the most powerful tool presently. A future with IPv6 may help put an end to attacks like this.

Source

[el_eel]

Vorbe din Ferentari.

https://www.google.ro/search?q=ferentari&client=opera&hs=O6s&tbm=isch&tbo=u&source=univ&sa=X&ei=9_7kVKCNL4GdPdOEgPAK&ved=0CCQQsAQ

[Gushterul]

Preventing ARP Attacks Using Dynamic ARP Inspection