Image: JSOF
Security experts have disclosed today details about seven vulnerabilities impacting a popular DNS software package that is commonly deployed in networking equipment, such as routers and access points.
The vulnerabilities tracked as DNSpooq, impact Dnsmasq, a DNS forwarding client for *NIX-based operating systems.
Dnsmasq is usually included inside the firmware of various networking devices to provide DNS forwarding capabilities by taking DNS requests made by local users, forwarding the request to an upstream DNS server, and then caching the results once they arrive, making the same results readily available for other clients without needing to make a new DNS query upstream.
While their role seems banal and insignificant, they play a crucial role in accelerating internet speeds by avoiding recursive traffic.
Today, the DNSpooq software has made its way in millions of devices sold worldwide, such as Cisco devices, Android smartphones, and all sorts of networking gear like routers, access points, firewalls, and VPNs from companies like ZTE, Aruba, Redhat, Belden, Ubiquiti, D-Link, Huawei, Linksys, Zyxel, Juniper, Netgear, HPE, IBM, Siemens, Xiaomi, and others.
How DNSpooq works
The DNSpooq vulnerabilities, disclosed today by security experts from JSOF, are dangerous because they can be combined to poison DNS cache entries recorded by Dnsmasq servers.
Poisoning DNS cache records is a big problem for network administrators because it allows attackers to redirect users to clones of legitimate websites.
For example, if a threat actor can abuse a DNSpooq attack to poison DNS cache entries for gmail.com on a company’s Cisco router, they can redirect all that company’s employees to a Gmail phishing page while the browser shows the legitimate gmail.com address in their browsers.
In total, seven DNSpooq vulnerabilities have been disclosed today. Four are buffer overflows in the Dnsmasq code that can lead to remote code execution scenarios, while the other three bugs allow DNS cache poisoning.
DNSpooq are easy to pull off, but noisy attacks
On their own, the danger from each is limited, but researchers argue they can be combined to attack any device with older versions of the Dnsmasq software.
Attacks can be carried out quite easily against Dnsmasq installations directly exposed on the internet, but the JSOF team warns that devices on internal networks are also at risk if attackers relay the attack code via browsers or other (compromised) devices on the same network.
The attacks might sound hard to execute, but in an interview with ZDNet on Monday, Shlomi Oberman, chief executive officer at JSOF, said it was the contrary.
“DNSspooq cache poisoning vulnerabilities are not hard to pull off and are the type of vulnerabilities that, in our opinion, could be easily automated and used by botnets, malvertisers, phisers, and that merry bunch,” Oberman said.
“The main challenge for someone exploiting these vulnerabilities on a large scale is that they are quite noisy so they will probably be noticed by ISPs and other companies with wide visibility to internet traffic,” the JSOF CEO told ZDNet.
Oberman added that the attacks also require sending many DNS packets to a targeted device, which also takes a lot of time, and, in addition, also requires that attackers have access to adequate attack infrastructure.
Nonetheless, these are not prohibitive requirements, and the JSOF exec believes the DNSpooq attack is well in the reach of both cybercrime gangs and nation-state (APT) groups alike.
Patches rolling out everywhere
The easiest way to prevent any of these attacks would be to apply the security updates that will be released later today by the Dnsmasq project.
However, many of these Dnsmasq DNS forwarding clients are included inside the firmware of other products, where end consumers can’t reach in and update just one single library.
Oberman, whose company previously also discovered, disclosed, and helped patch the wide-reaching Ripple20 vulnerabilities, has taken a similar approach this time as well.
The JSOF exec told ZDNet that his company has worked with both the Dnsmasq project author and multiple industry partners to make sure patches were made available to device vendors by today’s public disclosure.
“The disclosure process included forming a task group composed of security and engineering representatives from Cisco, Google, Red-Hat, Pi Hole, CERT/CC, Simon Kelley (Dnsmasq maintainer), and JSOF,” Oberman told us.
“The task force engaged on how to record the vulnerabilities, how to communicate them, and also suggested several different patches. There are now patches available under embargo, both as a new version and as backported patches,” he added.
CERT/CC and ICS-CERT also helped coordinate disclosing the DNSpooq attacks to other vendors not included in the original task force. While some vendors might be late with integrating the patches, most vendors have been notified by now about the seven vulnerabilities and their need to eventually deploy patches to all affected products. A list of affected vendors, products, and patches (if available), are listed on the official DNSpooq website.
End-users have their own countermeasures
But for end consumers, determining which vendor deployed DNSpooq patches will most likely be an impossible feat, even for those with advanced technical skills.
Chasing down CVE identifiers for the seven DNSpooq vulnerabilities in device firmware changelogs is a complex feat even for security professionals and software engineers, let alone the average Joe.
Oberman says that these users can protect themselves against DNSpooq-vulnerable devices on their network through two methods.
“A good workaround would be to use DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT),” Oberman said.
“Another option would be to statically configure a trusted DNS server, like Cloudflare or Google DNS servers, so that DNS requests are not handled by the home router and go directly to the [remote] DNS server.
“Both these options require some technical understanding, but are simple enough for many users to carry out,” Oberman told us.
Source: Networking - zdnet.com
