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^[1]
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^[2]. “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^[3]
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^[4]
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^[5]
sent to the nameservers.

To achieve this, all an attacker had to do was guess the
16-bit^[6]
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 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^[7]
by the same group of researchers in November 2020, relies on
ICMP^[8]
“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^[9], 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.”