Vulnerability Note VU#800113

Multiple DNS implementations vulnerable to cache poisoning

Original Release date: 08 Jul 2008 | Last revised: 14 Apr 2014

Overview

Deficiencies in the DNS protocol and common DNS implementations facilitate DNS cache poisoning attacks.

Description

The Domain Name System (DNS) is responsible for translating host names to IP addresses (and vice versa) and is critical for the normal operation of internet-connected systems. DNS cache poisoning (sometimes referred to as cache pollution) is an attack technique that allows an attacker to introduce forged DNS information into the cache of a caching nameserver. DNS cache poisoning is not a new concept; in fact, there are published articles that describe a number of inherent deficiencies in the DNS protocol and defects in common DNS implementations that facilitate DNS cache poisoning. The following are examples of these deficiencies and defects:

  • Insufficient transaction ID space
    The DNS protocol specification includes a transaction ID field of 16 bits. If the specification is correctly implemented and the transaction ID is randomly selected with a strong random number generator, an attacker will require, on average, 32,768 attempts to successfully predict the ID. Some flawed implementations may use a smaller number of bits for this transaction ID, meaning that fewer attempts will be needed. Furthermore, there are known errors with the randomness of transaction IDs that are generated by a number of implementations. Amit Klein researched several affected implementations in 2007. These vulnerabilities are described in the following vulnerability notes:

    • VU#484649 - Microsoft Windows DNS Server vulnerable to cache poisoning
    • VU#252735 - ISC BIND generates cryptographically weak DNS query IDs
    • VU#927905 - BIND version 8 generates cryptographically weak DNS query identifiers
  • Multiple outstanding requests
    Some implementations of DNS services contain a vulnerability in which multiple identical queries for the same resource record (RR) will generate multiple outstanding queries for that RR. This condition leads to the feasibility of a "birthday attack," which significantly raises an attacker's chance of success. This problem was previously described in VU#457875. A number of vendors and implementations have already added mitigations to address this issue.
  • Fixed source port for generating queries
    Some current implementations allocate an arbitrary port at startup (sometimes selected at random) and reuse this source port for all outgoing queries. In some implementations, the source port for outgoing queries is fixed at the traditional assigned DNS server port number, 53/udp.
Recent additional research into these issues and methods of combining them to conduct improved cache poisoning attacks have yielded extremely effective exploitation techniques. Caching DNS resolvers are primarily at risk--both those that are open (a DNS resolver is open if it provides recursive name resolution for clients outside of its administrative domain), and those that are not. These caching resolvers are the most common target for attackers; however, stub resolvers are also at risk.

Because attacks against these vulnerabilities all rely on an attacker's ability to predictably spoof traffic, the implementation of per-query source port randomization in the server presents a practical mitigation against these attacks within the boundaries of the current protocol specification. Randomized source ports can be used to gain approximately 16 additional bits of randomness in the data that an attacker must guess. Although there are technically 65,535 ports, implementers cannot allocate all of them (port numbers <1024 may be reserved, other ports may already be allocated, etc.). However, randomizing the ports that are available adds a significant amount of attack resiliency. It is important to note that without changes to the DNS protocol, such as those that the DNS Security Extensions (DNSSEC) introduce, these mitigations cannot completely prevent cache poisoning. However, if properly implemented, the mitigations reduce an attacker's chances of success by several orders of magnitude and make attacks impractical.

Impact

An attacker with the ability to conduct a successful cache poisoning attack can cause a nameserver's clients to contact the incorrect, and possibly malicious, hosts for particular services. Consequently, web traffic, email, and other important network data can be redirected to systems under the attacker's control.

Solution

Apply a patch from the vendor
A number of vendors have released patches to implement source port randomization in the nameserver. This change significantly reduces the practicality of cache poisoning attacks. Please see the Systems Affected portion of this document for additional details for specific vendors. Additional information about Japanese vendors can be found in JPCERT/CC JVNVU#800113.

Stub resolvers are also vulnerable to these attacks, so system administrators should patch stub resolvers that issue queries in response to attacker behavior and that may receive packets from an attacker. Administrators should watch for patches to client operating systems that implement port randomization in the stub resolver.
Note: Routers, firewalls, proxies, and other gateway devices that perform Network Address Translation (NAT)--more specifically Port Address Translation (PAT)--often rewrite source ports in order to track connection state. When modifying source ports, PAT devices can reduce source port randomness implemented by nameservers and stub resolvers (conversely, a PAT device can also increase randomness). A PAT device can reduce or eliminate improvements gained by patching DNS software to implement source port randomization.

