ARP poisoning/MITM attack prevention

...it all started the other day when Irongeek posted his tutorial about nmap. Was really good. So then I browsed around on his website, looking for what all more stuff he had done. I saw one eye catching tutorial: Cain to ARP poison and sniff passwords

I had used Cain before to sniff passwords from a HUB, but had no clue about how easy it is with ARP poisoning and Man-in-the-middle attacks on a SWITCHed network, until I saw this tutorial where he shows how to do it in less than a minute.. ! I thought, maaan, that was way too easy to be true on any SWITCHed network. Decided to test it at work, and no, it's true alright, boy did it catch a bunch of passwords...!

So now I'm really concerned about the security at work. At our college we have a few thousands computers. Currently you can pick up passwords easily from pretty much anywhere...

What are all the options to secure and prevent one self from these kind of attacks???

I've tried to do some research and so far I've found this out:

1. You can "hardcode" all the MAC addresses on your network, but it's a big pain if you have a bigger network... This will make it a lot more secure, but there are obviously still ways around it...
2. Make sure ALL the communication on your network is using STRONG ENCRYPTION.
3. You can buy network devices that can detect (but not prevent) ARP/MITM attacks and then notify you about it... (anyone who can recommend something good?)
4. At first thoght you can only do this on the same local subnet you are connected to, but just found out it can be done on an internal network remotely, as long as the internal network has internet access... (which we do.. !)

This is really bad stuff! Could some of you give me more info about all this, and surely there must be a better way to protect one self against it... or??!

Quote:

---

2. Make sure ALL the communication on your network is using STRONG ENCRYPTION.

---

Ahhh.... The double edged sword....

Allow only encrypted transmissions:

Pro: It makes many attacks fail simply because the information required to assist the attacker in the attack is no longer available to him without a serious commitment to cracking the keys that will require substantial computing power and time.

Con: As a system admin I can't see what is going on on the network. All traffic monitors show the same thing, (encrypted traffic), and IDS' simply don't work.

Allow only unencrypted transmissions:

Pro: I can watch you. I can see everything that happens. My IDS' and other monitors work so I can detect the anomolous traffic and mitigate it.

Con: The attacker who gains a foothold can sniff the traffic the same as I can and exploit the information gained more easily...

Hmmm.... What to do?

My opinion: If you can't see the traffic you can't understand it. If you can't understand it then you can't detect the intrusion. Thus, you have to be able to see the traffic.... Run the trusted network unencrypyed, watch for encrypted streams and validate them or kill them.

Think one of your best ways to combat this would be through port security (which is what you mentioned when you said statically enter everyone's MAC). What you are essentially doing is telling a switch that on that port, only this one MAC is authorized to use it. Can be very work intensive to do it and alot of work to maintain it. I am not sure about other vendors, but Cisco does offer an in between that allows you to set a maximum # of MAC addresses for a port and another setting that prevents a system on that switch from receiving broadcast/multicast traffic.

Anyway, the first option should work for you. Simply set the max # of MAC addresses per port to 1 and then any arp spoofing will fail because you would have more than one MAC address there...

Couple of things:

First it needs to be mentionned that strong encryption itself isn't the silver bullet when it comes to man in the middle attack: while the encryption itself is strong, the weakness is in the key exchange and authentication. For example, it's possible to conduct a MITM on SSL and SSH connections and if the user ignores the warnings from the browser/ssh client that the certificate is invalid or that the host fingerprint is wrong, you'll be able to sniff the session....
So it's only strong *mutual*authentication, combined with strong encryptiong that really aleviates this problem.

As for prevention mesures you can:
-as nebulus mentionned, use port security on your managed switches. The easiest way to set this up is to run the network in a known trusted state first, let the switch build it's MAC table and then freeze the MAC table on the switch.

-use port level authentication with 802.1x

-use the arpwatch software to monitor ip/mac associations on the network.

Other than that I'm not aware of much more that can help...


Ammo

Thanks a lot guys!!
As always, very good advices!! :)

Btw, are there any arpwatch programs for windows that monitors the network?

Oh, and what about the "rumor" about beeing able to do MITM attacks remotely over the internet...? Is that really possible? Have read/heard both ways; can't be done, cause the routers cuts the MAC's off, but also heard it still is possible, just never heard how you could make it possible...

Thanks again!

Quote:

---

Oh, and what about the "rumor" about beeing able to do MITM attacks remotely over the internet...?

---

In theory, yes, however technically it is a very difficult process to get setup and working correctly. If you have a basic understanding of routing, you'll quickly come to this conclusion.

Been testing and playing with it some more, and just discovered something new I haven't heard about before.

We went to the Bread CO to see how they address users being able to MITM attack other wireless users. And they actually have something different in place! :)

When using Cain, AP and the whole IP range available for users, all IP's already had "ghosted" MAC addresses, they all had the same MAC, if they were in use or not.

I have never heard of this "solution" before. Anyone who knows more about it, and how effective it really is?

