Americas

  • United States

Asia

Oceania

lconstantin
CSO Senior Writer

Flaws in widely used dnsmasq software leave millions of Linux-based devices exposed

News Analysis
Jan 19, 20218 mins
SecurityVulnerabilities

A set of seven vulnerabilities, called DNSpooq, allows attackers to redirect users or execute malicious code. Patch dnsmasq now.

padlock / Domain Name System / DNS / ICANN / security
Credit: Alpesh Ambalal Patel / Getty Images

Security researchers have found several serious vulnerabilities in dnsmasq, a utility used in many Linux-based systems, especially routers and other IoT devices, to provide DNS services. Attackers can exploit the flaws to redirect users to rogue websites when trying to access legitimate ones or to execute malicious code on vulnerable devices.

Dnsmasq is a lightweight tool that provides DNS caching, DNS forwarding and DHCP (Dynamic Host Configuration Protocol) services. The utility has been around for around 20 years and is part of the standard set of tools in many Linux distributions, including Android. As a utility that provides network services, dnsmasq is widely used in networking devices such as home business routers but is also present in many other types of embedded and IoT systems including firewalls, VoIP phones and car WiFi systems.

The primary use of dnsmasq is to resolve DNS queries either for the device it’s running on or for other devices on the network, in the case of routers. The software forwards the queries to other DNS servers on the internet or serves the responses from a local cache to speed up the process. It is this caching feature that researchers from Israeli IoT security company JSOF found ways to exploit.

DNS cache poisoning

JSOF found a total of seven vulnerabilities in dnsmasq that they collectively dubbed DNSpooq. Some of these flaws enable so-called DNS cache poisoning attacks, where attackers who can send queries to a vulnerable dnsmasq-based forwarder can force the server to cache rogue or “poisoned” DNS entries for targeted domain names. In practice, this means that when a device or computer that uses the forwarder tries to access a certain domain name, it will receive a malicious response from cache that will direct it to a server under attackers’ control instead of the real one.

DNS cache poisoning came into focus in 2008 when security researcher Dan Kaminsky revealed a vulnerability that impacted the most popular DNS server software. His disclosure triggered what was then described as the world’s largest coordinated vulnerability patching effort and sped up the adoption of DNSSEC, a set of security extensions to the DNS protocol that added cryptographic signing and verification of DNS records. The attack technique did not die off. Just last year, researchers from University of California, Riverside and Tsinghua University revealed a new attack method dubbed SAD DNS that can lead to DNS cache poisoning.

DNS hijacking, the larger group of attacks that DNS cache poisoning is part of, has been used over the years by a variety of malware programs and attacker groups to direct users to fake banking websites. Technically, websites that use HTTPS with HTTP Strict Transport Security (HSTS) should be protected because while attackers can direct users to a different web server by using DNS hijacking, they shouldn’t be able to also spoof the website’s digital certificate, so this should result in a certificate error inside the browser.

However, this mitigation is reliant on how well certificate validation is performed inside the client. Modern browsers have good certificate validation practices, but mobile apps have been known to have broken validation. Also, DNS is not just important for websites and content served over HTTP and displayed in a browser or an app. It’s also used for email and virtually all other protocols that involve contacting a remote server by using a domain name and which might or might not support or implement server identity verification via digital certificates.

Even in a web context, things are not fully mitigated. Instead of spoofing a full website, attackers might use DNS hijacking to replace just one of the external resources loaded by a website, such as a JavaScript file or an advertisement. This can still result in malicious code loaded inside the victim’s browser or app in the context of the targeted website.

Dnsmasq is usually intended for internal networks, but the JSOF researchers found over 1 million devices, including many home routers, that have dnsmasq misconfigured and listening to the internet. Attackers can target these devices directly.

Devices that are configured properly but run a vulnerable instance of dnsmasq can also be targeted if attackers gain access to a different device on the network or even remotely through a local user’s browser. For example, if users visit a compromised website or even a legitimate website that loads a malicious advertisement, attackers can force the users’ browsers to make a series of malicious DNS queries that could result in their local DNS resolver’s cache being poisoned. This was successfully tested with the Safari web browser but fails in Google Chrome.

A successful attack requires making at least 150 DNS queries in rapid succession to poison the cache, which can take between 30 seconds and 5 minutes, JSOF CEO and researcher Shlomi Oberman tells CSO. Chrome happens to limit the number of simultaneous DNS requests to six or eight for performance reasons, so they got lucky in a way because this also blocks the attack, he says.

Devices that run dnsmasq can also be targeted directly if they’re connected to an open network, like those in airports or other public spaces. Many access points, including enterprise ones that are used to set up guest networks, use dnsmasq and are exposed in this way since anyone can connect to those networks and send malicious queries to the DNS resolver.

Remote code execution

Some of the vulnerabilities found by JSOF are buffer overflows and their exploitation can lead to arbitrary code execution. These flaws are in the parsing routines for DNSSEC responses, but before the signature validation. This means the dnsmasq instance will be vulnerable if it’s configured with DNSSEC support, which is recommended for security reasons, but the attacker doesn’t need to send DNS responses that are actually digitally signed with a legitimate signature because the flaws are located before the signature validation step.

In fact, the easiest way to exploit the buffer overflows is to combine them with the cache poisoning vulnerabilities. The attacker can first send queries to poison the cache and the records added in the cache can be used to exploit the buffer overflow to get code execution.

On many embedded devices all processes run with root privileges, so such an attack can result in a full device compromise and can provide attackers with a foothold into the local network that is very hard to detect and remove because IoT devices don’t generally receive the same level of security scanning and monitoring as other systems.

Mitigating the dnsmasq vulnerabilities 

JSOF has worked with the CERT Coordination Center (CERT/CC), ICS-CERT, the dnsmasq developer, Google and other affected parties to coordinate the patching effort and disclosure of these vulnerabilities. The flaws are patched in dnsmasq version 2.83, which will be released Tuesday, January 19, and will be available in the repositories of most Linux distributions.

That said, it’s likely that many devices will remain unpatched for the foreseeable future or indefinitely. Embedded devices tend to run stripped-down versions of Linux with older kernels and userspace tools. Some devices are very slow to receive firmware updates or might already be out of support and will never get patches for these issues. Most home and small business routers still require manual firmware updates and their users rarely update them.

JSOF has identified over 40 affected vendors, some of which make industrial control and enterprise networking gear. The list is likely not complete and includes names like Google, Cisco Systems, Siemens, Huawei, General Electric, Ubiquiti Networks, Aruba Networks, Dell, Netgear, Synology, OpenStack and Linksys.

Some vendors have been more responsive and involved than others and while the ICS and enterprise hardware vendors are likely to issue patches in a timely manner, for many IoT and smaller devices it usually takes much longer, unfortunately, Oberman says. “I think these flaws will linger for months or years for some devices.”

Oberman thinks the attacks we’re likely to see will be those against home routers and other devices that are directly exposed to the internet, because 1 million hijacked devices is quite appealing for any botnet operator even to use just for DDoS attacks. However, these are also the more visible attacks and we’re unlikely to hear if these vulnerabilities are used against organizations in targeted and stealthy attacks.

Oberman recommends that organizations run their local DNS servers where they can do DNS sanitization and prevent not only these attacks, but many others as well. Adding more visibility and monitoring for IoT devices using various solutions available on the market, as well as network segmentation, can also help mitigate the impact of security issues with such devices in general.