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 seven 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 with DNS forwarding capabilities used for locally caching DNS records, 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 the software included in Android smartphones and millions of routers and other networking devices from Cisco, 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."
Dnsmasq versions 2.78 to 2.82 were all found to be affected by the three flaws.
The other four vulnerabilities disclosed by JSOF are heap-based buffer overflows, which can lead to potential remote code execution on the vulnerable device.
"These vulnerabilities, in and of themselves, would have limited risk, but become especially powerful since they can be combined with the cache-poisoning vulnerabilities to produce a potent attack, allowing for remote code execution," the researchers said.
Even worse, these weaknesses can be chained with other network attacks such as SAD DNS and NAT Slipstreaming to mount multi-staged attacks against Dnsmasq resolvers listening on port 53. Even those that are configured to only listen to connections received from within an internal network are at risk if the malicious code gets transmitted via web browsers or other infected devices on the same network.
Besides rendering them susceptible to cache poisoning, the attacks can also permit a bad actor to take control over routers and networking equipment, stage distributed denial-of-service (DDoS) attacks by subverting traffic to a malicious domain, and even prevent users from accessing legitimate sites (reverse DDoS).
The researchers also raised the possibility of a "wormable attack" wherein mobile devices connected to a network that uses an infected Dnsmasq server receives a bad DNS record and is then used to infect a new network upon connecting to it.
Update Dnsmasq to 2.83
It's highly recommended that vendors update their Dnsmasq software to the latest version (2.83 or above) that will be released later today in order to mitigate the risk.
As workarounds, researchers suggest lowering the maximum queries allowed to be forwarded, as well as rely on DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) to connect to the upstream server.
"DNS is an Internet-critical protocol whose security greatly affect[s] the security of Internet users," the researchers concluded. "These issues put networking devices at risk of compromise and affect millions of Internet users, which can suffer from the cache poisoning attack presented.
"This highlight[s] the importance of DNS security in general and the security of DNS forwarders in particular. It also highlights the need to expedite the deployment of DNS security measures such as DNSSEC, DNS transport security, and DNS cookies."
