Cricket Liu
VP, Architecture
Infoblox

Recently, the news has featured accounts of widespread attacks against Internet name servers. These attacks have successfully poisoned the caches of many name servers offering recursion, redirecting users of those name servers to malicious web servers. Several makes and models of name servers, including the Microsoft DNS Server and both BIND 4 and BIND 8 name servers have been discovered to be vulnerable to these exploits.

Why should you care about these attacks? The recent attacks have been fairly ham-fisted, after all, redirecting the entire com domain to web servers with bare-bones content. Any moderately cautious user of the Internet would see right through that ruse, right? But imagine a subtler, more sophisticated attack, redirecting users of only a single web site, say a major Internet merchant, to a reasonable facsimile of the real site, or just a "man in the middle" web server that simply captured all traffic from users and relayed it to the real site. Such an attack could quickly ensnare thousands of login names, passwords, credit card numbers, and so on, before anyone noticed.

These attacks work either by returning bogus records with an otherwise legitimate response or by returning an entirely counterfeit response to a targeted name server. I've put together this note to help you examine these variants, and to provide additional resources for protecting your network as these attacks, no doubt, become commonplace.

Potentially Devastating Repercussions
Repercussions of DNS attacks like this that take advantage of security vulnerabilities inherent in conventional DNS systems to hijack an organization's Web presence can compromise all of the people that visit an organization's site and result in identity theft, halted e-commerce and company communications, just to name a few.

For example, a user that is redirected as a result of this attack, could be sent to a seemingly official form requesting personal information and the user could unknowingly provide data to an "untrusted" source, effectively contributing to the theft of their own identity. Understanding how these attacks proliferate and best practices for network identity infrastructure (NII) deployments, can help eliminate these risks for users, partners, employees and customers.

Fortunately, thus far, it appears that the recent attacks have not perpetrated more serious repercussions other than redirecting users to spam web sites or other sites promoting spyware downloads, but the operational and business impact of this alone can translate into significant time and resource costs for businesses.

THAT'S BOGUS
In the first variety of attack, a hacker configures a name server to return unrelated, false records inside an otherwise legitimate DNS response message--or more likely, modifies a name server's code to accomplish this, since name servers normally don't include irrelevant data in a response. These false records are generally placed in a section of the DNS message meant to carry "additional" records related to an answer, such as A records that correspond to mail exchangers that a querier requests. If the name server that receives this response doesn't check that all of the records in the response are actually related in some way to the question it originally asked, it will cache the fake records and return them in response to successive queries.

This variety of attack is actually remarkably old. This is the same kind of attack Eugene Kashpureff used to poison the caches of hundreds of Internet name servers back in July, 1997. The poisoning induced them to direct users accessing www.internic.net to an entirely different web site. Perhaps even more remarkable is the fact that Steve Bellovin warned of this vulnerability in DNS nearly ten years prior to that, in a paper written in 1989!

BIND 4 and BIND 8 name servers were patched almost immediately (in July of 1997, that is) to protect them against this type of attack. The Microsoft DNS Server, however, is still vulnerable--in its default configuration, at least. Incredibly, while the Microsoft DNS Server includes a mechanism to guard against such attacks, the mechanism is off by default. D'oh!

BIND 4 name servers from 4.9.5 on and BIND 8 name servers from 8.1.2 on are resistant to this type of attack (but keep reading, because they're vulnerable to a similar attack). All BIND 9 name servers are resistant to this attack. Microsoft DNS Servers must have the Secure Cache Against Corruption box checked in the name server's configuration.

Unfortunately, when used as forwarders, BIND 4 and 8 name servers are also vulnerable to this attack. When processing a forwarded query, a BIND 4 or 8 name server simply relays the answer back to the querying name server without inspecting the message. This behavior is so integral to the architecture of BIND 4 and 8 name servers that the ISC can't fix it without an overhaul of the code. Consequently, anyone using BIND-based forwarders should upgrade to BIND 9.

COUNTERFEIT CACHE
The second variety of cache poisoning attack involves peppering a targeted name server with entirely made-up responses. In this case, there's no need for the finesse of using the additional data section: A hacker can simply answer with the DNS equivalent of a bald-faced lie, telling a querier that www.amazon.com, for example, maps to the address of a web server under his control.

Now, to make this work, the hacker needs to satisfy a few requirements: He must answer a query the targeted name server currently has outstanding (in other words, if the name server isn't working on resolving the address of www.amazon.com, it won't accept a response answering that question). He must answer the query before any legitimate response arrives. He also must guess the 16-bit message ID the targeted name server is using for the query. All of these, unfortunately, sound harder than they are.

Satisfying the first condition is easy. Here are just a few options: If the targeted name server accepts recursive queries, the hacker can try just querying it directly for the domain name he wants to spoof. If it doesn't accept recursive queries, he can try sending a non-recursive query for the domain name he wants to spoof. If it's cached--and assuming it's a popular site he wants to spoof, it probably is--he can note the remaining time to live on the cached record and wait for the record to time out of the cache. Chances are a user will cause a lookup of the site's domain name shortly thereafter.

If the name server doesn't accept queries from a random source address, he can try spoofing a query from a source address on the name server's local network, or on a network assigned to the company that owns the name server. If none of that works, send mail to someone who uses the name server, with an HTML body that includes a link to an image on the site you're trying to spoof.

Answering the query before a legitimate response arrives could be tricky, but if the hacker is serious about the attack, he can mount a denial of service attack against the real authoritative name servers serving the domain name he's trying to spoof. Or he can just continuously bombard the targeted name server with spoofed responses. Sooner or later, he'll beat the real answer.

Finally, matching the outstanding message ID is surprisingly easy. First, it turns out that many name servers use message IDs that aren't nearly as random as they should be. Second, BIND 4 and 8 name servers start name resolution each time they receive a query for a domain name--even if they're already working on resolving that domain name. That means that now there are more valid message IDs that a hacker can guess when trying to spoof that domain name. Together, these factors can make spoofing a name server a straightforward affair.

The BIND 9 name server, thankfully, addresses both of these issues. It uses significantly more random message IDs and doesn't start name resolution for each received query, making it much harder to mount a successful attack.

CONCLUSION
I hope this article gives you a better understanding of the recent cache poisoning attacks and of how to guard against them. For many, implementing that protection will require upgrading to BIND 9 name servers. Just remember that the Infoblox DNSone is one of the simplest, most secure and cost-effective ways to deploy BIND 9 name servers on your network.

I have also put together a library of materials to assist you in examining and hardening your own DNS architecture at http://www.infoblox.com/dns-resources. I hope you find them useful! If Infoblox can be of further assistance as you examine your DNS architecture, please contact us at info@infoblox.com or at +1.408.716.4300 x2.

Sincerely,

Cricket Liu
VP, Architecture
Infoblox