A tool/theory to prevent all MiTM attacks for any computer

[ShadowMaster]

So I've been thinking lately about MiTM attacks because of some automation scripts I've looked at, and came to the following conclusion: If automation can help the attackers, it can also help the victims.

The theory:
By comparing the current gateway MAC against a known clean MAC, and by intercepting all broadcasted ARP replies, without using static ARP tables any given victim should still be able prevent all MiTM attacks simply by resetting his arp cache with known clean values.
I don't want the user to be stuck with static arp because 1) That means his computer is not network portable, which would suck for laptops. 2) ICMP blasts can get rid of 'em, so they aren't foolproof anyway.

The practice:
I want a program that'll initially query the arp table, save known clean gateway MAC values for a given network, and compare every x seconds. It'll will have a different profile for every network the user uses.
If the MAC has changed, then alert the user, and either revert to the old MAC, send an arp request based on the old MAC to search for a legit ICMP redirect/host unreachable, or just warn user that the traffic might be unsecure, depending on user input/options. Also, if the standard arpspoof broadcast packet is detected, alert the user and follow the above steps.

The Implementation:
I want this to be an open source utility for any user with a simple gui for non-tech-savvy users. It should also be portable from windows to linux and v/v.

The problems:
I know how to program in .NET with a little c mixed in. I wouldn't even begin to know how to write this program. I'd love to put in the effort but I can't do it alone, and need the community's help.

The needs:
This'll be open source so anyone seeking reimbursement should stay away.
Someone to design modules/functions and say what should go in to each module/function. (ARP cache querying, comparison function, warning function, ARP cache resetting, etc...)
Someone to help write the network API's to search for broadcasted ARP replies, ICMP packets, etc...
Someone to help write system-portable code.
Someone to design a user-friendly GUI.
Someone to decide on profile storage procedures.
-->> Someone to tell me if I've missed something <<--

NOTE: Just because I say "Someone" does not mean that it won't be me doing the work. It just means that if someone if willing to put in the initiative to do it himself, I'd be incredibly appreciative.
I created a project on google here https://code.google.com/p/arp-protector/, but there is nothing currently there.

Please feel free to contact me directly with ideas or offers, if you do not want to reply to this post for whatever reason.

[Scamentology]

Its one thing to spy on a corporate LAN but its another on someones personal connection - Its creepy. Like looking in someones window at night. I am all for development of this for personal use.

taken from the bottom of arp-spoof wikipedia page:
https://en.wikipedia.org/wiki/ARP_spoofing

Some of them are open source.

ArpON: Portable handler daemon for securing ARP against spoofing, cache poisoning or poison routing attacks in static, dynamic and hybrid networks.
Agnitum Outpost Firewall[1]: Reply only accepted if request sent.[2]
AntiARP[3]: Windows-based spoofing prevention in kernel.
Anticap: Kernel patch for Linux 2.2/2.4, FreeBSD 4.6, NetBSD 1.5, prevents mapping being overwritten (no longer available).
Antidote[4]: Linux daemon, monitors mappings, unusually large number of ARP packets.
Arp_Antidote[5]: Linux Kernel Patch for 2.4.18 - 2.4.20, watches mappings, can define action to take when.
Arpalert: Predefined list of allowed MAC addresses, alert if MAC that is not in list.
ArpStar: Linux module for kernel 2.6 and Linksys router, drops invalid packets that violate mapping, option to repoison/heal.
Arpwatch/ArpwatchNG/Winarpwatch: Keep mappings of IP-MAC pairs, report changes via Syslog, Email.
remarp: Remote Arpwatch, SNMP-based monitoring, mapping changes.
Colasoft Capsa: Alert ARP storms, imbalance on ARP request/response.
Prelude IDS: ArpSpoof plugin, basic checks on addresses.
SnoopNetCop: minitors local ARP cache (no longer available).
Snort: Snort preprocessor Arpspoof, performs basic checks on addresses
XArp[6]: Advanced ARP spoofing detection, active probing and passive checks. Two user interfaces: normal view with predefined security levels, pro view with per-interface configuration of detection modules and active validation. Windows and Linux, GUI-based.

