Compartir a través de

Detecting ARP Spoofing Attacks

  • Artículo

After investigating an ARP spoofing incident recently, I started thinking of how we could easily ferret out this sort of information when responding to a potential incident.

In this particular case, there were two important parts of the attack:

  1. ARP spoofing forced all traffic bound for the default gateway to be funneled through the infected machine, and
  2. HTTP proxying allowed for the injection of malicious code in HTML documents.

ARP spoofing would be easy to detect and/or rule out if you happen to know the MAC address of the default gateway off the top of your head as you could just look at the local ARP cache ("arp -a" at a command prompt) to make sure you had the right one; however, I'd suspect that most people wouldn't have that information easily at hand. 

Another approach that might work is to:

  • Start a network capture.
  • Clear the ARP cache of any entries for the default gateway ("arp -d 192.168.0.1").
  • Initiate a connection to something on the other side of the default gateway ("ping microsoft.com").
  • Stop the capture and look to see if you got more than one ARP response when you ARP'd for the default gateway.

This approach is messy and it makes the assumption that the malware responds to ARP requests rather than just spamming the hosts on the subnet with gratuitous ARPs.   The remaining approach would be to do what we did in this incident -- take a network trace of general network traffic and look for the excessive gratuitous ARPs coming from the infected machine.  (I'd also suspect that most IDS systems would catch this -- if you were feeling lazy, you could probably take the network trace and feed it through Snort in offline mode...)

I had an epiphany about the second part, detection injection of malicious code in HTML docs, while I was having a romantic dinner over the weekend.  Fortunately, my significant other is used to this sort of behavior and she didn't even roll her eyes when I asked if she had a pen and paper so I could write it down...

The epiphany was that the best way to find injected code was to compare a suspicious document with a known-good document.  Of course, the problem is finding a known-good doc to compare to but, with a bit of thought, I came up with an additional insight -- an attacker couldn't inject a payload into a doc downloaded over SSL.  So, I think the following would work nicely:

Unfortunately, the two copies of default.aspx, in this example, will have minor differences but nothing so obvious as an <iframe> pointing somewhere else.

I'm open to other approaches, though, and I'd love to hear from folks who have other ideas.

Comments

  • Anonymous
    January 01, 2003
    I believe there was some malware that was able to use javascript hackery to redirect and proxy HTTPS in a full-screen frame. The average user would not notice it. I believe I saw this demonstrated at BlackHat 06/Vegas and the only way you could tell was either by looking at the page source or noticing the small thin border around the page. So, I'd speculate that it's possible that by utilizing that technique + the ARP spoofing technique that you could redirect through the attackers local malicious proxy. I have not tested this.

  • Anonymous
    July 13, 2007
    Curt: the malware can only take that approach if it's running on the local host and then by hooking into the browser or network stack.  SSL security is end-to-end on the network so nobody anywhere in between can MITM it unless they've got a root-signed cert for the domain in question, or the user ignores a browser warning.   Another way of detecting ARP poisoning using only built in tools or easy to script tests would be to ping all possible hosts on the local subnet (or broadcast address if that works -- I don't recall what conditions that will work with firewalls, different network stacks, etc, so that might not work) and then query the local arp cache to see if the "gateway" shows up for any other IPs on the network.  It's not foolproof as I can think of a couple of ways the attacker could evade detection if he knew about it beforehand, or ways that might cause the router's mac to show up for other addresses, but generally speaking it should work fairly well.  And it's an easy check to implement.  I bet you it would have detected this particular malware fairly, showing the mac of the real machine's IP and the gateway IP as well.

  • Anonymous
    August 01, 2007
    I just noticed something similar on my university's campus network: in my case, it was a reference to a JavaScript file inserted at the top of Web pages. I haven't seen anything about this exploit anywhere else. It's a pretty scary exploit, since fundamentally you are relying on the network administrator to keep the network from being compromised--there's not much you can do if the network itself goes bad.