Multiple DNS Implementations Cache Poisoning Vulnerabilities

Last Update Date: 28 Jan 2011 Release Date: 9 Jul 2008 5687 Views

RISK: Medium Risk

Deficiencies in the DNS protocol and common DNS implementations facilitate DNS cache poisoning attacks. 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. 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.
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.
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.

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.

Exploits to the vulnerabilities have been pubished on the Internet. The risk of exposure is escalated.

HKCERT has issued an advisory on 31-July-2008

Impact

Spoofing

System / Technologies affected

Microsoft Windows 2000 Server DNS
Microsoft Windows Server 2003 DNS
Microsoft Windows Server 2008 DNS
BIND 9.3
BIND 9.4
BIND 9.5
Cisco IOS Software
Cisco Network Registrar
Cisco Application and Content Networking System
Cisco Global Site Selector Used in Combination with Cisco Network Registrar
Juniper Firewalls with ScreenOS
Juniper J-Series Routers with JUNOS built prior to May 23, 2008
Juniper switching products with JUNOS buitl prior to May 23, 2008
Solaris 8 BIND 8.2.4 and prior
Solaris 9 BIND 8.3.3 and prior
Solaris 10 BIND 9.3.4-P1 and prior
Nominum versions prior to 3.0.4.0
Vantio versions prior to 3.3.1.0

Solutions

How to find out if the DNS server you use is vulnerable?

THREE

DNS Checker (http://www.doxpara.com/?p=1185):
it can check your DNS server for randomness of source port and query ID. If randomness is sufficient the test is passed.
DNSStuff Test Tool (http://www.dnsstuff.com):
it can check your DNS server for it can check your DNS server for randomness of source port and query ID with clear graph.
DNS-OARC Test (reference: https://www.dns-oarc.net/oarc/services/porttest): it is a universal test to verify any DNS server by its IP address. It uses existing domain querying command line tools to query a TXT record of "porttest.dns-oarc.net".

	[Linux]	dig @IP-of-DNS-SERVER +short porttest.dns-oarc.net TXT

	[Windows]	nslookup -type=txt -timeout=30 porttest.dns-oarc.net IP-of-DNS-SERVER

The result is GREAT, GOOD or POOR, relying on the standard deviation of the observed source ports.

Immediate action - Apply a patch from your vendor

Before installation of the software, please visit the software manufacturer web-site for more details.
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. 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. Please see the Systems Affected section for additional details for specific vendors. System administrators should watch for patches to client operating systems that implement port randomization in the stub resolver.
Remarks: 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. A PAT device can reduce or eliminate improvements gained by patching DNS software to implement source port randomization. This can be resolved if we can force random source port at the network gateway like to workaround below.
Contact the owner of DNS server to patch
If your accessed DNS server is not under your control, contact the owner and inform them of the issue.
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.

Workarounds

If you cannot patch the DNS server, or the DNS server is not under your control, there are workarounds to mitigate the risks

Force random source port of DNS at network gateway
If the network gateway is using iptables, we can introduce additional randomness into source port via a NAT operation (see the - random option and SNAT target) regardless of the DNS software used behind the firewall/router/proxy. This applies to both locally generated or forwarded packets. Please refer to "Mitigating DNS Cache Poisoning Attacks with iptables" for details.
Disable Recursion, or restrict DNS recursion request from external party
Administrators can configure the DNS server to disable recursion request, or to accept recursive request only from whitelisted subnets
Disable glue-fetching
Administrators can configure the DNS server to disable glue-fetching explicating to protect from cache poisoning
Filter spoofed 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
Separate the name server for providing authoritative responses for their zones (public advertising) and that for providing recursive name resolution services to their internal systems (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.
Use a DNS server without the vulnerability
If you cannot patch the DNS server, or the DNS server is not under your control, you can inform the owner of the DNS server to patch. You can also switch to a different DNS provider which is not vulnerable, such as OpenDNS (http://www.opendns.com), which provides two DNS servers' IP addresses. OpenDNS employs anycast to diversify their traffic so it should be capable of taking up more requests from various geographical locations. However, you are advised to verify the performance of DNS replies when configuring your DNS servers to use OpenDNS.

Vulnerability Identifier

CVE-2008-1447

Multiple DNS Implementations Cache Poisoning Vulnerabilities

Impact

System / Technologies affected

Solutions

Vulnerability Identifier

Source

Related Link