- January 20, 2021
- Posted by: administrator
- Category: Threat News
Israel-based security consultancy firm JSOF disclosed today seven Dnsmasq vulnerabilities, collectively known as DNSpooq, that can be exploited to launch DNS cache poisoning, remote code execution, and denial-of-service attacks against millions of affected devices.
Dnsmasq is a popular and open-source Domain Name System (DNS) forwarding software regularly used that adds DNS caching and Dynamic Host Configuration Protocol (DHCP) server capabilities to Internet-of-Things (IoT) and various other embedded devices.
The full number or the name of all companies that use Dnsmasq versions vulnerable to DNSpooq attacks on their devices is not yet known.
However, JSOF highlighted a list of 40 vendors in their advisory, including Android/Google, Comcast, Cisco, Redhat, Netgear, Qualcomm, Linksys, Netgear, IBM, D-Link, Dell, Huawei, and Ubiquiti.
Behind the DNSpooq vulnerabilities
Three of the DNSpooq vulnerabilities (tracked as CVE-2020-25686, CVE-2020-25684, CVE-2020-25685) allow for both DNS cache poisoning attacks (also known as DNS spoofing).
DNS Cache Poisoning is an attack method that allows threat actors to replace legitimate DNS records on a device with ones of their choosing.
Using this attack, threat actors can redirect users to malicious servers under their control, while to the visitors it appears as if they are visiting the legitimate site.
This allows the attackers to perform phishing attacks, credential theft, or to distribute malware from what is perceived as a trusted company.
The first DNS spoofing attack was disclosed by security researcher Dan Kaminsky in 2008 when he showed that DNS software can be exploited to steal data and impersonate any website name.
“Traffic that might be subverted includes regular Internet browsing as well as other types of traffic, such as emails, SSH, remote desktop, RDP video and voice calls, software updates, and so on,” JSOF’s report explains.
The rest of them are buffer overflow vulnerabilities tracked as CVE-2020-25687, CVE-2020-25683, CVE-2020-25682, and CVE-2020-25681 that could let attackers remotely execute arbitrary code on vulnerable networking equipment when Dnsmasq is configured to use DNSSEC.
Over 1 million vulnerable devices exposed
Attacks exploiting the DNSpooq security bugs are quite easy to carry out and do not require any unusual techniques or tools.
“The attack can be completed successfully in seconds or a few minutes, and has no special requirements,” JSOF’s technical whitepaper says [PDF].
“We also found that many instances of dnsmasq are misconfigured to listen on the WAN interface, making the attack possible directly from the Internet.”
More than 1 million Dnsmasq servers are currently exposed on the Internet according to Shodan and over 630,000 according to BinaryEdge, with millions of other routers, VPNs, smartphones, tablets, infotainment systems, modems, access points, drones, and similar equipment not accessible over Internet also vulnerable to attacks.
“Some of the DNSpooq vulnerabilities allow for DNS cache poisoning and one of the DNSpooq vulnerabilities could permit a potential Remote Code execution that could allow a takeover of many brands of home routers and other networking equipment, with millions of devices affected, and over a million instances directly exposed to the Internet,” JSOF said.
To fully mitigate attacks attempting to exploit DNSpooq flaws, JSOF advises updating the Dnsmasq software to the latest version (2.83 or later).
JSOF also shares a list of (partial) workarounds for those who cannot immediately update Dnsmasq:
- Configure dnsmasq not to listen on WAN interfaces if unnecessary in your environment.
- Reduce the maximum queries allowed to be forwarded with the option–dns-forward-max=. The default is 150, but it could be lowered.
- Temporarily disable DNSSEC validation option until you get a patch.
- Use protocols that provide transport security for DNS (such as DoT or DoH). This will mitigate Dnspooq but may have other security and privacy implications. Consider your own setup, security goals, and risks before doing this.
- Reducing the maximum size of EDNS messages will likely mitigate some of the vulnerabilities. This, however, has not been tested and is against the recommendation of the relevant RFC5625.
NOTE:: This article is copyright by bleepingcomputer.com and we are using it for educational or Information purpose only