Researchers have described a new variation of the SAD DNS cache poisoning attack that affects roughly 38% of domain name resolvers, allowing attackers to divert traffic intended for legitimate websites to a server under their control.
According to University of California academics Xin’an Zhou, Keyu Man, and Zhiyun Qian, the exploit allows an off-path attacker to insert a malicious DNS record into a DNS cache. A man-in-the-middle (MITM) attacker can use the SAD DNS exploit to redirect any traffic (initially meant for a specific domain) to his server, allowing eavesdropping and modification of the conversation.
The current vulnerability affects Linux kernels and common DNS software such as BIND, Unbound, and dnsmasq when running on Linux, but not on FreeBSD or Windows.
DNS cache poisoning, also known as DNS spoofing, is a method in which inaccurate data is inserted into a DNS resolver’s cache, causing DNS requests for a trusted domain (e.g., www.example.com) to return an incorrect answer (i.e., IP address) and users to be routed to hostile websites.
Not only is it now straightforward to guess the originating port, but an adversary may also fabricate a response by flooding the resolver with DNS answers for any or all of the 65 thousand or so conceivable transaction IDs attached to DNS lookup requests submitted to the nameservers.
To do so, an attacker just needed to guess the 16-bit identification — which means there can only be 65,536 transaction ID values — that is used to authenticate the nameserver’s validity and confirm that the IP address returned is real. Suppose the negative response with the correct transaction ID comes before the authoritative server’s response. In that case, the DNS cache will be poisoned, returning the attacker’s selected address rather than the exact IP address.
However, because the recursive resolver caches data obtained from authoritative nameservers, if the resolver requests an IP address of a domain name that another client has already requested, it simply returns the requested record from its cache to the client without having to contact the nameservers.
Since then, the attacks have been rendered impractical by increasing the entropy of lookup queries by utilizing the transaction ID in combination with a randomized UDP port as a second identifier instead of the usual port 53. But, recently found leaky side channels have allowed the ephemeral port number to be derandomized, essentially removing the safeguards.
SAD DNS, also known as Side channel AttackeD DNS, uses the ICMP “port unreachable” message to determine which ephemeral port is being used. While ICMP is required for routing diagnostic and error responses in an IP network, the protocol’s rate-limiting feature limits the amount of bandwidth available for inbound ICMP traffic on a port, restricting denial-of-service (DoS) attacks that can occur when an attacker attempts to bombard the network with ICMP messages.
The new side channel method entails the attacker sending many faked UDP probes to the target using the victim’s forged source address, utilizing the technique to narrow down the open ports and estimate the transaction ID, similar to the original Kaminsky attack.
Unlike previous approaches, such as SAD DNS, which use UDP probes to verify whether a UDP port is open or closed, the newly revealed DNS cache poisoning attack directly investigates a side channel while processing ICMP error messages – i.e., ICMP frag required or ICMP redirect packets — which do not elicit a response by purpose — are used as a yardstick to attain the same objective.
The attack’s primary concept is to exploit the global exception cache’s limited number of total slots, a 2048-bucket hash table, to determine if an update has happened after a batch of ICMP probes. The side channel differs from SAD DNS in that it appears while processing incoming ICMP messages (rather than egress packets), and it “levers the space resource limit (i.e., the capacity for storing the next hop exception cache is restricted),” whereas SAD DNS’ side channel “levers the time resource restriction” (i.e., ICMP error generating rate is limited).
To counter the current attack, the researchers offer many mitigations, including randomizing the cache structure, refusing ICMP redirect messages, and enabling the socket option IP PMTUDISC OMIT, which tells the underlying operating system not to receive the ICMP frag required packets, thereby removing side channel processing from the kernel.