Just released on SourceForge last week by the WestAnnex Security group, ArpStar(arp*) is a new LKM for 2.6 that will detect and defeat all ARP poisoning attacks. http://arpstar.sourceforge.net

here is the abstract description


In short, it is a kernel module countermeasure to ARP poisoning Man-in-the-Middle attacks. It is designed to defeat all ARP poisoning tools such as the popular Ettercap and Cain&Abel.

The arp* (pronounced ArpStar) is a module for the Linux 2.4/2.6 kernels that detects AND defeats all ARP poisoning attacks. Currently, ARP poisoning attacks can be detected by a variety of software programs; none of which can defeat the attack. We intend to change that. arp* at its very core is simply a change in the way ARP packets are handled by the Linux kernel. The functionality that allows arp* to work is kernel Netfilter hooks. By intercepting ARP packets before the kernel can process them, arp* is able to protect the system against ARP poisoning attacks.

Currently, the Linux kernel allows improper ARP packets to change the ARP cache. Unsolicited ARP replies as well as ARP requests actually write changes to the cache. Our implementation keeps track of ARP requests and replies and only allows solicited ARP replies to change the cache. This, by itself, defeats most ARP poisoning attacks. More devious ARP poisoning attacks use ARP requests and colliding ARP replies to poison the cache. To combat these situations we also implement custom handling for ARP requests and routines for collisions. As many ARP poisoning utilities construct packets that are not quite sane, we implement sanity checks to filter out obviously bad ARP packets. Trusted IP/MAC combinations are also allowed using module parameters so users can inform the kernel of known systems.

ARP poisoning signature matching has also been implemented. arp* is aware of popular tools which carry out ARP poisoning attacks. Tools such as Ettercap and Cain&Abel perform their ARP poisoning with unique sequences of packets. arp* is knowledgeable of their preferred methods and identifies their attack patterns accordingly. However, the defeat of ARP poisoning attacks does not depend on recognizing the signature of the attacker. Signatures are simply a way of identifying how the attack is being carried out.

This project has been coded in C and is available as a module for the 2.6 Linux kernel series. The only libraries needed are the included in the Linux kernel. It has also been ported to the Linksys WRT54G


For now, our site is lame, but the module rocks. Take a look. Try it out. Let us know what you think.
email us at westannex@gmail.com


Thanks,
-WestAnnex

Interesting tool. Thanks for the info

I have built a gentoo ebuild for this guy. It isn't in the portage tree yet, but I have submitted it. Those of you that want it now can get it here.

