Maybe you heard about the Web attack levied against Metasploit.com last week. The attack made a few waves in news circles, particularly since HD Moore--creator of Metasploit--is well known for his security expertise. In short, the attack allowed someone to create the impression that the Metasploit Web site itself was hacked when in reality no such thing ever occurred.
What did happen was that the site was indirectly attacked using Address Resolution Protocol (ARP) poisoning. For those of you who aren't familiar with such a tactic, ARP poisoning is the processing of spoofing the direct relationship between MAC addresses and IP addresses. So in short, if you can convince a network device to update its ARP tables using data that you provide, then you can control where network packets go on a network--which is how the attacker made it appear that Metasploit.com was hacked. People who tried to visit the Metasploit Web site had their traffic transparently redirected to another site that hosted a Web page with a simple message that said the site was hacked "just for fun."
ARP traffic is broadcast on local subnets and typically does not transmit segments or routers unless ARP traffic is being proxied, in which case it should traverse only select interfaces. What this means in the case of Metasploit.com is that whoever launched the attack most likely had some sort of access to the local network where Metasploit.com is hosted.
When a site comes under ARP poisoning attack sometimes it's not immediately obvious. Because such attacks can redirect traffic it's not very difficult for an attacker to launch man-in-the-middle attacks. An attacker can simply poison the ARP cache, thereby redirecting traffic to their own system, gain access to all traffic passing through their system, and pass that traffic on to its intended destination. That attack would be somewhat difficult to detect, and during the attack all your data would be readily available to the attacker.
In the case of what might appear to be a Web site defacement, an administrator's first impressions might lead him or her to think that someone compromised a server. In the case of a Web site, that line of thinking can lead to a lot of rapid investigation. For example, any number of areas might need to be checked to determine if the site was somehow breached. Web files would be checked for alteration and the Web server platform configuration would also be checked. If no traces were found then one might think that there was unwanted data injected into databases, and then time would be spent digging around to see if anything turned up in any number of databases and tables.
If all that investigation failed to turn up any clues, then it should cross the administrator's mind that maybe someone launched an ARP poisoning attack. If such an attack happens on your own network, then of course you have a decent level of control to investigate further. But what if your services are hosted? In that case you're at the mercy of the hosting company, which can sometimes be a really bad situation, particularly if the company doesn't consider it a top priority to protect innocent site users, as well as the reputations of both the company and its customers.
If you're using hosted services for anything, including Web mail, Web sites, databases, file storage, collaboration, etc., then you'd be well advised to check into the potential security at your hosting providers as well as their potential response to ARP attacks. Better routers and switches have built-in security features that can usually mitigate ARP poisoning. Unfortunately, some hosting companies can't--or don't--expense such equipment or don't realize such features are useful until a problem develops. Another problem is hosting companies' policy and practices: If their equipment proves vulnerable to ARP poisoning, will they employ static ARP entries to stop the attacks, even if only temporarily? You might be surprised to learn that some hosting providers won't do that for you unless you make some really big waves about it.
It's probably a good idea to investigate your hosted services providers, and it's also probably a good idea to figure out whether your in-house network gear can mitigate ARP attacks. Also, you might want to get a copy of the Cain & Abel tool (at the URL below) and give its ARP poisoning features a whirl on your network to see how your gear responds--but be aware that doing so could break your network connectivity if you fail to understand your network topology and the hardware you have in use.
http://www.oxid.it/cain.html