Without any further "hacking" we weren't able to execute any successful MITM attack.

Alright, unless someone can actually tell me how this works, I don't believe it's possible now.

I have a scenario which may accomplish this:

The nearest router to the workgroup switch runs a layer 2 firewall, altering the MAC addresses on all outgoing packets to be the same. The workgroup switch is actually a layer 3 switch, and does not rely on MAC addresses to switch traffic.

Packets travelling from workstations to the nearest router would then bear the MAC address of whatever the layer 2 firewall is altering them to be. This MAC address would of course be irrelevant as the workgroup switch switches based only on IP addresses.

Now, all the workstation NICs must be placed into promiscuous mode, either through some network setting of which I am unaware, or by jumper settings on the card itself, if such cards exist. The network stack on each workstation should then recieve traffic routed and switched by IP address alone, and ignore MAC addresses.

Would this work?

"Btw, are there any arpwatch programs for windows that monitors the network?"

ettercap for windows (linux port, but seems to be half decent in functionality, not sure on XP anymore, but server's should be fine, not sure how ettercap uses raw sockets in windows), can detect machines running network cards in promisc, and can display who's running mitm attacks (not sure exactly how this works)

other than that, Snort IDS can detect an ARP Spoof and kill the connections, also a port to windows

I read through this post again and I was a little concerned with the sound of how easy this technique is advertised by someone who tried it. I was left with the same feeling I get when I watch those chuckle heads wax cars that have been in the junkyard using the miracle deluxe space age car wax...."Anyone can do this folks....it's simple!"

That said, IMPORTANT SAFETY NOTE:

While this app and others such as frag router allow you to ARP poison and route traffic through your box, if you attempt this a on an enterprise WAN (and you have no idea what you're up to) with a simple desktop or laptop, it's very likely you're going to DoS the place in record time. I can assure you that if your IT staff is half way decent you are going to get a visit very quickly. If you are going to play with this, be very careful as the end results may land you a fabulous position at McDonalds.

One last thing, every Cisco device with a newer IOS can prevent ARP poisoning. All of mine are set to do this.

Thehorse,

Yes, I was very surprised how easy it was to do a MITM attack. I always thought it was a complicated thing until I saw the tutorial made by Irongeek.
Since he didn't show any way to prevent it, I was hoping I would find some good answers here.

You mentioned your latest Cisco routers can prevent ARP poisoning. Is this done by what has already been mentioned in here, by fixed MAC/port settings and only allowing one MAC per port, or do they actually have a "check-box" for preventing ARP poisoning?

To give you a little background, I work at a college taking care of a bunch of webservers. I'm not responsible for the routers/network. But I think it's a big concern for the servers I'm responsible for, so I made these tests, and of course informed the network guy as well, to have him look in to this and hopefully fix it.

Thanks!

If I may...

Cisco routers prevent arp spoofing by locking each port down to the first mac address it sees, or with some, you can "freeze" the mac table in a certain state. Although this would prevent arp spoofing, it would not, stop arp poisoning, since an attacker is sending a false arp reply with its own MAC address, and so there is still only one MAC address out each port.

As for the prevention of arp poisoning, and therfore MITM attacks, the switch intercepts ARP replies and inspects them to ensure they are destined for the correct machine and coming from the correct machine. It already knows that the gateway, say 192.168.0.1, is on port 1, for example. When a workstation, say on port 2, sends an arp request for the gateway, the switch will inspect that packet. Assume the attacker is on port 3. Since the switch knows that the response to the arp request sent from port 2 must come back from port 1, it will drop the arp reply which the attacker will send from port 3. A kind of layer 3 firewall on the switch. This process is known as Dynamic Address Resolution Protocol, as far as I know.

In short, the switch ensures that arp replies are only sent from the machine they are supposed to be sent from.

Although I am aware of the theory behind it, I don't know exactly how to implement this on most switches, but it would likely be something as simple as an "enable darp" command. I'm sure somebody knows better than I do.

Striek,

Thank you much for that information! :)

Could TheHorse or somebody else confirm to me if that is actually an option, "Enable DARP"?

I know our Network Manager is tired of Cisco, and he is now replacing most switches with HP swicthes. Since I don't mess with that kinda stuff, I have no idea if they are comparable or not, but I will ask him if he knows about DARP.
I have already told him about all your advices, but locking every single port down is probably not gonna happen. He's the one and only guy taking care of the network, with a couple of thousands computers, using a DHCP network, and computers and rooms changing all the time, it would be way too much for him to be able to handle...

BUT, if this DARP is an option, that might in fact fix it for us!!?! :)

Thanks again!

ps. Ammo, have to add I just tried what you said about SSL, and yeah, that is some real scary stuff. Since we don't use public certificates, and we always have to hit YES to accept it, you can capture all the SSL sessions as well, getting all the passwords in clear text and no one would have a clue... maaaan! We are now considering getting Verisign certificates, but man are they expensive!!

