dns security

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 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 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, 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 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 — 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 (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” 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 “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.”