Multiple DNS implementations vulnerable to cache poisoning

DNS POISON – FLUSH DNS TODAY

If you haven’t heard about DNS cache poisoning … well now you have!!! If you are running a nameserver, time to flush the DNS irrespective of the operating server – be it linux, mac or Windows – I suggest you do it before it spreads and harms anyone!

You may read more about this from the original post HERE or a republished article below

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.

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 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

Vendor	Status	Date Updated
3com, Inc.	Unknown	10-Jul-2008
Alcatel-Lucent	Vulnerable	14-Aug-2008
Apple Computer, Inc.	Vulnerable	1-Aug-2008
AT&T	Unknown	21-Apr-2008
Avaya, Inc.	Vulnerable	16-Jul-2008
Avici Systems, Inc.	Unknown	21-Apr-2008
Belkin, Inc.	Unknown	13-Jul-2008
Blue Coat Systems	Vulnerable	22-Jul-2008
BlueCat Networks, Inc.	Vulnerable	22-Jul-2008
Check Point Software Technologies	Not Vulnerable	23-Jul-2008
Cisco Systems, Inc.	Vulnerable	10-Jul-2008
Conectiva Inc.	Unknown	5-May-2008
Cray Inc.	Unknown	5-May-2008
D-Link Systems, Inc.	Unknown	2-May-2008
Data Connection, Ltd.	Unknown	21-Apr-2008
Debian GNU/Linux	Vulnerable	9-Jul-2008
djbdns	Not Vulnerable	10-Jul-2008
dnsmasq	Vulnerable	11-Jul-2008
DragonFly BSD Project	Unknown	3-Jul-2008
EMC Corporation	Unknown	21-Apr-2008
Engarde Secure Linux	Unknown	5-May-2008
Ericsson	Unknown	21-Apr-2008
Extreme Networks	Unknown	21-Apr-2008
F5 Networks, Inc.	Vulnerable	14-Jul-2008
Fedora Project	Unknown	5-May-2008
Force10 Networks, Inc.	Not Vulnerable	11-Jul-2008
Foundry Networks, Inc.	Not Vulnerable	10-Jul-2008
FreeBSD, Inc.	Vulnerable	14-Jul-2008
Fujitsu	Vulnerable	18-Jul-2008
Funkwerk Enterprise Communications	Vulnerable	22-Aug-2008
Gentoo Linux	Vulnerable	12-Jul-2008
Gnu ADNS	Unknown	5-May-2008
GNU glibc	Unknown	5-May-2008
Hewlett-Packard Company	Vulnerable	16-Jul-2008
Hitachi	Not Vulnerable	29-Jul-2008
Honeywell	Unknown	21-Apr-2008
IBM Corporation	Vulnerable	12-Jul-2008
IBM Corporation (zseries)	Unknown	5-May-2008
IBM eServer	Unknown	21-Apr-2008
Infoblox	Vulnerable	21-Jul-2008
Ingrian Networks, Inc.	Unknown	5-May-2008
Intel Corporation	Unknown	21-Apr-2008
Internet Systems Consortium	Vulnerable	14-Jul-2008
JH Software	Not Vulnerable	10-Jul-2008
Juniper Networks, Inc.	Vulnerable	10-Jul-2008
Linux Kernel Archives	Unknown	3-Jun-2008
Luminous Networks	Unknown	21-Apr-2008
Mandriva, Inc.	Vulnerable	22-Jul-2008
MaraDNS	Not Vulnerable	10-Jul-2008
Men & Mice	Unknown	5-May-2008
Metasolv Software, Inc.	Unknown	5-May-2008
Microsoft Corporation	Vulnerable	8-Jul-2008
MontaVista Software, Inc.	Unknown	5-May-2008
Motorola, Inc.	Unknown	21-Apr-2008
Multitech, Inc.	Unknown	21-Apr-2008
NEC Corporation	Vulnerable	22-Aug-2008
NetApp	Unknown	3-Jul-2008
NetBSD	Unknown	5-May-2008
Netgear, Inc.	Unknown	21-Apr-2008
Network Appliance, Inc.	Unknown	21-Apr-2008
Nixu	Vulnerable	9-Jul-2008
NLnet Labs	Not Vulnerable	10-Jul-2008
Nokia	Unknown	21-Apr-2008
Nominum	Vulnerable	10-Jul-2008
Nortel Networks, Inc.	Unknown	21-Apr-2008
Novell, Inc.	Vulnerable	14-Jul-2008
OpenBSD	Vulnerable	24-Jul-2008
OpenDNS	Not Vulnerable	10-Jul-2008
Openwall GNU/*/Linux	Vulnerable	17-Jul-2008
PePLink	Not Vulnerable	10-Jul-2008
Posadis project	Unknown	14-Jul-2008
PowerDNS	Not Vulnerable	10-Jul-2008
Process Software	Unknown	8-Aug-2008
QNX, Software Systems, Inc.	Unknown	5-May-2008
Red Hat, Inc.	Vulnerable	10-Jul-2008
Redback Networks, Inc.	Unknown	21-Apr-2008
Secure Computing Network Security Division	Vulnerable	17-Jul-2008
Shadowsupport	Unknown	5-May-2008
Siemens	Unknown	8-Jul-2008
Silicon Graphics, Inc.	Unknown	5-May-2008
Slackware Linux Inc.	Vulnerable	12-Jul-2008
Sony Corporation	Unknown	21-Apr-2008
Sun Microsystems, Inc.	Vulnerable	31-Jul-2008
SUSE Linux	Vulnerable	11-Jul-2008
The SCO Group	Unknown	5-May-2008
Trustix Secure Linux	Unknown	5-May-2008
Turbolinux	Unknown	5-May-2008
Ubuntu	Vulnerable	10-Jul-2008
Wind River Systems, Inc.	Vulnerable	14-Aug-2008
Yamaha Corporation	Vulnerable	29-Jul-2008
ZyXEL	Unknown	21-Apr-2008

References

http://www.kb.cert.org/vuls/id/484649
http://www.kb.cert.org/vuls/id/252735
http://www.kb.cert.org/vuls/id/927905
http://www.kb.cert.org/vuls/id/457875
http://www.cert.org/archive/pdf/dns.pdf
http://csrc.nist.gov/publications/nistpubs/800-81/SP800-81.pdf
http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience
http://tools.ietf.org/html/rfc3833
http://tools.ietf.org/html/rfc2827
http://tools.ietf.org/html/rfc3704
http://tools.ietf.org/html/rfc3013
http://tools.ietf.org/html/rfc4033
http://tools.ietf.org/html/draft-ietf-tsvwg-port-randomization
http://cr.yp.to/djbdns/dns_random.html
http://cr.yp.to/djbdns/dns_transmit.html
http://cr.yp.to/djbdns/forgery.html
http://www.trusteer.com/microsoftdns
http://www.trusteer.com/bind9dns
http://www.trusteer.com/bind8dns
http://www.sans.org/reading_room/whitepapers/dns/1567.php
http://blogs.iss.net/archive/morednsnat.html
https://jvn.jp/cert/JVNVU800113/
http://www.cert.at/static/cert.at-0802-DNS-patchanalysis.pdf

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 on http://www.kb.cert.org