Quote:

---

Originally posted here by SawPer

ps. Ammo, have to add I just tried what you said about SSL, and yeah, that is some real scary stuff. Since we don't use public certificates, and we always have to hit YES to accept it, you can capture all the SSL sessions as well, getting all the passwords in clear text and no one would have a clue... maaaan! We are now considering getting Verisign certificates, but man are they expensive!!

---

Well, you could always setup your own internal CA and have all your users install that root ceriticate once.

Technically, the only diffrence between a Versign issued cert is that the verisgned root cert is installed by default on most browsers...


Ammo

Yes, it's called Dynamic Arp Inspection or DAI. It's a little more involved than a single "enable" command. I use it here and it works wonderfully.

OVERVIEW:
========
Map out your neighboring switches/routers
Configure ARP inspection
Setup your trusts
Verify the bindings
Look at some sample inpsection traffic

This Cisco doc will get you started. It's not exactly written for a n00b but if you're reasonably familiar with Cisco gear, you should have no issues. This deals with the 4500 catalyst switches, which I happen to have here but the commands are transferrable.

http://www.cisco.com/en/US/products/...08019d0ca.html

TheHorse,

Awesome!! Many thanks! :)

Yeah, our network guy knows some Cisco, so he should be able to hanlde it. I will check with him.

Thanks again!!

Yick, it seems to be a proprietary solution from Cisco! :(
HP doesn't seem to have anything similar... not good... not good at all... what to do now??

I guess I will do some research online to try to find something about HP switches... unless someone here already knows about them?

Really shocked how over locked this problem is! It's like everybody is trying to stick their head in the sand, pretending this problem doesn't exist! :(
When it's so easy to do a MITM attack, you would think there would be tons of good solutions against it...


Striek,

Just to confirm your last comment. Even IF we did lock every single port down and only allowing for 1 MAC/port, you are saying ARP poisoning still bypasses this, cause the attacker is just lying about his IP/MAC address directly to the victim, which then continues to talk to the MAC, which is completely legit as far as the switch is concerned...
I don't see any solution for us at all then, if we don't get Cisco.. ! :(

...and then depression set in.. heh!

Cisco was specifically mentioned somewhere in the thread and I happen to run a Cisco shop here. HP certainly has something similar.

--TH13

YEEESSSSSSS!!!!!!!!!!!!!!!!!! :)

We were all depressed, hanging around, thinking there is no way we can prevent this from going on... then we thought.. well.. what if we forced everybody to have static ARP's??

So I tried: arp -s [IP] [MAC] (of my gateway)

Fired up Cain, and Cain wouldn't even show my computer as getting poisoned!!! So it didn't catch a thing now!!! YIIIEEEEHAAAAAA!!!

Now if this is all waterproof, this is a fairly simple solution compared to buying new Cisco switches for the whole network!

Any comments about static ARP tables? Is that a good enough solution?! Some research seems to show that Win98 allows the static ARP's to be over written, but it doesn't look like that's the case from our test today on WinXP at least...

Thanks again for all help!!

ps. Hey, if you just feel like it, you are very welcome to give me some Anti points for this one.. heh! ;)

hahaha, lol

SawPer, "1. You can "hardcode" all the MAC addresses on your network, but it's a big pain if you have a bigger network... This will make it a lot more secure, but there are obviously still ways around it..." You just answer your own question buddy ?

On a only switched network, you will have to setup all the static ARPs for every computer, but as the network grows, and the target would be yourself and the router, then a simple static MAC addy for the gateway would be all that is needed....

Get me ?

Yeah, I like it! It's actually not that bad at all! :)
All workstations just need to load a batch file adding the gateway to the static ARP table, plus any "sensitive" internal servers on the same subnet.

FYI:
If you are interested, I have done some more tests with static ARP. Static ARP tables work fine with WinXP and Win2003 Server, but it does NOT work with Win2000 or anything older!
When I configured a static MAC for the gateway of a Win2000 Server box, it got overwritten by the poisoning by Cain, and the static MAC stayed static with the fake MAC! Wonder who thought that bright idea out? Kind of defeats the idea of a static ARP table... heh?!?

Quote:

---

Originally posted here by SawPer
Yeah, I like it! It's actually not that bad at all! :)
All workstations just need to load a batch file adding the gateway to the static ARP table, plus any "sensitive" internal servers on the same subnet.

FYI:
If you are interested, I have done some more tests with static ARP. Static ARP tables work fine with WinXP and Win2003 Server, but it does NOT work with Win2000 or anything older!
When I configured a static MAC for the gateway of a Win2000 Server box, it got overwritten by the poisoning by Cain, and the static MAC stayed static with the fake MAC! Wonder who thought that bright idea out? Kind of defeats the idea of a static ARP table... heh?!?

---

Thats very useful to me, thanks heaps. AP awarded.

I was basing alot on the fact, that on a system i could just do that, then I would be ok... Well, there goes that :P