3

I am only recently learning about the nuances of networking, but if a malicious user responded to an ARP "who is" when they should not have, what happens?

cabbagebot
  • 133
  • 3

2 Answers2

5

It depends on the listener, but typically the most recent response wins (often at the switch level, not just the computer level). So, packets for that IP address are routed at something that looks very much like random to one or the other of the target servers.

This usually ends poorly, but only because state such as TCP connections isn't transportable. If both machines implemented the same UDP service, you might not even notice.

Daniel Pittman
  • 5,842
  • 1
  • 23
  • 20
  • 1
    Thanks very much! Is this a common man-in-the middle technique, would you know? – cabbagebot Mar 07 '12 at 01:14
  • 2
    @cabbagebot: ARP poisoning is a valid and common enough attack vector given it's limitations. You have to be on the same local link as your intended target, so out of all attacks it tends to be a lesser concern. However, if you're running a public network of some kind then definitely be wary of this one. – Matthew Scharley Mar 07 '12 at 01:40
4

One of my experiences of arp problems generally was with some customers of our server services who set static IP addresses on servers in DHCP ranges. The end result for the user was that services would intermittently switch between the conflicted targets for each new request (approx 50% connections established to each server, with the "wrong" one serving 404 errors).

I would guess that this is because the ongoing TCP connection did not rely on arp during ESTABLISHED connections, only when initiating. (but I am no network bod so don't quote me ;-)

However my experience of ARP spoofing attack technology is different, because the attacker really wants to appear to be the correct Host, even in the conflicted state.

So to achieve that the malicious host sends out a continuous arp storm of packets, this is intended to make sure that at any given time, the target device received the an arp response more recently from the attacker rather than the genuine host.

When this happens most of the arp packets are from the attacker, so most of the TCP connections from clients connect to the malicious host. (something like 95% to attacker and 5% to genuine host)

This is obviously easy to detect by IDS because of all the arp traffic is not consistent with the normal parameters and levels.

In the situation with the mistaken dual IP problems, the gateway sees packets like this;

host1(arp) -> ip set to host1
host2(arp) -> ip set to host2
host1(arp) -> ip set to host1
host2(arp) -> ip set to host2
host1(arp) -> ip set to host1

however with the malicious attacks it is more like this;

host1(arp) -> ip set to host1
attacker(arp) -> ip set to attacker <-- attacker is man-in-the-middle here
attacker(arp) -> ip set to attacker <-- attacker is man-in-the-middle here
attacker(arp) -> ip set to attacker <-- attacker is man-in-the-middle here
attacker(arp) -> ip set to attacker <-- attacker is man-in-the-middle here
attacker(arp) -> ip set to attacker <-- attacker is man-in-the-middle here
attacker(arp) -> ip set to attacker <-- attacker is man-in-the-middle here
attacker(arp) -> ip set to attacker <-- attacker is man-in-the-middle here
attacker(arp) -> ip set to attacker <-- attacker is man-in-the-middle here
attacker(arp) -> ip set to attacker <-- attacker is man-in-the-middle here
attacker(arp) -> ip set to attacker <-- attacker is man-in-the-middle here
host1(arp) -> ip set to host1 ** <-- ** not here though
attacker(arp) -> ip set to attacker <-- attacker is man-in-the-middle here
attacker(arp) -> ip set to attacker <-- attacker is man-in-the-middle here
attacker(arp) -> ip set to attacker <-- attacker is man-in-the-middle here
attacker(arp) -> ip set to attacker <-- attacker is man-in-the-middle here
attacker(arp) -> ip set to attacker <-- attacker is man-in-the-middle here
...

Tom
  • 11,176
  • 5
  • 41
  • 63