This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Hi all,

please help me regarding this case: I've just started to work in a office with 20-30 people. This office has already used to "slow-intermittently disconnected" internet for some times. The main problem is this office rely heavily on internet to perform its service. Being a little bit curious, I tried to scan the network using Wireshark with arp.duplicate-address-frame filter, and it brought a lot of results, from the same 2 macs addresses. This office uses only wireless network for every computer. It serve around 30 computers (not counting the gadgets), and so far has no other problem except for the previously mentioned one.

I am suspicious that there are someone in the office who are using some kind of arp poisoning (or something else) that cripple the connectivity. I am not the network administrator, and I need some solid proof before bringing this up to my boss.

Please help!

asked 17 Jan '16, 23:14

trickyfin's gravatar image

trickyfin
6113
accept rate: 0%

1

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

(17 Jan '16, 23:29) Jaap ♦

don't worry, other than the company has no policy (yet) regarding the issue, I have some connections with the people higher up, and I will do some mild approach first before do anything rash.

Anyway, please help...

(18 Jan '16, 07:54) trickyfin
1

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...

(18 Jan '16, 15:03) sindy
1

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...

(18 Jan '16, 15:30) sindy
1

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.

(18 Jan '16, 15:35) sindy

@sindy: Thank you for the comprehensive respond. It added another perspective into my understanding. Unfortunately, I am in no position to manage the AP, and more unfortunately, the guy who managed the AP is the most likely culprit based on the evidences. If the guy who managed the AP is a real IT guy, what you have said might be done, but since he was a GA guy with no real IT background, I have to still consider him.

Edit: misconfiguration of one device is unlikely, because the conflicting ip is the gateway one (192.168.1.1), and if someone knows enough to set his/her ip manually, he/she should have known that the number shouldn't be used.

UPDATE I've been staking out in the office for the possible culprit. I came early this morning, set all the monitoring software, check the real router MAC address, and since I've got the other mac address yesterday, I wait for the other to come and see which group trigger the sensor.

It was the IT guy....

I won't do anything rash yet, and maybe I will talk to people higher up about this problem, and depend on their answer, setting every operational computer arp table to static might be the one to solve everything.

(The IT guy has just came to my place and set up the "shared folder" connection, and I almost got caught ^^;)

I am still expecting more insights, if there are any. Also, I will be glad if anyone pointed out what's wrong in my method, if they found one. Please help!

(18 Jan '16, 18:15) trickyfin

Another update (since they won't let me edit my previous comment any more) I did a temporary fix (at least for my computer) by setting the arp table to static, but then I notice that the oncoming traffic don't come from the gateway but from the attacker ip. Is there any other way to protect myself completely before the real fix applied? Please help!

(18 Jan '16, 19:55) trickyfin
1

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.

(18 Jan '16, 22:17) sindy

So the counter arp poisoning still an option...

That's actually another question I wanted to ask. Do HTTPS really secure the connection?

I am currently still waiting for the time to talk to the boss(es), while assessing the real situation here... (hint: office politic, fraud risk, etc,)

Thanks for the helps, especially @sindy, you really help me a lot!

(18 Jan '16, 22:32) trickyfin

I've converted your "answer" to a comment which it should have been (the forms are a bit confusing, yes). As for the separate question about real security of https:

Leaving aside what NSA guys may or may not be able to do, and leaving aside cryptoanalytic geniuses working in companies where IT is not the focus, an ordinary attacker may use one of the following:

  • a "passive attack" (I like the contradiction of the name). Incidentally, I wrote an answer about it to this question. In your case, the attacker may have access to your browser's pre-master keys, and theoretically, if he is a really bad guy, to keys of some of the servers, but not all. The way how he makes it possible to capture packets on the path between you and the server is not important, so arp poisoning is one of possible ways.

  • a "man in the middle (MITM)" attack. It requires that the victim confirms to continue browsing a page despite that the browser asks them for confirmation, claiming that there is something wrong with the certificate. I am definitely not an expert in certificates but I could speculate that it would be possible to override this need for victim's cooperation by generating (even dynamically) a certificate (with an encryption key) mimicking to be a certificate of a particular server and link it to a forged CA root certificate which your OS/browser would be configured to trust. That way, the traffic would be encrypted between you and the "box in the middle", and then between the box in the middle and the server, but the box in the middle would have access to the unencrypted contents of the communication. Again, arp poisoning is one of the ways how to insert the "box in the middle" into the path between the client machine and the server. So if your browser/OS is configured to trust some additional certification authorities, it is a strong hint in this direction.

(19 Jan '16, 00:36) sindy

Just one more remark, I was believing that if you use anonymous browsing in Firefox, the keylog file is not generated even if the browser is configured so, but someone has corrected my naivety and has told me it is generated too.

(19 Jan '16, 03:51) sindy
showing 5 of 11 show 6 more comments
Be the first one to answer this question!
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×78
×4
×4

question asked: 17 Jan '16, 23:14

question was seen: 1,523 times

last updated: 19 Jan '16, 03:51

p​o​w​e​r​e​d by O​S​Q​A