Restrict access

Administrators, particularly those who are unable to apply a patch, can limit exposure to this vulnerability by restricting sources that can ask for recursion. Note that restricting access will still allow attackers with access to authorized hosts to exploit this vulnerability. The document "Securing an Internet Name Server" contains instructions for restricting recursion in ISC BIND.

Filter traffic at network perimeters
Because the ability to spoof IP addresses is necessary to conduct these attacks, administrators should 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.

Run a local DNS cache
In lieu of strong port randomization characteristics in a stub resolver, administrators can protect their systems by using local caching full-service resolvers both on the client systems and on servers that are topologically close (on the network) to the client systems. These resolvers should be used in conjunction with the network segmentation and filtering strategies mentioned above.

Disable recursion
Disable recursion on any nameserver responding to DNS requests made by untrusted systems. "Securing an Internet Name Server" contains instructions for disabling recursion in various versions of ISC's BIND.

The U.S. National Institute of Standards and Technology (NIST) Special Publication 800-81 "Secure Domain Name System (DNS) Deployment Guide" contains detailed and thorough information about the secure deployment of DNS servers, including the recommendations above. Administrators are strongly encouraged to review this document and consider implementing the recommendations it describes.

Implement source port randomization
Vendors that implement DNS software are encouraged to review IETF Internet Draft "Measures for making DNS more resilient against forged answers" for additional information about implementing mitigations in their products. This document is a work in progress and may change prior to its publication as an RFC, if it is approved. System implementers may also wish to review IETF Internet Draft "Port Randomization" for a more generalized approach to how port randomization can mitigate some other types of spoofing attacks.

As noted above, routers, firewalls, and other gateway devices that perform NAT/PAT may modify source ports in ways that reduce the effectiveness of source port randomization.

Systems Affected (Learn More)

VendorStatusDate NotifiedDate Updated
Alcatel-LucentAffected21 Apr 200814 Aug 2008
Apple Computer, Inc.Affected05 May 200808 Oct 2008
Avaya, Inc.Affected21 Apr 200816 Jul 2008
Blue Coat SystemsAffected-21 Nov 2008
BlueCat Networks, Inc.Affected05 May 200822 Jul 2008
Cisco Systems, Inc.Affected01 May 200814 Apr 2014
Debian GNU/LinuxAffected05 May 200809 Jul 2008
dnsmasqAffected09 Jul 200811 Jul 2008
F5 Networks, Inc.Affected21 Apr 200814 Jul 2008
Force10 Networks, Inc.Affected21 Apr 200808 Oct 2008
FreeBSD, Inc.Affected05 May 200814 Jul 2008
FujitsuAffected21 Apr 200818 Jul 2008
Funkwerk Enterprise Communications Affected-22 Aug 2008
Gentoo LinuxAffected06 Jun 200812 Jul 2008
Hewlett-Packard CompanyAffected21 Apr 200816 Jul 2008
If you are a vendor and your product is affected, let us know.View More »

CVSS Metrics (Learn More)

Group Score Vector
Base 0.0 AV:--/AC:--/Au:--/C:--/I:--/A:--
Temporal 0.0 E:Not Defined (ND)/RL:Not Defined (ND)/RC:Not Defined (ND)
Environmental 0.0 CDP:Not Defined (ND)/TD:Not Defined (ND)/CR:Not Defined (ND)/IR:Not Defined (ND)/AR:Not Defined (ND)

References

Credit

Thanks to Dan Kaminsky of IOActive for identifying the effectiveness and practicality of DNS cache poisoning, and to Paul Vixie of Internet Systems Consortium (ISC) for raising the urgency of these issues. Daniel J. Bernstein is credited with the original idea and implementation of randomized source ports in the DNS resolver.

This document was written by Chad R Dougherty.

Other Information

  • CVE IDs: CVE-2008-1447
  • US-CERT Alert: TA08-190B
  • Date Public: 08 Jul 2008
  • Date First Published: 08 Jul 2008
  • Date Last Updated: 14 Apr 2014
  • Severity Metric: 27.54
  • Document Revision: 105

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.