Help needed, ARP poisoning possibility

Careful padawan, be sure to follow step 1 of your capture setup.

Arp poisoning is a way to redirect the incoming traffic of the victim to your own device by convincing the local senders of that traffic (which may include the gateway router) that your device's MAC address represents the victim's IP on the LAN, and forwarding the received packets to the victim's own MAC address after copying and saving them, or modifying them, whatever the goal of the attacker may be. Or the attacker may want to impersonate the victim rather than "wiretap" its traffic.

Such activity should normally not have a devastating impact at the overall throughput of a switched network, at least directly - in contrary to arp flooding, which makes switched networks act as a single collision segment, reducing available bandwidth drastically.

But on a shared media network, like the wireless ones are, the situation is different - even arp poisoning may significantly reduce the overall throughput of the network if the amount of victim's incoming traffic occupies a large share of the total bandwidth, so if the attacker effectively doubles it, the bandwidth becomes almost completely exhausted.

As far as that, your assumption that arp poisoning may be the reason of network slowdown makes sense.

My mom's golden rule is "no need to search for evil intention where mere stupidity is enough to explain". So to check whether the occurrence of the same IP is a consequence of an evil activity or stupidity, you should look at the relationship between the two source MAC's activity. To get as much of the victim's traffic as possible, the attacker must refresh the other machines' arp tables either constantly&frequently by "gratuitous arp" packets, or respond to their arp requests sooner than the victim.

to be continued...

To find out, you have two possibilities, one very limited and one very aggressive:

• if you'd capture using promiscuous mode of your PC's wireless adaptor, you'd be able to see only part of the network traffic: the one which is unicast to you and the one which is broadcast to everyone. So you could only see the arp requests and gratuitous arps which are both broadcast, but not arp responses which are unicast to the source of the request being responded. So if the attacker uses arp responses (at least most of the time), you cannot spot it this way.

• if you are lucky to have a Mac or a linux PC with an appropriate wireless adapter/driver, and thus to be able to use monitoring mode: assuming that the WiFi uses some kind of encryption, it is actually not of much use in this case unless you'd be able to restart the AP after starting your capture, so that all devices in the network would have to re-associate to the AP and thus you would be able to capture the EAPOL handshake of all of them. This would allow you to see the unencrypted contents of all the traffic of all devices in the WiFi network which is not encrypted on another layer (ssl, tls), and you would also instantly see whether one of the MAC addresses in question is forwarding received packets to the other one (except the AP which relays wireless frames between clients by principle!), which would be a clear indication of evil intention. What I've just written is true if the wireless security is based on a common password for all devices (wpa-psk) as I suspect from your description of the company; if by chance the devices use individual passwords, restarting the AP won't allow you to decrypt all traffic. But try to think as the attacker: if it would be possible to gain access to victim's data this way, why would he have to use arp poisoning? It would make sense only if he would need to impersonate the victim and doing so successfully would require to send from the victim's IP address, which is also quite unlikely unless the IP addresses in the wireless network are public ones.

to be continued...

So I'd vote for misconfiguration of one of the devices using the conflicting IP. This is enough to consume more network bandwidth too, because tcp sessions would be broken for both, causing lots of retransmissions in better case and RST in worse.

If you'd be in position to manage the AP, it should be much easier to find out, by simply blocking the two MACs one by one and watching who'd start complaining. If two people would complain and their devices' MAC addresses would really match the blocked ones, stupidity was the explanation; if not, something evil was going on but if you weren't lucky and banned the victim's MAC first, you've just warned the attacker that someone is after him.

The guy who manages the AP should not be the attacker as he can use simpler and, more important, harder to detect methods to reach the same goal for which an ordinary user would need arp poisoning, so it should be safe to talk to him.

And the last point, with 30 computers + unknown number of gadgets on a single AP you may have a lot of trouble even without cloned IPs. Imagine all those Android devices upgrading applications twice a week.

Well, you've mentioned just two MAC addresses to share an IP in your original question, so it didn't come to my mind that one of them would be the gateway's one.

As you say that both your own IP and the gateway's (AP's) IP address are getting redirected to the attacker's MAC, there is zero chance that there is no intention.

I have no right to complain that you've taken an active step by setting the MAC address of the router manually at your own PC as I've recommended you other active steps, but by "protecting" yourself that way, you have actually highlighted yourself enough, as the guy can now see that your PC receives some traffic from the 'net but cannot see the opposite direction of that traffic, which indicates to him that your PC behaves different from expectations. So if not too late, I'd remove the static arp record.

If you use https to read web pages and your browser isn't configured to dump pre-master keys to a file, your web browsing contents should still be safe but the hosts you visit are known (and I don't know whether you read e-mails using a webmail or whether you download them using IMAP and if the latter, whether it uses ssl/tls). So unless you work at this site from a device which is not connected through that WiFi, the mere fact that you browse this site has got you hours from being spotted, but I guess you've realized this in advance.

And as you cannot do anything about the AP configuration, you cannot do anything to make it send your packets to you directly except actively "arp poisoning" it with your PC's real MAC address yourself, in order to get a bigger share of your data directly and not via the attacker's PC. But this would have the same alerting effect to the attacker.

So you'll likely have to talk to the boss soon. I don't know whether to hope that you'll learn that the boss knows about the activity as someone else is sending data out of the company and the IT guy is investigating who is it, or to hope that the current culprit is the bad guy himself. Neither possibility sounds nice.