This DNS vulnerability may allow an attacker to obtain sensitive information about clients using the DNS server and may redirect Internet traffic from those clients to any server of the attacker's choosing.  These servers may masquerade as legitimate servers and may trick the victim into entering confidential information or downloading malicious software.

Multiple vendor DNS protocol implementations could allow a remote attacker to attempt DNS cache poisoning. The DNS client service fails to provide an adequate amount of entropy when performing DNS queries. An attacker could exploit this vulnerability to poison the DNS cache, which could allow the attacker to obtain sensitive information and redirect Internet traffic to any server of the attacker's choosing.

Even if security patches are applied to DNS servers, the port randomization incorporated by these patches may be ineffective if the DNS resides behind a firewall or router that performs network address translation (NAT) using sequential source ports.

When a host on a computer network selects a source port for a UDP request, it selects a port that is unique for that host. When a one-to-many hiding NAT device receives that request and translates it, it may have to assign a new source port, because the NAT device has to assign unique ports for all of the hosts on the internal network. Few NAT devices on the market randomly select UDP source ports. Therefore, when patched DNS clients and servers are used behind NAT, they may still be vulnerable to attack. The source port entropy introduced by the recent patches is canceled out by the NAT device.

Various vendors have supplied patches to fix the core DNS issue.  See References for details on these patches.

X-Force encourages organizations to ensure the appropriate vendor-supplied patches have been applied. However, if the DNS server is behind a NAT device that does not randomly select source ports, the server may still be vulnerable after patching it.

Some secure NAT devices do exist. Linux boxes running ipchains usually preserve the UDP source port selections made by clients running behind them, which preserves the randomness introduced by the client. An OpenBSD machine running pf will assign a new random UDP port for each transaction.  Unpatched DNS servers behind NAT devices that behave like this may not be vulnerable.

A NAT that selects cryptographically random source ports can help protect a vulnerable application running behind it that selects ports predictably.  Conversely, a NAT that selects ports sequentially breaks the security of applications behind it that depend on random port selection. In short, the recommended mitigation strategy may depend significantly on the NAT in use.

Although several reports have indicated that there are enterprise-class NAT devices that do not randomize ports, no patches were available at the time of this alert's publication.

Since the exploit details of this attack are now public, X-Force encourages customers to attempt to mitigate this threat before vendor updates are available. 

One mitigation technique is to move caching internal DNS servers that are behind NAT into a DMZ where they can be directly assigned a unique Internet IP address. Another possibility is to direct all queries from internal name servers to a temporary forwarding server placed in the DMZ until updates for the NAT device are available. In the later case, it is important that to make sure that recursion is disabled on the internal servers. If not, the internal servers may query directly to servers out on the Internet.