===================================================================== CERT-Renater Note d'Information No. 2008/VULN277 _____________________________________________________________________ DATE : 09/07/2008 HARDWARE PLATFORM(S) : / OPERATING SYSTEM(S) : Systems running DNS implementations. ====================================================================== http://www.us-cert.gov/current/index.html#dns_implementations_vulnerable_to_cache ______________________________________________________________________ National Cyber Alert System Technical Cyber Security Alert TA08-190B Multiple DNS implementations vulnerable to cache poisoning Original release date: July 08, 2008 Last revised: -- Source: US-CERT Systems Affected Systems implementing: * Caching DNS resolvers * DNS stub resolvers Affected systems include both client and server systems, and any othernetworked systems that include this functionality. Overview Deficiencies in the DNS protocol and common DNS implementations facilitate DNS cache poisoning attacks. Effective attack techniques against these vulnerabilities have been demonstrated. I. Description 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. The general concept has been known for some time, and a number of inherent deficiencies in the DNS protocol and defects in common DNS implementations that facilitate DNS cache poisoning have previously been identified and described in public literature. Examples of these vulnerabilities can be found in Vulnerability Note VU#800113. Recent research into these and other related vulnerabilities has produced extremely effective exploitation methods to achieve cache poisoning. Tools and techniques have been developed that can reliably poison a domain of the attacker's choosing on most current implementations. As a result, the consensus of DNS software implementers is to implement source port randomization in their resolvers as a mitigation. US-CERT is tracking this issue as VU#800113. This reference number corresponds to CVE-2008-1447. II. 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. III. Solution Apply a patch from your vendor Patches have been released by a number of vendors to implement source port randomization in the nameserver. This change significantly reduces the practicality of cache poisoning attacks. Please see the Systems Affected section of Vulnerability Note VU#800113 for additional details for specific vendors. As mentioned above, stub resolvers are also vulnerable to these attacks. Stub resolvers that will issue queries in response to attacker behavior, and may receive packets from an attacker, should be patched. System administrators should be alert for patches to client operating systems that implement port randomization in the stub resolver. Workarounds 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. 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. 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. This should be done 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. 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. IV. References * US-CERT Vulnerability Note VU#800113 - * US-CERT Vulnerability Note VU#484649 - * US-CERT Vulnerability Note VU#252735 - * US-CERT Vulnerability Note VU#927905 - * US-CERT Vulnerability Note VU#457875 - * Internet Draft: Measures for making DNS more resilient against forged answers - * RFC 3833 - * RFC 2827 - * RFC 3704 - * RFC 3013 - * Microsoft Security Bulletin MS08-037 - * Internet Systems Consortium BIND Vulnerabilities - ____________________________________________________________________ US-CERT thanks Dan Kaminsky of IOActive and Paul Vixie of Internet Systems Consortium (ISC) for notifying us about this problem and for helping us to construct this advisory. ____________________________________________________________________ The most recent version of this document can be found at: ____________________________________________________________________ Feedback can be directed to US-CERT Technical Staff. Please send email to with "TA08-190B Feedback VU#800113" in the subject. ____________________________________________________________________ For instructions on subscribing to or unsubscribing from this mailing list, visit . ____________________________________________________________________ Produced 2008 by US-CERT, a government organization. Terms of use: ____________________________________________________________________ Revision History July 8, 2008: Initial release ====================================================================== ========================================================= Les serveurs de référence du CERT-Renater http://www.urec.fr/securite http://www.cru.fr/securite http://www.renater.fr ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 151 bd de l'Hopital | fax : 01-53-94-20-41 + + 75013 Paris | email: certsvp@renater.fr + =========================================================