Republished with permission from WatchGuard Technologies, Inc.

WatchGuard


DNS Pharming: Someone's poisoned the water hole!

By Dave Piscitello, President, Core Competence

If you have children, you'll probably recall the pull-string figure Wild West Woody from the Pixar movie, Toy Story. Among the handful of fun phrases Woody would say when you pulled his string were, "There's a snake in my boot!" and "Someone's poisoned the water hole!" If Hasbro were to release a "virtual" Woody today, he'd warn us of a similarly serious threat, DNS cache poisoning. The analogy is simple: in the Wild West, a poisoned well spelled disaster; on the Internet, a poisoned DNS cache is no less a calamity.

A Refresher on Domain Name Resolution

Applications (e.g., browsers and e-mail clients) use local DNS software (a "stub" resolver) to find the IP address that corresponds to a domain name of a resource (e.g., a Web site or mail server). The stub resolver forwards this query to a local name server (NS), which may be run by your organization, or by your ISP. The local name server can refer this request to the authoritative NS for resolution. To find the authoritative NS for any given zone of DNS data, a local NS begins by asking a root (.) server. For example, to resolve http://www.watchguard.com/, a local NS will ask a root server, "What's the IP address for watchguard.com?" The server will reply, "You need to ask the com NS at this IP address." The local NS dutifully asks the com NS, which replies, "You need to ask the watchguard NS at this IP address." A local NS configured in this manner is performing iterative and recursive resolution.

Iterative and recursive name resolution is necessary when you are looking up a domain name for the first time. But why should a name server resolve www.google.com a million times a day? For efficiency, many DNS administrators configure a full-service NS, which provides resolution and will also cache resolved names for quicker response to future queries for this same name record. (Note: Name servers typically limit the lifetime of cached entries to either a local Time To Live, or the Time To Live specified by the authoritative NS of that name record; whichever is smaller. Note also that Windows XP also maintains a local cache. A resource listed below considers this implementation in detail.)

What is DNS Cache Poisoning?

Cache poisoning is an attack where a name server is tricked into adding or modifying cached DNS data with incorrect and malicious data. There are several forms of DNS (cache) poisoning. One attack that is recently causing problems is associated with phishing and is called pharming. The attacker lures a victim into requesting resolution of a name in a zone he controls, e.g., www.example.com, often by using spam e-mail. The victim's local NS queries the attacker's NS (example.com). The attacker's NS responds with the IP address of www.example.com. The attacker generously provides additional name record(s) for other domain names to the reply as well, e.g., www.watchguard.com. This record is the poison: the IP address he associates with www.watchguard.com is one for a host the attacker controls rather than the correct address of 206.253.208.100. With this attack, the attacker hopes the victim uses a caching name server that trusts name records from a non-authoritative source. This lax configuration results in a "poisoned cache." Note that in this example, WatchGuard's authoritative name server is not the target of the attack, and will operated unaffected and unaware of its occurrence.

Once an attacker has poisoned a name record in a cache, anyone who visits that cache and requests a poisoned record can be duped or wronged in many ways. For example:

  • A user can visit a Web site that is a defaced or fraudulent version of the real Web site. Because of the impact to the user and the site operator (the domain name registrant), this attack is both a pharming attack and domain name hijacking.
  • A user may submit account credentials to a bogus mail server or to a malicious but legit-looking Web portal requiring authentication. Or, the user may perform an online transaction and submit credit card or other financial information. Both are forms of identity theft.
  • A user may download infected files or malicious code from a bogus site he has been duped into visiting.

Security experts warn users to examine hyperlinks they encounter in e-mail to make certain the links are not contrived and imposter "look-alike" URLs (see "Foundations: How to Spot Phishing Attacks" and "Anatomy of a Phishing Expedition"). Attackers now use cache poisoning to increase the credibility of phishing and scam attacks. Once a cache is poisoned, the attacker can use the exact domain name of the site or server he's spoofing, and users won't be able to detect bogus URLs as easily.

Securing DNS Cache Servers against poisoning

To see if your local NS is vulnerable to cache poisoning, visit Ketil Froyn's DNS Poisoning page, where you can (safely) check against this vulnerability. For a good education, use a LAN analyzer and trace the DNS queries and responses. If you're uncomfortable doing this yet you administer a DNS server, at least check that your configuration protects against this type of cache poisoning.

If you are running DNS service on Windows NT 4.0, 2000 or 2003 Server OS, first read Microsoft's Description of the DNS Server Secure Cache Against Pollution setting. This Knowledge Base article explains how the DNS Server Registry parameter, SecureResponses, can be used to make your DNS server ignore the "additional" resource records that attackers use. When this parameter is correctly set, your DNS server will only cache resource records received from authoritative servers. By default, SecureResponses is not enabled in Windows NT 4.0 and 2000 DNS server, so you'll have to edit the Registry to add it. Microsoft provides detailed instructions on how to create and enable this parameter in the KBA "How to prevent DNS cache pollution." SecureResponses is enabled by default in Windows 2003 DNS server. Users of BIND should upgrade to the latest version of BIND 9, which enables pollution (poisoning) protection.

As a Web site operator, consider using SSL (HTTPS) rather than basic HTTP access to raise the bar against site hijacking and fraud. Users can verify the identity of your site by examining your server's certificate. Also consider using SSL/TLS or SSH tunnels for e-mail, ftp, and any other service you offer to employees, business partners and customers.

Several sources listed below also explain deployment scenarios that make DNS service more resilient against poisoning as well as other attacks.

Conclusions

DNS cache poisoning attacks such as pharming are not new, but renewed. Variants of this type of attack have existed for nearly a decade. However, broad adoption of Internet services for banking, commerce, and sensitive business transactions makes successful DNS cache poisoning attacks more rewarding for perpetrators today than ever before. If you offer DNS service, you should take measures to protect your users against name server attacks. As is the case with so many security vulnerabilities, a little configuration change can make a big difference -- and ensure your DNS server never gets a "snake in its boot."

Resources

Highly recommended: Gunter Ollman's The Pharming Guide (PDF)

DNS Cache Poisoning: The Next Generation (PDF)

DNS Poisoning Summary from SANS

US-CERT Vulnerability Note VU#109475

Pharming (Wikipedia)

Domain Name Hijacking Report from ICANN (PDF)

About DNS Resolver Cache for Windows XP


      Copyrightę 2005, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.