Put it in /usr/portage/net-misc/arpstar (you'll have to make that directory).

cd /usr/portage/net-misc/arpstar
ebuild arpstar-0.5.0.ebuild digest
ACCEPT_KEYWORDS="~x86" emerge arpstar

EDIT:
If you have a portage overlay directory put it in there instead.... otherwise it will get overwritten whenever you do an emerge sync.

Hmm... interesting...

I would like to know HOW it defeats ARP poisoning. I understand the whole trusted MACs idea, but how does it KNOW that the ARP packet isn't correct? Does it just detect for Cain&Abel and Ettercap, or what?

Just curious, as recently I've been getting some strange ARP packets myself... I just got an ARP "Who has" for an IP that has been out of my network for 2 months now (only 3 computers in my network total, too!).

http://arpstar.sourceforge.net/whatisArpStar/

That kinda gives you a basic discription of how it works.

That's what bassdemon copy/pasted exactly....

I want to know HOW it works (without wading through all the code and figuring it out line by line).

That basically says "there are methods to detect ARP spoofing, and we can detect and defeat them!! WOWIE KAZOWIE WE ARE AWESOME!!!".

It's like infomercials that say it will reduce weight, but don't explain how, except some of those have a half assed BS explanation to it.

jtshaw-

Thanks for the ebuild! Gentoo is our preferred distro by far, and we'd Love to get it into portage.

Aeiri-

you're well entitled to a full description of how ArpStar does its job. Since this is basically our first announcement of it's existence, we thought it'd be sufficient to make people aware that it's available.

At the present build, ArpStar detects and prevents ALL ARP poisoning attacks. It will recognize Ettercap and Cain&Abel specifically, and report that recognition. If it does not recognize the tool performing the attack, it will report a generic attack.

As for HOW, what part of the abstract was unclear? I recommend paying attention to the 3rd paragraph and asking questions based on that.


-WestAnnex

Haha...

I missed that third paragraph, I must have been doing something else at the same time and lost track of where I was...

How does it determine which ARP requests are solicited or not?

What does it do in this situation? Does it ignore all ARP requests unless the request is by a trusted IP/Mac?

As all security isn't 100%, this can probably be circumvented by sending a valid ARP request after DDoS'ing a known IP or something. This does, however, look like a really big step in the right direction.

Good work!

Aeiri-
Well, solicitation of an ARP reply == your machine asking for an ARP reply. Essentially, if your box needs to know what MAC is associated with an IP, it will ask for it with an ARP request. Poisoning generally occurs when a 3rd party attacker sends your box an unsolicited(not-requested) ARP reply with a new, malicious IP/MAC pairing. We keep track of your box's ARP requests, and handle unsolicited ARP replies with great scrutiny. Generally, they are dropped.

When your box receives an unsolicited reply your ARP cache may already have an entry for it. What we do is attempt communication with the older(more trusted) MAC address already in the cache with an arp request. If there is no response, we must assume that the machine has in fact been taken off the LAN, and that the colliding entry may now in fact be valid.

Collisions are an uncommon dilemma. It occurs when your box sends out an ARP request and two different replies come back. Bass will have to back me up on that.

Don't make too big a deal out of the trusted IP/MAC address(currently we only allow one, but may allow more in the future). Keep in mind, another way to combat ARP poisoning is with static ARP tables...but they're pain in the arse to maintain, and who really uses them anyhow. We generally use our Trusted IP/MAC as a static entry to our gateway, since that IP rarely changes and it's a common target for a poisoner. Essentially, it creates a hybrid dynamic/static ARP cache, which is a good option to have.

We can't agree more that no security is 100%, and you hit the nail on the head with the DoS attack combo. I think what you meant to say is "what if the attacker sends an unsolicited reply after DoS'ing the machine it intends to impersonate." Well, effectively that appears to our machine to be the same as if the box being DoS'd was physically removed from the LAN. In that scenario, we are more likely to trust the new pairing. We have been quite aware of this more complex attack, and are still looking for the best way to handle it. This is one of the reasons we implemented the Trusted IP/MAC, even though the DoS/ARP combo attack is significantly more difficult and noisy to execute on the attacker's side.

-WestAnnex

Hey all. Ok you wanna know how it works...no problem. We're uploading a technical pdf on arpstar to our website soon (hopefully today) which goes into great detail about how it works.

First off, thank you jtshaw for the ebuild. that totally rocks.

Tech stuff.

ARP requests are not solicited. Terminology there...ARP replies are solicited by ARP requests. So we drop unsolicited ARP replies. If someone just sends you an ARP reply without you asking for it we drop it. If we didn't ask for it we don't need it. And the majority of ARP poisoning tools use this technique. Basically we have a list of IPs that we have sent requests to that is constantly being updated. If the IP is in the list, meaning we have sent it an ARP request and have not seen an associated reply, then we have a greater chance of accepting the first ARP reply that comes back. If it matches what's already in the table we accept it and delete it from the list. That's regular ARP traffic. If it doesn't match what we already have then it *could* be a poisoning attempt or the other machine could have left the network and a different machine has legitimately taken its place. So we drop the packet and try to assess the situation.

There are two possible issues with this that are currently limitations of the ARP protocol as we see it. We cannot defend against ARP poisoning if there is no ARP entry currently in the cache. If there's no valid entry to compare against we cannot know if the new entry is valid or not. Unless ARP was modified to have a signature with your MAC address or something else there's not much we can do about that. But that's why we did add the trusted ip/mac pair. It helps mitigate that situation some. The other is what you suggested, Aeiri. If you DoS'd a system and took its IP. There's not much we can do about that either. From your end it looks as if the machine simply left the network and another took its place. We need this ability since we're using dynamic tables and presumably dhcp. Otherwise you'd have a static network. We do a little to work with this problem but it does still exist.

Collisions occur when you send an ARP request and multiple replies come back for that address. How can we know which is correct? If an entry is already in the table we take that one. If there is no entry we have to make a choice between integrity and availability. It's a module parameter which you can specify, default set to integrity. Until the module receives only one reply back it will not allow either into the table. This means you do not want a connection unless it is the right connection. You'll presumably notice the problem and fix it (possibly removing someone from your network or reporting it to the network admins etc). If you opt for availability, it will take the first response and go with that as the valid entry. This means having the connection is more important than the integrity of the connection.

BUT as Rockcrusha said...collisions are very rare. Ettercap and Cain and Abel don't really make use of them. Seringe does...but it's not a very effective tool in the first place. It just kinda messes up a network. That's kind of a crash course in how it works. We're trying to put up a very thorough explanation on our webite. It'll be there soon so check it out. In the Documentation section.

Anything else I can help with?

Swi+ch

www.westannex.org

ok we have a pdf up on the site that is more technical. it's in the documentation section.

Swi+ch

FYI: We have posted an unoffical slide presentation that goes into more detail about the methodology we used. The link that Swi+ch mentioned is at: :-)

