2

I am trying to create a script that will do a basic ARP spoofing attack (I choose this StackExchange website because the question is more about the theoretical side), and I see no reference to the attack in case the computer already has the gateway IP in its cache (and the same for the target's IP in the gateway cache).

As I see it, the computer most of the time should have the gateway in its cache, and therefore an attack will be possible only if one can predict when the ARP table gets reset automatically or can answer before the gateway.

I would like to understand which ARP replay should he save and which he should discard; and whether there is a way to use the attack even if the gateway IP is in the target's cache.

Patrick Mevzek
  • 1,748
  • 2
  • 10
  • 23
hjsv41
  • 23
  • 3

2 Answers2

1

The assumption, "ARP poisoning attacks only work when the gateway's MAC address is not in the victim's ARP cache", is false.

A type of ARP request or reply exists known as a "gratuitous ARP"; from the Wireshark Wiki:

Gratuitous in this case means a request/reply that is not normally needed according to the ARP specification (RFC 826)

A gratuitous ARP reply is a reply to which no request has been made.

The wiki page also has some information about legitimate use of gratuitous ARP replies. However, they can also be used maliciously, and they are the driving force behind most ARP poisoning attacks.

Let's look at an example network setup:

Gateway:
IP address: 192.168.1.1
MAC address: 11:11:11:11:11:11

Victim:
IP address: 192.168.1.100
MAC address: 22:22:22:22:22:22

Victim's ARP cache:
192.168.1.1 is at 11:11:11:11:11:11

Attacker:
IP address: 192.168.1.200
MAC address: 33:33:33:33:33:33

In this case, the gateway's MAC address is already cached by the victim, and the attacker wants to convince the victim that they are the gateway. The attacker can send a gratuitous ARP reply to the victim:

192.168.1.1 is at 33:33:33:33:33:33

Even though the victim did not request this information, it will happily update its ARP table:

Victim's ARP cache:
192.168.1.1 is at 33:33:33:33:33:33

Now the victim's traffic will go to the attacker instead of the gateway.

So, the takeaway is that gratuitous ARP replies can be used to update existing, legitimate entries in favor of malicious ones. The victim doesn't have a way of knowing whether or not the gratuitous ARP is malicious; what if the machine was just reconfigured or had a NIC swap? There is not really a way to tell.

I would like to understand which ARP reply should he save and which he should discard

As somewhat indicated above, the most recently received ARP reply is used to update the cache, regardless of whether is was gratuitous or not.

Community
  • 1
multithr3at3d
  • 12,355
  • 3
  • 29
  • 42
  • That clarifies the matter, thanks. Do you happen to know if this(gratuitous ARP handling) is configurable on most systems ? – hjsv41 Apr 21 '18 at 15:27
  • @hjsv41 I don't know much about that, but there seem to be quite a few results searching online. – multithr3at3d Apr 22 '18 at 01:24
0

As the term "cache" implies, it's a temporary storage and is subject to refreshes. Computers can refresh these values when a timeout strikes. These timeouts are configurable and are different per OS.

Attack wise, if the target removes that entry from the cache, and wants to talk to the gateway again, it will send another ARP request. If you're faster than the original gateway, you'll be able to reroute that traffic to an address you specify.

ndrix
  • 3,206
  • 13
  • 17
  • So as an attacker you have a small and precise window of opportunity to attack ? Beacouse all the scripts that I saw online that implemnts the attack dosent check for when the target broadcast arp request. – hjsv41 Apr 20 '18 at 17:57
  • I guess most tools just brute force the network with replies. Waiting (and the duration of the logic of responding) for a request may lose vital milliseconds. – ndrix Apr 20 '18 at 18:01
  • The article I referd to is https://null-byte.wonderhowto.com/how-to/build-man-middle-tool-with-scapy-and-python-0163525/ in this article the arp replay is sent only once so it cant be brute force. Thats why I didnt understand the method used in the article and thought its a gap in my knowledge. – hjsv41 Apr 20 '18 at 18:19
  • Yeah, the article assumes you don't have the mac address in the arp table. You can check the arp cache with with *arp -a* – ndrix Apr 20 '18 at 18:45