I know this is far from what you are looking for but here is a shell script I wrote a million years ago.

#/bin/bash

#  (C)opyright 2010 Scamentology

   subnet="192.168.0.0"              # Subnet to scan - If routers IP is 192.168.0.1 then subnet = 192.168.0.0
interface="wlan0"                    # Interface to scan
time_wait="30"                      # Time to wait in seconds


#__ Nothing Below This Line _______________________________________________________________________

if [ ! "$(which arp-scan)" ] ; then echo "arp-scan needs to be installed to run this program - apt-get install arp-scan" ; exit 1 ; fi

find="$(echo $subnet | cut -c 1-3)"


function scan(){
clients="$(arp-scan -I $interface $subnet/24 | grep -v DUP | grep $find | awk '{ print $2 }')"


for i in $clients;do
   haxor="$(grep $i safe_mac_list)"
   if [  ! $haxor ] ; then
      echo "OMG Theres a haxor on my network $i "$(date)"" >> alert_log
      # Put whatever alert technique you want to use here!!!!!!!!!!!!!
   else
      echo "All is good in the neighborhood "$(date)"" >> alert_log
   fi
done
sleep $time_wait
scan
}
scan

Most security issues are not about a lack of tools - Its about a lack of implementation of an available solution.

Please feel free to contact me directly with ideas or offers, if you do not want to reply to this post for whatever reason.

[ShadowMaster]

So I took a look at your tools, and came out with a few problems. One: they are not really free. Two: many of them require installations on both systems. Also, while your script has a similar idea to what I want to accomplish, it obviously cannot be ported to windows easily. What I want is a free, portsble tool that doesn't require installation on both systems, preferably to be truly portable. Let me know if you or someone you know can help with actual coding, if you're interested.

[Scamentology]

I am right there with you. I posted those tools so there is an idea of how to move forward. Lets develop a tool thats cross platform and open source.

First things first - what language should this be done in. i suggest java for its portability. once that decision is made we can build a working template then move on from there.

I hope you didn't think I was attacking your idea.

also I think Ettercap is written in c ( correct me if I am wrong). It has an arp-cop plugin that could be useful if you chat with the new ettercap devs.

So I took a look at your tools, and came out with a few problems. One: they are not really free. Two: many of them require installations on both systems. Also, while your script has a similar idea to what I want to accomplish, it obviously cannot be ported to windows easily. What I want is a free, portsble tool that doesn't require installation on both systems, preferably to be truly portable. Let me know if you or someone you know can help with actual coding, if you're interested.

[ShadowMaster]

I didn't think you were attacking, I thought you were pointing out that it had already been done. That being said, the information did help me think of stuff I wanted to add, such as not allowing an ARP reply without an ARP request.

I would like java in theory, but the extent of cross-platform portability that I want doesn't require it, and it would be way easier to write in a c variant. Java really is only necessary for serious cross-platform (PC to smartphone) and it's very tedious for what I think should be done here. If you think it's necessary then by all means, let's write it in java. But if it's easier to code in a different language, why complicate things?

By chatting with the ettercap devs, do you mean in the tool request section?

BTW, just by reading the descriptions of the tools in that wikipedia page, we should be able to combine and implement all those on one tool.
Also BTW, I literally just started a PWB course, so my ability to work on this may be a little sporadic.

I'll ask some friends what language they think it should be in, and when you give your final input, we'll decide together, then we'll move on the design phase.

[comaX]

I unfortunately can't contribute code-wise, but I want to be kept updated, and maybe help where I can. So here's my post so I'm subscribed

[ShadowMaster]

@comaX Good to have you aboard. We'll need all the help we can get, and anything you, or anyone, contributes is great. BTW, how's the yamas script going?

@scamentology So I spoke with a few friends and the consensus was perl for multiple reasons. Chief among them was http://www.cpan.org/ and any real objections I had were solved by http://www.perlmonks.org/?node_id=443176. If many modules that we need have already been coded, I am very happy to hop on the bandwagon of others' labor. And if something can make it an .exe, then ease, and true linux to windows portability has been achieved. Two fer one. I like it. What are your thoughts on the mattter? comaX, your thoughts?

