0

There is something I do not understand about arp spoofing, and no article I read so far seems to explain it:
Assume the following setting: We have three hosts A,B,C with ip addresses 192.168.178.{10,11,12}, all hosts are connected to each other by a single switch. Now host A wants to communicate with hosts B and hence sends out an arp request to get the MAC address of 192.168.178.11. Host C wants to intercept the connection and so he sends out an arp package relating 192.168.178.11 with his MAC address.
I guess C strictly has to wait after B responded, because if the package of C would arrive first then B's response would still reach A after that and then the arp cache of A would replace the MAC address send by C with the MAC address send by B because the latter is newer (maybe I already got something wrong here?).
But now to the actual problem: Even if C sends out his arp package after B, then this package would still be addressed to a broadcast MAC address, and so it should also reach B who now reads an arp package from which he can conclude that either

  • his ip address is not unique or
  • someone is trying to arp spoof him

either way the attack would be noticed.
So my question is: How can an arp spoofing be effective if the fact that arp packages are send by broadcast always implies that the victim can be aware of the attack?

Possible explanations I have thought of so far:

  • arp packages can be addresses to a single MAC address, so that be could make sure that only A gets the faked package and not B (but wouldn't the header reveal to B that this certain arp package was not send to an broadcast address and hence should be treated with suspicion)
  • the OS could notice all of that, it just is not programmed to do so
Dominik
  • 101
  • 1

1 Answers1

1

I guess C strictly has to wait after B responded, because if the package of C would arrive first then B's response would still reach A after that

If C is spamming ARP requests or responses constantly, it is possible A will already have C's entry cached and will not even need to reach out to B. Even if it does get an entry from B, it will likely be overwritten fairly quickly.

the OS could notice all of that, it just is not programmed to do so

There is such a thing as "gratituitous ARP", where the attacking host can send ARP responses without being prompted, and other hosts will opportunistically cache this information, likely for performance reasons. I don't know of any kernel implementation that identifies any ARPs as "suspicious", since it's hard for the kernel to know the state of other devices on the network that are trying to ARP. It comes down to trying to separate normal from malicious behavior; did B's IP address legitimately change, or is someone spoofing it? There's not really a good way to tell.

There are some tools and methods to detect or prevent ARP spoofing. I recall there's an open source project "antidote" that sniffs ARP packets, and logs an alert if it thinks something malicious is happening. Enterprise-grade switches may also have mitigations, performing tracking of which port a host is on, and blocking attempts to impersonate that host from another port.

multithr3at3d
  • 12,355
  • 3
  • 29
  • 42
  • It seems to me that if the OS rejected unrequested ARP requests, the attacker would need to make his fake ARP reply arrive on the requester before the intended target's ARP reply, otherwise the ARP spoofing wouldn't work. Is that right? – Alan Evangelista Jul 31 '21 at 12:07
  • @AlanEvangelista perhaps that would make it harder, yes, but the attacker could probably win that race. – multithr3at3d Jul 31 '21 at 13:28