A Set of Severe Flaws Affect Popular DNSMasq DNS Forwarder

Cybersecurity researchers have uncovered multiple
vulnerabilities in Dnsmasq, a popular open-source software used for
caching Domain Name System (DNS) responses, thereby potentially
allowing an adversary to mount DNS cache poisoning attacks^[1]
and remotely execute malicious code.

The flaws, collectively called “DNSpooq” by Israeli research
firm JSOF, echoes previously disclosed weaknesses in the DNS
architecture, making Dnsmasq servers powerless against a range of
attacks.

“We found that Dnsmasq is vulnerable to DNS cache poisoning
attack by an off-path attacker (i.e., an attacker that does not
observe the communication between the DNS forwarder and the DNS
server),” the researchers noted in a report published^[2]
today.

“Our attack allows for poisoning of multiple domain names at
once, and is a result of several vulnerabilities found. The attack
can be completed successfully under seconds or few minutes, and
have no special requirements. We also found that many instances of
Dnsmasq are misconfigured to listen on the WAN interface, making
the attack possible directly from the Internet.”

Dnsmasq, short for DNS
masquerade^[3], is a lightweight
software for providing local DNS caching, thus reducing the load on
upstream nameservers and improving performance.

As of September 2020, there were about 1 million vulnerable
Dnsmasq instances, JSOF found, with prominent users being Cisco
routers, Android smartphones, Aruba, Technicolor, Redhat, Siemens,
Ubiquiti, and Comcast.

Revisiting Kaminsky Attack and SAD DNS

The concept of DNS cache poisoning is not new.

In 2008, security researcher Dan Kaminsky^[4]
presented his findings of a widespread and critical DNS
vulnerability that allowed attackers to launch cache poisoning
attacks against most nameservers.

It exploited a fundamental design flaw in DNS^[5]
— there can be only 65,536 possible transaction IDs (TXIDs) — to
flood the DNS server with forged responses, which is then cached
and leveraged to route users to fraudulent websites.

The transaction IDs were introduced as a mechanism to thwart the
possibility that an authoritative nameserver could be impersonated
to craft malicious responses. With this new setup, DNS resolvers
attached a 16-bit ID to their requests to the nameservers, which
would then send back a response with the same ID.

But the limitation in transaction IDs meant that whenever a
recursive resolver queries the authoritative nameserver for a given
domain (e.g., www.google.com), an attacker could flood the resolver
with DNS responses for some or all of the 65 thousand or so
possible transaction IDs.

If the malicious answer with the right transaction ID from the
attacker arrives before the response from the authoritative server,
then the DNS cache would be effectively poisoned, returning the
attacker’s chosen IP address instead of the legitimate address for
as long as the DNS response was valid.

The attack banked on the fact that the entire lookup process is
unauthenticated, meaning there is no way to verify the identity of
the authoritative server, and that DNS requests and responses use
UDP (User Datagram Protocol) instead of TCP, thereby making it easy
to spoof the replies.

To counter the problem, a randomized UDP port was used as a
second identifier along with the transaction ID, as opposed to just
using port 53 for DNS lookups and responses, thus raising the
entropy in the order of billions and making it practically
infeasible for attackers to guess the correct combination of the
source port and the transaction ID.

Although the effectiveness of cache poisoning attacks has taken
a hit due to the aforementioned source port randomization (SPR) and
protocols such as DNSSEC^[6]
(Domain Name System Security Extensions), researchers last November
found a “novel” side-channel to defeat the randomization by using
ICMP rate limits as a side-channel to reveal whether a given port
is open or not.

The attacks — named “SAD DNS^[7]” or Side-channel
AttackeD DNS — involves sending a burst of spoofed UDP packets to a
DNS resolver, each sent over a different port, and subsequently
using ICMP^[8]
“Port Unreachable” messages (or lack thereof) as an indicator to
discern if the rate limit has been met and eventually narrow down
the exact source port from which the request originated.

Mount Multi-Staged Attacks That Allow Device Takeover

Interestingly, the DNS cache poisoning attacks detailed by JSOF
bear similarities to SAD DNS in that the three vulnerabilities
(CVE-2020-25684, CVE-2020-25685, and CVE-2020-25686) aim to reduce
the entropy of the Transaction IDs and source port that are
required for a response to be accepted.

Specifically, the researchers noted that despite Dnsmasq’s
support for SPR, it “multiplexes multiple TXIDs on top of one port
and does not link each port to specifics TXIDs,” and that the CRC32
algorithm used for preventing DNS spoofing can be trivially
defeated, leading to a scenario where “the attacker needs to get
any one of the ports right and any one of the TXIDs right.”