Something Old, Something New: DNS Hijacking

Every day, intruders break into and deface Web sites. The methods these crackers use are incredibly numerous. In most cases, someone failed to establish adequate security controls, and an intruder was able to penetrate the network. That assumption might seem obvious, but malicious users can use methods to subvert a normally functioning system without actually penetrating that system's security.

One recent example is RSA Security. Intruders allegedly defaced the company's Web site this past weekend. After reading the initial news reports regarding the defacement, I was slightly startled. After all, RSA Security is a big name in the security industry and should be able to keep its networks reasonably secure. I wondered whether the report was true. Did someone really deface the RSA Security Web site?

As it turns out, the answer is yes and no. To me, a Web site defacement means someone broke into a network, gained access to relevant file systems, and modified the HTML for the site's home page. The alleged defacement of RSA Security's Web site did not follow that scenario. No one broke into RSA Security's network, no one penetrated its security, and no one modified any of its Web server files. No one actually cracked RSA Security's site at all.

If no one defaced the site, what did happen? The answer is very old and very simple: DNS hijacking. At least two forms of DNS hijacking can occur on the Internet. One hijack attack involves spoofing DNS records, and the other method involves taking over InterNIC database records.

From the information available at the time of this writing, it appears that intruders used the former method to spoof, not deface, RSA Security's Web site. I use the word spoof because that's exactly how the attack works: Someone creates a fake Web page and then redirects traffic to that fake page by manipulating various DNS records. When unsuspecting users see the spoofed Web page, they assume an intruder cracked the real Web site. In reality, the site was not cracked at all.

In the case of RSA Security's Web site hijack, someone diverted traffic to a fake Web page after gaining access to an upstream DNS server out of RSA Security's direct control. The intruder accessed the DNS server and temporarily modified its DNS records so those queries destined for RSA Security's Web site would divert to the fake RSA Security Web site. It's that simple. People thought they had landed on the real RSA Security site when, in fact, they simply landed on a spoofed site at another IP address.

If you understand basic DNS architecture, you can understand how this attack could happen to any domain on the Internet. DNS record spoofing is a trivial way to spoof a real Web site crack. And to make matters worse for the hijacked site, the hijacking misleads people into thinking intruders cracked the Web site at Company A, when intruders actually cracked the DNS server at Company B. Company B usually goes unmentioned in the flurry of press reports regarding the attack. If I knew who Company B was in the RSA Security case, I'd report that information to you, but I’ve been unable to obtain that company's name.

The problem with these types of hijacking attacks is that in most cases, administrators control only their DNS records. You can’t defend against this type of Web site attack because you have little, if any, control over upstream DNS records. All you can do is monitor your site using third-party Web page integrity-checker tools and take action the instant you suspect a traffic diversion.

Defending against the second DNS hijack type is easy because of the attack’s nature. In a nutshell, a malicious user can perform this type of DNS hijack by creating fake mail accounts, spoofing valid mail accounts, and flooding the inbox of the technical and administrative contacts listed for a given domain. This attack is successful only if you don't use authentication for your InterNIC records, or if you disregard the flood of email you receive from an intruder that uses this method of attack. In most cases, the flood of email looks like a slew of InterNIC confirmation messages. The attack relies on the hope that less-experienced administrators will mistake these messages for some kind of mail error and simply delete them all instead of examining each one.

To protect your system against this second type of domain hijack, modify your InterNIC domain records so that they require some level of authentication before anyone can make changes.