So here are the modules/functionability I think we need. Tell me if there should be something more.
1) Read the current ARP cache and store it. (Array should be fine.)
Some assumption as to the current non-poisoned state must be made. For more tech savvy, allow gateway address checking through the browser.
1a) Allow the current state to be saved in a profile.
See step 3.
2) Allow for manual IP, MAC address entry to be appended to the array.
Duh.
3) Detect when an Arp request was sent out, and which address it was sent to.
And if the request was to the gateway in the same profile, warn the user that the MAC has changed if it has, then follow the prevention steps.
4) If an unsolicited reply was recieved, drop it.
DUH!
5) Prevent arp-storming and ICMP blasts.
DUH!
6) If somehow the MAC in the same profile changed, then revert to old.
6a) If ICMP error message are recieved, then send and AR request to the IP and see how many replies are recieved. One mac, all is good. Two MAC's you're in trouble. If two are received, warn the user, and use the old.
7) On detection of a broadcasted ARP reply, Immediately warn the user and drop the packet.
8) Allow to installed as a service. (Windows)
9) On a profile SWITCH, prevent ARP requests from being sent, and instead populate the ARP cache from the stored profile.
10) If one client is sending lots of ARP packets, alert the user/admin.
11) Allow for other alert mechanisms. (Syslog, email...)

I think I've gotten everything, if anyone wants to add more functionality please post.
Everyone ok to move on to the actual function by function design phase? I think gui should come last.

[paparts]

I like the idea. I like to contribute but I'm a PHP fan. I hope there more will help in the development.

[J0hnnyb14z3]

Hey guys, this is a very interesting topic/tool. First off, I'd recommend python for this project. It's capable of running on almost any system, it's network friendly, it's easy to code, and it's pretty damn powerful! Perl would be an option but I bet you'd find a stronger developer base in the python world. Thats just my opinion though... On to the meat and potatoes...

One of the obvious ways to detect arp spoofing is by detecting a large amount of arp traffic from a single node (or multiple nodes). The way tools like arpspoof work is by trying to flood the network with a packet every second or so that states the attacker's desired false arp info. Other devices on the network get this arp update every second and use that info for routing packets. When the real gateway broadcasts its arp info it's drowned out by the noise from the attacker. So, logically if we can identify the source of the noise on the network and block it via packet counting rules, IP/Mac tables, or whatever else and alert the user to the anomaly then we have accomplished a part of the goal.

Using a database of some sorts to keep track of "clean" IP/MAC combos for machines on the network is a great way to start when it comes to prevention. Also, implementing a static routing setup could work but may be over complicated (especially cross platform I have a feeling). But, finding a balance of approaches and attacking the problem from every possible exploitable path would be the key to a robust tool. There may be some limitations here though due to the nature of the arp protocol itself...

One of the things I keep thinking about when looking over the requirements is that they seem to assume that the gateway MAC will change or be a different MAC when an attack is occurring AND the client will see this. Correct me if I'm wrong, but during mitm/proxy attacks can't you modify the packets going back to the client? If you could do this then the destination and src fields could be edited and the client would never know that the packets WEREN'T coming from the gateway (on the way back to the victims machine the src mac is changed to the real gateways mac instead of the attackers, therefore it is not being used for routing and does not cause a DOS). How can we catch this and ensure we are really effectively understanding the topography of the LAN and where the packets are coming from and going too?

Anyway, I'm definitely interested and would consider working on this project as long as it's not reinventing the wheel. (As seen in the post above and based on a google search there are LOTS of IDS's, IPS's, and standard tools already that do something very similar with arp for various platforms) So what can we bring to the table thats new and fresh when it comes to fighting arp attacks? ie What would make this tool stand out and be worth the many hours of coding?

I look forward to hearing more!

Thanks!

[J0hnnyb14z3]

Sorry, accidentally double posted.. mod please delete this..