DNS Poisoning White Paper | Portland, Oregon computer network security consulting company

The "No Network is 100% Secure" series
- DNS Poisoning -
A White Paper

DNS poisoning - overview: Domain Name Service (DNS) is 411 for computers. If you type in "www.google.com" in your browser, DNS returns the web server IP address and sends you to the Google web site. A poisoned DNS will return a bogus IP address that sends your browser to a compromised website. What is important here is that most users and businesses do not run their own public DNS. They instead rely on the public DNS servers operated by their respective ISPs, which is why this is issue is disturbing and serious.

DNS poisoning is a legacy issue that has plagued lookups since DNS was created. Previously due mostly to administrative sloppiness on the part of those who managed DNS servers, this threat is back with a vengeance today.

The most recent vulnerability was discovered in the Summer of 2008 when a domain-name service server operated by AT&T had been compromised. The attack caused AT&T subscribers to be redirected to a fake Google page that tried to push affiliate advertising sites.

AT&T was one of the many internet service providers reported to be errant in applying patches that fix a devastating DNS flaw. At that time, about 51 per cent of unique name servers tested showed up as vulnerable. Today, that vulnerability is estimated to be closer to 35 percent. Still a substantial number though!

DNS poisoning details: An Internet-connected computer typically uses a DNS server provided by the computer owner's Internet service provider (ISP). This DNS server generally serves the ISP's own customers only and contains DNS information that has been cached by previous users of the server. A poisoning attack on a single ISP DNS server can affect the users serviced directly by the compromised server or indirectly by its downstream server(s) if applicable.

To perform a cache poisoning attack, the attacker exploits a flaw in the DNS software that can cause it to accept incorrect information. If the server does not correctly validate DNS responses to ensure that they have come from an authoritative source, the server will end up caching the incorrect entries locally and serve them to users that make the same request. At this point, the DNS cache is considered to be poisoned. This will continue for as long as the fake entry is cached by the server (entries usually have a time to live -- or TTL -- of a couple of hours) subscriber's browsers or e-mail servers will automatically go to the address provided by the compromised DNS server.

This kind of attack is often categorized as a "pharming" attack and it creates several problems. First, users think they are at a familiar site, but they aren't. Unlike with a "phishing" attack where an alert user can spot a suspicious URL, in this case the URL is legitimate. Remember, the browser resolves the address of the domain automatically so there is no intervention of any kind on the part of the users and, since nothing unusual has happened, they have no reason to be suspicious.

Another problem is that hundreds or even thousands of users can be redirected if an attacker successfully inserts a single fake entry into a caching server. The scale of the problem is amplified by the popularity of the domain being requested. Under these circumstances, even a moderately experienced hacker can cause a lot of trouble, obtaining passwords and other valuable or sensitive information.

As part of the Golden Shield Project, China regularly engages in DNS Poisoning for particular sites or networks which violate the policies under which the project operates.

It is possible to attack e-mail systems in a similar way. Rather than inserting a fake record for a Web server into a DNS caching server, the attacker inserts a fake MX record for a mail server, thereby redirecting corporate e-mail to a server they control.

How the latest iteration of cache poisoning works: Prior to this latest vulnerability, attackers could only exploit a narrow opening of beating legitimate authoritative DNS servers by sending a fake query response, hoping they arrive at the caching server first with the correct query parameter values. These races typically only lasted a fraction of a second, making it difficult for an attacker to succeed.

But the dynamics of the race have been dramatically altered in favor of the attacker with this new vulnerability because a security researcher figured out a way to eliminate the narrow time window. This is accomplished by rapidly firing questions at the caching server that an attacker knows the server will not be able to answer. For instance, an attacker can ask where foobar123.google.com is, knowing a caching server is unlikely to have such an entry. That provokes subsequent questions from the caching server and creates millions of opportunities to send fake answers.

Instead of only one race the attacker can have millions, creating more chances to guess the right values for query parameters and making the attack dangerous. In fact, it was demonstrated that open source DNS servers could be compromised in 10 seconds using this scheme.

Poisoning an entry for foobar123.google.com is not useful since no one will ever request that domain, but this is where the last part of the attack comes into play. In the fake answers the attacker also points the caching server to a fake name-server for the domain the attacker wants to compromise. The caching server stores both of these pieces of information. Since the attacker now controls the name server for the domain, every subsequent query for the domain will be directed to the attacker's server. This means the attacker now controls addressing for all the subdomains for the domain: www.google.com, mail.google.com, etc. This is extraordinarily powerful. Any request for any subdomain can be directed to a server of the attacker's choosing.

To address this latest problem it was decided that the UDP port used for a query should no longer be the default port 53, but rather a port randomly chosen from the entire range of UDP ports (less the reserved ports). UDP source port randomization, or UDP SPR, as it is called, makes it harder for an attacker to guess query parameters since now both the 16-bit query ID and as many as 16 additional bits for the UDP port must be correct, for a total of up to 4 billion combinations.

But many enterprises have their DNS servers situated behind various devices that provide network address translation (NAT). Most NATs de-randomized the UDP ports used by the DNS server, rendering the new fix less effective. IT managers were also not enthusiastic about opening up the full range of UDP ports in their firewalls. To make matters worse, another security researcher demonstrated that it was still possible to poison a DNS server even with the protection afforded by randomization across 64,000 UDP ports.

So now what?: Bottom line is that DNS is still seriously vulnerable to attack and poisoning! Alternative means of securing the DNS are being considered. UDP source port randomization is a useful defense, but a balance needs to be struck between the protection afforded the DNS by UDP SPR and the exposure created by opening a range of ports or degrading firewall performance. Secure modes of operation for DNS servers, such as switching to a TCP connection is another useful defense.

