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.
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.
That’s a valid point and you’ve definitely got me dead-to-rights on it. A whitelisting approach for gateways would be a good start although, ultimately, that wouldn’t detect all ARP spoofing attacks, particularly not if the attacker was aiming for information disclosure. (I could still spoof a client’s MAC address to the default gateway and intercept all of that client’s inbound traffic…in fact, I could probably still inject HTML into your HTTP responses that way. Hmmmm…)
It seems as though the best _solution_ would be implemented at the switch level; however, to be honest, I’m not sure what sort of switch config would mitigate it. Of course, there are also a lot of people out there with unmanaged switches.
Cisco DAI (Dynamic Arp Inspection) combined with port-security (1 static + 1 dynamic) would prevent this attack. As would tunneling everything in SSH, SSL, SSL VPN, OpenVPN, IPSec, etc.
I somehow feel that prevention is better than detection for this specific attack path.
It would be interesting to provide a view into what people are doing (i.e. Squid logs), however – people do a lot over HTTP and SSL. I’m not sure that I know of a solution that scales, but http://whitetrash.sf.net looks like an interesting way to prevent some web-based attacks to/from the clientside without having to view into all of the traffic.
Probably the best way to detect these kind of clientside malware attacks would be to use honeyclients (client based honeypots), or web crawlers such as Heritrix from the crawler.archive.org project. I suggest you check out the new book my Holz and Provos, “Virtual Honeypots: From Botnet Detection to Intrusion Prevention” for more information on honeyclients. McAfee’s SiteAdvisor is also an interesting product for detection of clientside malware from a global perspective.
Jose Nazario and others have been working on a way to de-obfuscate Javascript malware, but this is a difficult problem. Probably the best way to do this is in the browser (e.g. Web Developer Toolbar -> View Generated Source). There are also add-ons (NoScript Anti-XSS features, FireKeeper, etc) which can directly help with this kind of analysis by matching on signatures. External tools such as PHP-IDS and friends can also help in this area of research.
And what with XSS Proxy Tunneling announced on RSnake’s blog today – things could get really interesting… imagine running Nessus, Foundstone, and WebInspect inside corporate networks through an in-browser backdoor. That should put Qualys out of business!
@Neil: “I could still spoof a client’s MAC address to the default gateway and intercept all of that client’s inbound traffic…in fact, I could probably still inject HTML into your HTTP responses that way.”
Yup, you’re right! No need to arp spoof one direction when you can just do the other one. My protecting of the gateway may just force you to be noisier if you want to inject against more systems.
@dre: I was talking to a coworker about the XSS tunnels the other day, and I just read that paper last night. That’s pretty crazy. I also feel that something big is going to come out and take all of this browser-as-a-proxy the last few steps to full worm/attack scale. It’s just too golden to be able to hop the perimeter.
Yeah, scaling up ARP protection is difficult.
Honeypots are another long-term project of mine that I’d like to do with a spare box or two. I see too much value in them, both on the LAN and on the Internet, to let them go too long without learning more. Book is now on my list!
Yeah, scaling up ARP protection is difficult.
No, I meant scaling the ability to look into every GET and POST HTTP method coming into and out of your network and get anything meaningful for security out of it.
The ARP protection stuff is – as I said – well handled by Cisco DAI with a basic port-security configuration. You’ll also need to enable spanning-tree guards, DHCP snooping, and other protections – but try running http://yersinia.net or Ettercap against a Cisco network protected fully by DAI. Cost to implement is about 5 change control requests with one resource working for about 8 hours in total assuming you can script your Cisco switch configurations (and if you already have change control, then why not?). Compare to NAC.