Home > arp_poisoning, Security > arp cache poisoning: it’s for real

arp cache poisoning: it’s for real

Last week I helped one of our clients solve their web server being inserted with iframe problem, which started a few weeks back when they told me that their customers complained accessing to their product order status page resulting in some unexpected pop-up windows. As a result this client’s website is marked unsafe by anti-virus programs such as mcfee. My initial investication showed that accessing the problematic page results in an iframe line being inserted to the top of the page in the html source code:
<iframe src=”h t t p://w w w.h a c k i n g s.c n”></iframe>
(I intentionally add some spaces in the url as I don’t want you to accidentally hit that link going to the hacker’s site.)

A bit more detail about the setup of the webserver:
2) runs behind a Linux firewall accessible through DNAT

My investigation continued and my accessing the same page from the firewall resulted in the same result — the hacking line being inserted. But when I accessed the page from any other workstation including the webserver itself, I didn’t see the line, which led to my wrong conclusion that there must be some virus in the webserver that is smart enough to tell where the traffic is from — when it’s from the gateway, the request is most likely made from the Internet; when it’s from the LAN, it stops inserting the line to fool the web administrator that the web server is fine. My conclusion is not coincident: I also used a Linux laptop to set up a temporary web server providing the exact same urls to replace the original webserver and the hacking line disappeared. I recommended the client to bring down the IIS webserver immediately and replace it with a Linux server. I thought the problem was solved.

A few days later, my client reported that the problem came back, with a Linux server being the web server. My hunting for the real cause of the problem went on and somehow arp cache poisoning got into my head. I heard it a lot before but never seen it in action. To get started I installed and run arpwatch on the firewall and before long I saw a lot of flip-flops scrolling up on the screen (mac addresses change back-and-forth) for a bunch of ip addresses in the client’s LAN. The client doesn’t use dhcp therefore there shouldn’t be flip-flops — At least that tells me that I was on the right direction to solve the problem. From the arpwatch log I saw something like this

Jul 29 13:21:18 linux-gw arpwatch: report: pausing (cdepth 3)
Jul 29 13:21:18 linux-gw arpwatch: flip flop 18:8b:41:72:b1 (0:13:20:3d:5e:53)
Jul 29 13:21:18 linux-gw arpwatch: report: pausing (cdepth 3)
Jul 29 13:21:18 linux-gw arpwatch: changed MAC address 0:50:da:7b:c6:60 (0:13:20:3d:5e:53) 

I could see from the log entries that those flip flop lines share the same pattern — the mac address for a specific ip gets changed to the same mac address 0:13:20:3d:5e:53 then back to its original mac address. At that point I concluded whichever machine that has 0:13:20:3d:5e:53 as the mac address is the one that initializes arp poisoning attack. As the client didn’t have a ip to mac address mapping, the hunting for that machine took a bit while but luckily it was found on one of the workstations. I instructed the client to disconnect that workstation from the LAN and I conducted the test again, the hacking line was gone — either from the Internet or the gateway. What a relief! arpwatch continued to report a lot of flip-flops, but they are just for changing back to their original mac addresses from the poisoned mac address. When arpwatch stopped reporting flip-flops I generated an IP-Mac address map for the client so it will a piece of cake to ID which machine generates arp cache poisoning attack when problem like this happens again.

Categories: arp_poisoning, Security
  1. March 6, 2010 at 1:31 pm

    Does my mac adresse change if I upgrade my computer with some other hardware? For example change the graphic card?

    • ricoch3n
      March 7, 2010 at 2:06 am

      Only networking devices (ethernet adapters, wifi adapters, etc) have mac address. So changing your graphic card won’t change whatever mac address(es) you currently have on your system.

  2. zazuge
    March 23, 2010 at 1:07 pm

    I think the story doesn’t stop her, doesn’t it?
    you didn’t tell us what caused that change ?

    in my case we have a network where the proxy control witch ip can access internet at what hour
    but some greedy people changed their ip to get extra surf time at the expense of legitemate network users
    arwatch helped me track them
    now maybe i’ll use arp acl in my proxy
    and dhcp

    • ricoch3n
      March 25, 2010 at 12:57 am

      The story did stop there as that PC was re-formated right after it’s taken out from the network. I had no way to find out why it got affected (by virus or some sort) in the first place.

      Using mac addresses in your acl definitely provides more effective control as you mentioned that your users are allowed to change their workstation’s IP. Good luck.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: