I like case studies. They’re the real deal in comparison to the theoreticals of many articles. Neil Carpenter recently posted about web-borne malware that eventually led to lan arp poisoning and injection of iframes into web requests. This sort of stuff illustrates the new things we need to start thinking about when it comes to web security. A web attack against one user browser stupid sites stupidly can result in your whole LAN being victimized; the next step in onesy-twosy hijackings from web pages. What is really cool is Neil followed that post up with another one discussing how to detect arp attacks like this.
I had to take exception to his statement that “I’d also suspect that most IDS systems would catch this.” That’s correct, but I don’t know of any IDS systems that would catch those and not throw hundreds of other false positives at the same time. It’s common to intially tune an IDS to not detect ARP.
So what else can you do to provide always-on detection of spoofed arp? You could set up a script to sniff and parse out arp requests relating to your gateways. These should be finite and quite managable. Then whitelist out the combinations for your gateway. If you get different responses, flag and alert. This way you ignore all the other arps since they will likely be false positives anyway, and only alert on what you really care about: the gateway. I bet arpwatch or some other nix arp tools could be leveraged to assist in this.
It is also time to have every company look into some sort of proxy solution for web traffic. Even if it is not robust and does active filtering or stripping of malicious files, it should at least log what is being visited and when. Multiple attempts to site xyz/123.htm accompanying every other hit is a good indicator after-the-fact.
These sorts of blended attacks are nothing new, but it is somewhat new to have such attacks originate from the web browser, attack the network, and end with other web browsers. That’s cool and scary at the same time.