Tainting DNS Responses

As discussed earlier, DNS requires the cooperation of many unknown or untrusted hosts to function properly. You have to blindly trust that the response received to a DNS query is genuine. Unfortunately, this is not always the case. This section presents a sampling of DNS problems and perversions related to DNS record authentication.

A Weak Link

One of the weaknesses in using host names to allow or deny access to a given service is that if a host can assume a bogus identity of a trusted host, all authentication can be subverted. Think of the types of access allowed based on host name or perhaps on an entire domain name. Do you allow access to an intranet web server for all internal hosts because they are part of your domain? Or, do you use UNIX hosts that allow access without user ID and password authentication based on a trusted host name? That can be very risky behavior if true identities are altered to masquerade as trusted hosts. A host name can be changed on a host itself, on a DNS server that has been compromised and altered until discovered, or on a DNS server temporarily by corrupting a cached DNS record.

Versions of BIND, beginning with BIND 8.3, include DNS Security Extensions (DNSSEC) to provide better authentication mechanisms based on cryptographic signatures to validate the integrity and origin of DNS data. To authenticate a set of responses, a responding DNS server will "sign" them by encrypting a hashed incarnation of the set of responses with the DNS zone's private key. This signature will be returned to the resolver via a new resource record known as SIG. The resolver needs to get the DNS server's public key for the appropriate zone, which is done using another new resource record known as KEY. After it is obtained, the recipient decrypts the signature using the public key to obtain the original hash of the data. The recipient then computes its own hash of the received set of responses, using the same algorithm the DNS server used. It compares the response it receives, and if it matches the decrypted one from the server, it means that the data has not been altered and it is from the professed source.

Cache Poisoning

A Computer Emergency Response Team (CERT) advisory (CA-97.22, issued in August 1997) warns of a vulnerability in versions of BIND.Versions before release 8.1.1 were vulnerable to caching malicious or misleading data from a remote server. A hostile user could use a remote DNS server to put incorrect DNS records in the cache of a victim DNS server.

For this to happen, first, an evil user must force your vulnerable local name server to query the evil user's hacked DNS server. The query is for some innocent piece of information, but the response contains corrupted resource records that your vulnerable DNS server caches.

This "poisoned" data is then returned in any responses for the poisoned record asked of the tainted DNS server. The cache-poisoning techniques are used to corrupt the mapping between host names and IP addresses.

Another of the cache-poisoning exploits is successful because it sends answers with a query record. When any type of DNS traffic is sent, a DNS message is contained in the datagram. The same DNS message format is used for both queries and responses. It appears that some errant versions of BIND cache whatever they find in the response section of the DNS message. They don't check to make sure that the record is a response and not a query. The evil user sends a query to your vulnerable DNS server with poisoned answers in the query, and the DNS server caches these tainted responses.

Figure 6.6 shows an example of how cache poisoning can work. Suppose there is a wicked user who crafts a DNS message with a response in the request. This same user can then send a

query using the source host evil.dns.net and the destination DNS server of ns04.baweb.com, the authoritative name server for www.hillary2000.org.

Figure 6.6. DNS cache poisoning.

This crafted packet has a query for the IP address of www.hillary2000.org, but it includes

an IP address in the response part of the DNS message, which gives the IP address of 206.245.150.74. This is not the real IP address associated with www.hillary2000.org, as

you will soon see.

ns04.baweb.com suffers from the inability to tell query from response, and therefore caches the answer it received in the query. Its cache has just been poisoned with a bogus host name

and IP pairing. Now, to complete the ruse, there must be a DNS server on behalf of a user or process that consults ns04.baweb.com for the IP address for www.hillary2000.org. In

response, the cached answer of 206.245.150.74 is returned.

This is a real-world example in alleged political cyber-warfare. In July 1999, Hillary Clinton launched a web site, www.hillary2000.org, which promoted her to-be-declared run for the

U.S. Senate from New York.

When some users attempted to contact this site, however, they were redirected to a rival site,