Prevention using today's technology: Many cache poisoning attacks can be prevented by DNS servers being less trusting of the information passed to them by other DNS servers, and ignoring any DNS records passed back which are not directly relevant to the query. For example, recent versions of BIND now contain code that performs these checks. As stated above, source port randomization for DNS requests, combined with the use of cryptographically-secure random numbers for selecting both the source port and the 16-bit nonce, can greatly reduce the probability of successful DNS race attacks.

A secure version of DNS, DNSSEC, uses cryptographic electronic signatures signed with a trusted digital certificate to determine the authenticity of data. DNSSEC can counter cache poisoning attacks, but as of this writing is not widely deployed.

Defense considerations: When attempting to protect yourself against a DNS spoofing attack, you have to consider the different aspects of the attack and where you fit in. For instance, do you want to prevent against your users being returned bogus data? Or are you trying to prevent your domain name from being hijacked? In any DNS spoofing attack there are two victims - the hijacked domain owner, who is losing traffic to his site, and the end user who gets redirected to a phony IP address.

For a domain owner, there is little you can do to protect against someone spoofing your domain name to a vulnerable nameserver. If you are running a webserver, consider using SSL to authenticate yourself to browsers. Eventually DNSSec will allow all domain servers to have cryptographically signed records, but it is not widely implemented at this time. Even detecting such an attack would be difficult, since the hijack would be largely independent of your servers. Be on the lookout for short denial-of-service attacks; they may indicate someone trying to slow your server down temporarily or crash it in order to complete a spoofing attempt.

For the Nameserver Admin, you can upgrade BIND to the latest version in the 9.x series, which are at least less vulnerable to many known attack methods.

Disable recursive queries from the outside world, using split-split DNS if possible. Split-split DNS means you have 2 nameservers; one to serve your public domain information to the outside world, and one to do recursive queries for your users. The public server should not allow recursive queries, and the recursive (caching) server should be protected from the Internet by a firewall. This is sometimes confused with split DNS, where the internal server forwards requests to the outside server which makes recursive queries on its behalf. This arrangement offers no protection against cache poisoning, and should be avoided.

If you cannot use split-split DNS, you should at least try to restrict who can do recursive queries from your nameserver. Using the "allow-recursion" option doesn't give you very much protection - remember, the attacker is already spoofing the source IP address, so it is just a matter of them knowing which addresses are allowed to do recursive queries. If possible, use the "listen-on" option to bind the nameserver daemon to an interface that is protected from the outside world.

Filter traffic at network perimeters. Because the ability to spoof IP addresses is necessary to conduct these attacks, administrators should take care to filter spoofed addresses at the network perimeter. IETF Request for Comments (RFC) documents RFC 2827, RFC 3704, and RFC 3013 describe best current practices (BCPs) for implementing this defense. It is important to understand your network's configuration and service requirements before deciding what changes are appropriate.

If you are an End User urge your ISP/company to upgrade BIND. If they are not open to this, you can always run your own recursive resolver and bypass the ISP's nameservers. Practice safe computing; keep antivirus software updated and signatures current. Always confirm SSL certificates when making secure online transactions. If you suspect a site is being spoofed, you can make use of the ARIN whois records to determine whether an IP address actually belongs to the organization that owns the domain name.

Cautions: BIND 9 currently continues the practice of reusing source ports. This should be corrected, as it would make any new attacks harder to execute.

About the Author

Frank Saxton is a computer network security engineer and Easyrider LAN Pro principle. Home-based in Portland, Oregon, Frank has been designing remote diagnostic and network enterprise monitoring centers since the late 1970s. Prior to becoming a professional systems engineering consultant in 1990, Frank had a 20 year career in computer systems field engineering and field engineering management. Frank has a BSEE from Northeastern University and holds several certifications including Network General's Certified Network Expert (CNX). As a NOC design engineer and architect, Frank works regularly with enterprise-class monitoring tools such as HP Openview Operations, BMC Patrol and others. In his enterprise security audit work, Frank uses sniffers and other professional grade monitoring tools on a daily basis.

Next in the security white paper series:

How Cyber Criminals will mature over the next ten years
Are you vulnerable to drive-by exploits?
High value sites recent hacks
IT employment challenges of the 21st century
Employment reference checking white paper
Competency Certifications White Paper
Firewall White Paper
Virus White Paper
GhostNet White Paper
Password White Paper
Digital Identification Certificates White Paper
Cryptography White Paper
OpenID White Paper
Intrusion Detection Systems IDS White Paper
Rootkit White Paper
Unnecessary Windows XP Services White Paper
Scareware White Paper
Exaflood Internet Brownout White Paper
Cloud Computing White Paper
Proxy Server White Paper
Personal Computer PC Security White Paper
Phishing White Paper
DNS Poisoning White Paper
Conficker White Paper
SPAM White Paper
Best Practices White Paper
Denial of Service DoS White Paper
Trojan Virus Attacks White Paper
Port Scanning White Paper
Monitoring Basics 101 White Paper
Monitoring Basics 102 White Paper
Monitoring Basics 103 White Paper
Virtual Machine Security White Paper
Aurora vulnerability White Paper
Shelfware White Paper
Outsourced IT White Paper

Easyrider LAN Pro Consulting services:

Network Security Audit and PC Tune-up service

- Proxy server installation and configuration
- Enterprise security consultations
- Disaster recovery planning
- Disaster recovery services
- Capacity, migration and upgrade planning
- Build and deploy central syslog server
- Build trouble ticket systems
- Design and build monitoring environments
- Design and build Network Operations Centers (NOC)
- HP Openview, BMC Patrol consulting