http://arpstar.sourceforge.net/docs/arpstar.pdf

-ZG

Well what I'm saying is dynamically changing your MAC address (in memory, obviously not in hardware) to the DoS'd computer's. ("killall dhcpcd;ifconfig eth0 hw ether $x;dhcpcd", $x being the DoS'd MAC address)

This would actually look like the computer disconnected, and reconnected, not that another took it's place.

I think ARP needs to be eradicated completely... ARP wasn't designed with security in mind, and we should create something else that is.

Another idea for you guys to add would be if you get an unsolicited reply (wrong word I used there last time), you take that MAC/IP combo and blacklist it, unless it's already in the ARP table. This would block that person from poisoning when you DO request an ARP packet (creating a collision, or not if they DoS the box), and if they try to make you block a valid address (such as them flooding you with a valid MAC/IP combo to get you to block them, and trick you into getting the fake one), it will not block it.

well we totally agree about the problems in ARP. ARP is a terrible protocol. And imho it should be replaced. But seeing as almost every system uses it and it doesnt look like it's going to be replaced like it should...this is our solution. You might want to check out S-ARP. Secure ARP.

http://www.acsac.org/2003/papers/111.pdf

Pretty much ARP but with public/private keys. This would help a lot but I have only seen this whitepaper and no implementation.

As for what you're saying about the DoS and blacklist...There's pretty much nothing you can do about the DoS without creating the possibility of another DoS. For example, we have thought about the blacklist before and decided it would not be beneficial. The whole system depends on what is currently in your arp cache. If nothing is there at all then we have nothing to compare against. Kind of first come first serve. So if an attacker wanted to DoS a certain machine they could send replies to the system with arpstar causing it to put the mac addr in a blacklist. But let's say they spoofed the MAC of the legitimate machine. Since we don't have an entry yet in the table the legitimate machine is blacklisted. The attacker can then reply to any request we send and not worry about collisions and ARP poison the other machine for a man-in-the-middle attack. That's one reason we don't use blacklists...but we have thought about it before.

Right now our solution works for the vast majority of arp poisoning attacks while remaining flexible and dynamic. It was important to us that the end user would *typically* not notice anything at all and be protected. So the solution is not perfect but we think it is a vast improvement.

Swi+ch

Aeiri-

Sure. That is a perfectly good impersonation attack, but obviously does not perform ARP poisoning. ARP has serious deficiencies, there's no doubt, but it's not going anywhere soon. It is nice to be able to say that using arpstar will force an attacker to perform some kind of DoS in order to impersonate another machine by ARP poisoning. Then it becomes more of the nearly impossible responsibility to not allow the DoS, since ARP in its current form is lacking authentication completely.
That's not a terrible idea, but has potential to cause problems. Example: how long do you blacklist it? How many should you block? If the answer to either of those questions is known (*which they will be since this is open source) the attacker can circumvent that protection easily. for example: if you were to implement 500 blocked IP/MAC pairs, the attacker simply needs to generate 501 in a short period to get around it. Also, if you were to allow an infinite blacklist, a DoS could be performed similar to a SYN flood attack.

EDIT:
Like Bass said, it has too much potential to create another DoS.

-RockCrusha