New Side Channel Attacks Re-Enable Serious DNS Cache Poisoning Attacks

Researchers have demonstrated yet another variant of the SAD DNS cache poisoning attack that leaves about 38% of the domain name resolvers vulnerable, enabling attackers to redirect traffic originally destined to legitimate websites to a server under their control.

"The attack allows an off-path attacker to inject a malicious DNS record into a DNS cache," University of California researchers Keyu Man, Xin'an Zhou, and Zhiyun Qian said. "SAD DNS attack allows an attacker to redirect any traffic (originally destined to a specific domain) to his own server and then become a man-in-the-middle (MITM) attacker, allowing eavesdropping and tampering of the communication."

The latest flaw affects Linux kernels as well as popular DNS software, including BIND, Unbound, and dnsmasq running on top of Linux, but not when run on other operating systems FreeBSD or Windows.

From Kaminsky Attack to SAD DNS

DNS cache poisoning, also called DNS spoofing, is a technique in which corrupt data is introduced into a DNS resolver's cache, so that DNS queries return an incorrect response (i.e., IP address) for a trusted domain (e.g., www.example.com) and users are directed to malicious websites. Originally discovered by researcher Dan Kaminsky in 2008, the attack stemmed from the fact that recursive resolvers typically used a single open port (usually 53) to send and receive messages to authoritative nameservers.

This not only made guessing the source port trivial, an adversary can forge a response by flooding the resolver with DNS responses for some or all of the 65 thousand or so possible transaction IDs that are attached to the DNS lookup requests sent to the nameservers.

To achieve this, all an attacker had to do was guess the 16-bit identifier — i.e., meaning there can be only 65,536 transaction ID values — which is used to verify the authenticity of the nameserver and prove that the IP address returned is legitimate. Thus in the event the malicious answer with the right transaction ID arrives before the response from the authoritative server, then the DNS cache would be poisoned, returning the attacker's chosen address instead of the legitimate IP address.

But since the recursive resolver caches information received from authoritative nameservers, this also signifies that if the resolver receives a request for an IP address of a domain name that was recently requested by another client, it just replies back to the client the requested record from its cache without having to communicate with the nameservers.

Since then, the attacks have been rendered unfeasible by increasing the entropy by using the transaction ID along with a randomized UDP port as a second identifier instead of using the default port 53 for lookup queries. However, newly discovered leaky side channels have made it possible to derandomize the ephemeral port number, effectively undoing the protections.

SAD DNS aka Side channel AttackeD DNS, disclosed by the same group of researchers in November 2020, relies on ICMP "port unreachable" message as a means to infer which ephemeral port is used. While ICMP is necessary for routing diagnostic and error responses in an IP network, the protocol's rate-limiting feature provides a mechanism for restricting the amount of bandwidth that may be used for inbound ICMP traffic on a port with the goal of preventing denial-of-service (DoS) attacks that can arise when an attacker tries overload the network with ICMP messages.

The novel side channel attack involves the attacker sending a number of spoofed UDP probes containing the victim's forged source address to the target that's large enough to trigger the rate-limiting, using the technique to narrow down the open ports and guess the transaction ID, like it's in the case of the original Kaminsky attack.

"Specifically, if a guessed port number (in a spoofed UDP probe) happens to match the correct ephemeral port, the resolver will not generate an ICMP message (otherwise it would)," the researchers said. "This results in either a stationary limit counter or a decrement of the counter. An attacker can then check whether the counter has been drained by attempting to solicit ICMP responses with a UDP probe from his real/non-spoofed IP."

A previously overlooked attack surface

While prior methods, counting SAD DNS, employ UDP probes to determine whether a UDP port is open or closed, the newly discovered DNS cache poisoning attack directly explores a side channel during the process of handling ICMP error messages — i.e., ICMP frag needed or ICMP redirect packets — that by design do not elicit a response, using it as a yardstick to achieve the same goal.

"An attacker does not necessarily have to rely on the explicit feedback from an ICMP probe," the researchers noted. "Instead, even if the processing of ICMP probes is completely silent, as long as there is some shared resource whose state is influenced, we may find ways (other probes) to observe the changed state of the shared resource."

The central idea of the attack is to use the limited number of total slots in the global exception cache, a 2048-bucket hash table, to discern if an update has occurred following a batch of ICMP probes. The side channel is also different from SAD DNS in that it arises when processing incoming ICMP messages (as opposed to egress packets) and it "leverages the space resource limit (i.e., the space for storing the next hop exception cache is limited) while SAD DNS' side channel leverages the time resource limit (i.e., ICMP error generating rate is limited)."

The researchers propose a number of mitigations to prevent the latest attack, such as randomizing the caching structure, rejecting ICMP redirect messages, and setting the socket option IP_PMTUDISC_OMIT, which instructs the underlying operating system not to accept the ICMP frag needed messages and therefore completely eliminates the side channel related processing in the kernel.

"DNS is one of the fundamental and ancient protocols on the Internet that supports many network applications and services," the researchers said. "Unfortunately, DNS was designed without security in mind and is subject to a variety of serious attacks, one of which is the well-known DNS cache poisoning attack. Over the decades of evolution, it has proven extraordinarily challenging to retrofit strong security features into it."