VULHUB ™

 # DNSpooq - Kaminsky attack is back! ### 7 new vulnerabilities are being disclosed in common DNS software dnsmasq,reminiscent of 2008 weaknesses in Internet DNS Architecture ## Overview- DNSpooq ### Vulnerabilities threaten DNS integrity (again) The JSOF research labs are reporting 7 vulnerabilities found in _dnsmasq_ , an open-source DNS forwarding software in common use. Dnsmasq is very popular, and we have identified approximately 40 vendors whom we believe use dnsmasq in their products, as well as major Linux distributions. The DNS protocol has a history of vulnerabilities dating back to the famous 2008 Kaminsky attack. Nevertheless, a large part of the Internet still relies on DNS as a source of integrity, in the same way it has for over a decade, and is therefore exposed to attacks that can endanger the integrity of parts of the web. ### DNSpooq The Dnspooq vulnerabilities include DNS cache poisoning vulnerabilities as well...

 # DNSpooq - Kaminsky attack is back! ### 7 new vulnerabilities are being disclosed in common DNS software dnsmasq,reminiscent of 2008 weaknesses in Internet DNS Architecture ## Overview- DNSpooq ### Vulnerabilities threaten DNS integrity (again) The JSOF research labs are reporting 7 vulnerabilities found in _dnsmasq_ , an open-source DNS forwarding software in common use. Dnsmasq is very popular, and we have identified approximately 40 vendors whom we believe use dnsmasq in their products, as well as major Linux distributions. The DNS protocol has a history of vulnerabilities dating back to the famous 2008 Kaminsky attack. Nevertheless, a large part of the Internet still relies on DNS as a source of integrity, in the same way it has for over a decade, and is therefore exposed to attacks that can endanger the integrity of parts of the web. ### DNSpooq The Dnspooq vulnerabilities include DNS cache poisoning vulnerabilities as well as a potential Remote code execution and others. The list of devices using dnsmasq is long and varied. According to our internet-based research, prominent users of dnsmasq seem to include Cisco routers, Android phones, Aruba devices, Technicolor, and Red-Hat, as well as Siemens, Ubiquiti networks, Comcast, and others listed below. Depending on how they use dnsmasq, devices may be more or less affected, or not affected at all. The origin of the name DNSpooq is a merge of 3 elements: DNS spoofing, the idea of a spook spying on Internet traffic, and the 'q' at the end of dnsmasq, replacing the 'k' of spook with a 'q'. The spy or spook graphic illustrates the effects of an effective DNS spoofing on the ability to spy on internet traffic. The JSOF-pink glasses show how looking through tainted glasses, or a compromised middleman may alter your perception of the reality. DNSpooq demonstrates that DNS implementations are still insecure, even today, 13 years after the last major attack was described. Given the vulnerabilities in DNS over the years, you would think that the security-enhancement mechanisms that have been developed in response, would be ubiquitous by now. However, in reality, DNSSEC is still not very widely deployed, and neither is HSTS. For example, according to research from 2017, adoption of HSTS among the 1M most popular websites [was only at about 5%](https://www.cs.umd.edu/sites/default/files/scholarly_papers/Petrov%2C%20Ivan_1801.pdf)). According to some rough estimates performed by JSOF with the help of large Internet companies, and matching external sources, around [15-20% of Internet traffic](https://www.fortinet.com/blog/industry-trends/keeping-up-with- performance-demands-of-encrypted-web-traffic) is still completely unencrypted, and users still click through to insecure websites. Credit and Appreciation ## DNSpooq disclosure was made possible through coordination of many different participants. Special appreciation for their efforts must be expressed to: * Help with disclosure coordination and fix efforts: * Vijay Sarvepalli ( _[CERT Coordination Center [Cert/CC] )](https://www.kb.cert.org/vuls/)_ * Disclosure coordination and vulnerability communication: * Eugenio Iavarone, Francesco Casotto, and Xavier ([Cisco](https://www.cisco.com/c/en/us/index.html)) * Francis Perron and Mihai Maruseac ([Google](https://www.google.com/)) * Petr Menšik, Riccardo Schirone and Clifford Perry ([Red Hat](https://www.redhat.com/en)) * Dr. Dominic (DL6ER), Dan Schaper ([Pi Hole](https://pi-hole.net/)) * Help with patch development: * Dan Schaper and Dr. Dominic (DL6ER) from [Pi-hole](https://pi-hole.net/) * Petr Menšik from [Red Hat](https://www.redhat.com/en) * ICS-CERT coordination: Daniel Larson ([ICS-CERT](https://us-cert.cisa.gov/ics)) * Patch creation and vulnerability responsiveness: Simon Kelley * PR and communications: Zachary Weiner * Proofreading: Ariel Schon from JSOF * Publication and disclosure communication: Sari Heyman from JSOF * Research: Moshe Kol and Shlomi Oberman from JSOF ### History In 2008, well-known security researcher Dan Kaminsky found and disclosed a fundamental flaw in the Internet naming scheme that affected the most common DNS software and the integrity of the way the Internet worked at the time. Kaminsky proved that attackers can impersonate any website name and steal data. (This has since become known as the "Kaminsky Attack"). DNS has been considered a somewhat insecure protocol for decades, ever since the Kaminsky disclosure and even before that, though it is assumed to guarantee a certain level of integrity. This is the reason it is still heavily relied upon. At the same time, mechanisms have been developed to improve the security of the original DNS protocol. These mechanisms include HTTPS, HSTS, DNSSEC, and other initiatives. Browsers also try to increase users awareness by alerting them before accessing insecure sites with messages such as ["Your Connection is Not Private"](https://www.pandasecurity.com/en/mediacenter/panda-security/your- connection-is-not-private/).  Nevertheless, even with all these mechanisms in place, a DNS hijack is still a dangerous attack in 2021. A large part of the Internet still relies on DNS in a similar manner as in 2008, and is exposed to attacks of the same types.  ## ## Impact The DNSpooq vulnerability set divides into 2 types of vulnerabilities: 1. **DNS cache poisoning attacks** , similar to the Kaminsky attack, but different in some aspects. 2. **Buffer overflow vulnerabilities** that could lead to remote code execution. **(1)** **DNS Cache Poisoning:** The impact of DNS cache poisoning of the routing equipment DNS forwarding server can potentially lead to different kinds of fraud if users believe they are browsing to one website but are actually routed to another. 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. Some of these protocols have built- in measures to mitigate this type of attack, with varying degrees of effectiveness and so YMMV (Your mileage may vary). ### **DNS Cache Poisoning**  **(2) Device take over:** In addition to cache poisoning, every device on which an attacker can perform DNS cache poisoning can also potentially be taken over by the attacker. For example, in the case of a router, the attacker would then have complete control over all traffic going in and out of the network. There are additional impacts possible for these types of attacks. **_These are hypotheticals_** , since to our knowledge they have never been performed by a malicious actor in this way, but they are a definite possibility if the vulnerabilities are exploited correctly. Even so, given the hypothetical nature of the situation, it is hard to analyze how likely they are to actually occur and what value they could bring to different malicious actors. These possibilities include: **(A) Massive DDOS** : Diversion of a large amount of web-traffic to an attacker-controlled website could be used to generate massive JavaScript- fueled Distributed Denial of Service attacks. Simplistic calculations show that the size of the attack could be on the same order of magnitude as the biggest DDOS attacks performed to date. **Massive DDOS  ** **(B) Reverse DDOS** : Prevention of certain users from accessing a website and logging of access attempts to a domain. ### Reverse DDOS ** ** **(C)** " **Semi-** ** **Wormable** " **attacks**** : In situations where a mobile device moves between networks, the attack may be semi-wormable. It is not wormable in the traditional sense, since there are some pre-conditions and efforts needed on the attacker side for the exploit replication, but is semi- wormable in the sense that the exploit can continue to spread between vulnerable devices without explicit user interaction and without need for additional attacker access. In this scenario, a mobile device that was previously browsing in a network which uses an infected dnsmasq server receives a bad DNS record. When the device reaches a new network, it could infect the new network as well. ###### Last paragraph's wording has been edited for clarity following peer feedback. ### Wormable Attacks ** ** ## Technical Overview **Below are high-level technical details of the Vulnerabilities. For in depth information, please refer to our [technical whitepaper](https://www.jsof- tech.com/dnspooq-technical-wp/).** ## Terminology DNS: DNS (Domain Name System) is an addressing system used in order to reach a domain. A name such as '[www.example.com](http://www.example.com/)' would be mapped to an IP address. The DNS protocol is based on _queries _asking where an address is located and _responses _containing an IP address. This is a basic feature of the Internet and is used by almost all computer software. Dnsmasq: Dnsmasq is a popular software used for caching of DNS responses. Storing the responses to previously asked DNS queries locally speeds up the DNS resolution process. The software is installed on many home and commercial routers and servers in many organizations. Dnsmasq is used heavily by networking equipment, as well as being set up manually by IT personnel, usually in smaller networks. There are other uses of dnsmasq, such as providing DNS services to support Wi-Fi hot-spots, enterprise guest networks, virtualization, ad blocking, implementing a captive portal - the login screen that appears when logging in to a network in an airport or other public location and other use cases. The DNSpooq vulnerability set divides into 2 types of vulnerabilities: 1. **DNS cache poisoning attacks** , similar to the Kaminsky attack, but different in some aspects. 2. **Buffer overflow vulnerabilities** that could lead to remote code execution. ### Cache Poisoning Vulnerabilities This type of attack allows subverting of DNS queries in an organization or device using dnsmasq. Essentially, this means that an attacker will be able to reroute communications made by a specific target that relies on a website name such as [www.example.com](http://www.example.com). These vulnerabilities are similar to the _SAD DNS_ attacks reported recently by researchers at UC Riverside and Tsinghua University. SAD DNS also affect dnsmasq and other prevalent DNS software. The SAD DNS and DNSpooq vulnerabilities can also be combined to make attacks even easier. Additional attacks with unclear implications were also reported by a joint effort of universities ([Poison Over Troubled Forwarders](https://www.usenix.org/conference/usenixsecurity20/presentation/zheng#:~:text=Conference%20Policies-,Poison%20Over%20Troubled%20Forwarders%3A%20A%20Cache%20Poisoning%20Attack%20Targeting%20DNS,American%2C%20and%20African%20Diaspora%20Inclusion.) and others). The DNSpooq cache poisoning vulnerabilities are labeled: **CVE-2020-25686, CVE-2020-25684, CVE-2020-25685** The vulnerabilities work by reducing the entropy of the TXID and source port. They should be randomized and provide 32 bits of entropy, however, due to the use of a weak hash to identify the DNS requests and a loose matching of request to response, the entropy can be greatly reduced and only ~19 bits need to be guessed, making cache poisoning very feasible. The way that dnsmasq treats CNAME records further allows to spoof a chain of CNAME records and effectively poison 9 DNS records at the same time. To execute the attack a suitable setup must be set in place by the attacker, which is not difficult to perform. For the cache poisoning, devices that do not use the cache feature of Dnsmasq will be much less affected (but not completely immune). For more detailed technical information, refer to the [technical whitepaper](https://www.jsof-tech.com/dnspooq-technical-wp/). ### Buffer Overflow Vulnerabilities The 4 buffer overflow vulnerabilities that are a part of DNSpooq have a different effect. The worst of these vulnerabilities could lead to a remote code execution on the vulnerable device. These vulnerabilities, in and of themselves, would pose only limited risk. But they become especially powerful since they can be combined with the cache-poisoning vulnerabilities to produce a more potent attack. These vulnerabilities are labeled: **CVE-2020-25687, CVE-2020-25683, CVE-2020-25682, CVE-2020-25681** The buffer overflow vulnerabilities include a high severity heap-based buffer overflow vulnerability that could potentially lead to remote code execution when dnsmasq is configured to use DNSSEC. The vulnerability resides in the early stages of DNSSEC validation, rendering DNSSEC's defense against DNS attacks ineffective. We have not attempted full exploitation of this vulnerability. Other vulnerabilities we found are heap-based buffer overflows that can only lead to denial-of-service when DNSSEC is used. For the Buffer Overflows and Remote Code execution, devices that don't use the DNSSEC feature will be immune. DNSSEC is a security feature meant to prevent cache poisoning attacks and so we would not recommend turning it off, but rather updating to the newest version of dnsmasq. For more detailed technical information, refer to the [technical whitepaper](https://www.jsof-tech.com/dnspooq-technical-wp/). ### A combination with Impact One of the interesting things about these vulnerabilities is that each one of them, on its own, has limited impact. However, the vulnerabilities could be combined and chained in certain ways to build extremely effective multi-staged attacks. This is because exploiting some of the vulnerabilities makes it easier to exploit others. For example, we found that combining CVE-2020-25682, CVE-2020-25684, and CVE-2020-25686 would result in CVE-2020-25682 having a lower attack complexity (with the same impact) and result in a combined CVSS of 9.8 according to our analysis (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H ). Combining the vulnerabilities found by JSOF with other recently-disclosed network attacks could potentially lead to much easier and more widespread attack possibilities, an area of research which can be explored further. This includes vulnerabilities such as [NAT- slipstreaming](https://samy.pl/slipstream/), found by Samy Kamkar, [SAD DNS](https://www.saddns.net/), found by researchers at University of California Riverside, and the lack of destination-side source address validation as found by [researchers at Brigham Young University](https://support.cpanel.net/hc/en- us/articles/360055856934-Destination-Side-Source-Address-Validation-Reports- from-BYU), as well as other academic research on DNS. ### Vulnerabilities List | **Name** | **CVSS** | **Description** | | ------------------ | -------- | ------------------------------------------------------------ | | **CVE-2020-25681** | 8.1 | Dnsmasq versions before 2.83are susceptible to a heap-based buffer overflow in sort_rrset() when DNSSEC is used. This can allow a remote attacker to write arbitrary data into target device's memory that can lead to memory corruption and other unexpected behaviors on the target device. | | **CVE-2020-25682** | 8.1 | Dnsmasq versions before 2.83 are susceptible to buffer overflow in extract_name() function due to missing length check, when DNSSEC is enabled. This can allow a remote attacker to cause memory corruption on the target device. | | **CVE-2020-25683** | 5.9 | Dnsmasq versions before 2.83 are susceptible to aheap-based buffer overflow when DNSSEC is enabled. A remote attacker, who cancreate valid DNS replies, could use this flaw to cause an overflow in a heap-allocated memory. This flaw is caused by the lack of length checks inrfc1035.c:extract_name(), which could be abused to make the code executememcpy() with a negative size in get_rdata() and cause a crash in dnsmasq,resulting in a Denial of Service. | | **CVE-2020-25687** | 5.9 | Dnsmasq versions before 2.83are vulnerable to a heap-based buffer overflow with large memcpy in sort_rrset() when DNSSEC is enabled. A remote attacker, who can create valid DNS replies, could use this flaw to cause an overflow in a heap-allocated memory. This flaw is caused by the lack of length checks in rfc1035.c:extract_name(), which could be abused to make the code execute memcpy() with a negative size in sort_rrset() and cause a crash in dnsmasq, resulting in a Denial of Service. | | **CVE-2020-25684** | 4 | A lack of proper address/port check implemented in dnsmasq versions < 2.83 reply_query function makes it easier to forge replies to an off-path attacker. | | **CVE-2020-25685** | 4 | A lack of query resource name (RRNAME) checks implemented in dnsmasq's versions before 2.83 reply_query function allows remote attackers to spoof DNS traffic that can lead to DNS cache poisoning. | | **CVE-2020-25686** | 4 | Multiple DNS query requests for the same resource name (RRNAME) by dnsmasq versions before 2.83 allows for remote attackers to spoof DNS traffic, using a birthday attack (RFC 5452), that can lead to DNS cache poisoning. | ## Vendors Some of the bigger users of dnsmasq to our understanding and according to our internet research are Android/Google, Comcast, Cisco, Redhat, netgear, and Ubiquiti. There are many more. Different vendors use it for different purposes. Some vendor configurations may not be vulnerable. The following table provides examples of over 40 companies and respective products we believe are using dnsmasq, together with the relevant sources that led us to this understanding. | **User** | **Product** | **Product** | **Sources** | | ------------------------------------------------------------ | -------------------------------------------------- | ----------------- | ------------------------------------------------------------ | | **A10 networks** | Ex series | | https://support.a10networks.com/support/security_advisory/ex-series-cve-2017-13704-cve-2017-14491/ | | **Aruba** | ArubaOS | Aruba instantON | https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2017-005.txt | | **Asus** | Asuswrt | | https://www.snbforums.com/threads/dnsmasq-on-asuswrt-merlin.41046/ | | **AT&T** | arris,motorola, modems | NVG589 | https://www.networkworld.com/article/2452987/pingplotter-and-atandts-flaky-dns-servers.html https://forums.att.com/conversations/att-internet-equipment/dnsmasq-bad-name-at-varetchostsdyn/5defe203bad5f2f606158a31 | | **Audiocodes** | | | http://www.thekelleys.org.uk/dnsmasq/CHANGELOG http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2009q2/003042.html | | **Belden** | OWL 3G/LTE | | https://www.belden.com/hubfs/support/security/bulletins/Belden_Security_Bulletin_BSECV-2020-04_1v0.pdf?hsLang=en | | **Buffalo Networks (Not Vulnerable)** | dd-wrt routers | | https://www.buffalotech.com/products/airstation-highpower-n300-open-source-dd-wrt-wireless-router | | **Cisco ([Vulnerable](https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-dnsmasq-dns-2021-c5mrdf3g#vp))** | Meraki APs | RV Series Routers | https://quickview.cloudapps.cisco.com/quickview/bug/CSCvq54631https://quickview.cloudapps.cisco.com/quickview/bug/CSCvd11905 | | **Comcast** | | | https://joshuakugler.com/an-interview-with-simon-kelley-the-author-of-dnsmasq.html | | **Crosscontrol** | crosslink ai | | [https://support.crosscontrol.com/sites/default/files/documentation/Communication%20Modules/CrossLink%20AI/Manuals/CrossLink%20AI%20-%20Quick%20Start%20Guide%20CrossControl.pdf](https://support.crosscontrol.com/sites/default/files/documentation/Communication Modules/CrossLink AI/Manuals/CrossLink AI - Quick Start Guide CrossControl.pdf) | | **D-Link** | | | https://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10077 | | **Dell** | vxrail | | https://davidring.ie/2020/08/27/vxrail-flush-dns-cache/ | | **Digi international (Vulnerable)** | WR Routers | | https://www.digi.com/resources/documentation/digidocs/PDFs/90002282.pdf | | **General Electric** | MDSorbit | | https://www.gegridsolutions.com/communications/catalog/mdsorbit.htm | | **Google** | Android | | https://en.wikipedia.org/wiki/Dnsmasq | | **Grandstream** | (GWN7602, GWN7610, GWN7000) | | http://www.grandstream.com/sites/default/files/Resources/GWN7602_usermanual.pdf | | **Hirschmann** | | | http://www.doc.hirschmann.com/pdf/UM_Config_BAT-C2_01000_0419_en_2019-04-03.pdf | | **HPE** | Bluedata/EPIC controller | | https://support.hpe.com/hpesc/public/docDisplay?docId=bdp20190930001132en_us&docLocale=en_US | | **Huawei** | Honor V9 play | | https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20171103-01-dnsmasq-en | | **IBM** | IBM Cloud Private-CE container (Community Edition) | | https://hub.docker.com/r/ibmcom/k8s-dns-dnsmasq-nanny-ppc64le | | **Intellidesign** | | | https://blog.trendmicro.com/trendlabs-security-intelligence/dnsmasq-reality-check-remediation-practices/ | | **Juniper (Vulnerable)** | contrais | | https://www.juniper.net/documentation/en_US/contrail19/topics/concept/ha-cluster-manage-fabric.html | | **Linksys** | routers | | https://community.linksys.com/t5/Wireless-Routers/EA9500-v1-vulnerable-to-dnsmasq-vulnerability/td-p/1289347 | | **Motorola** | m2 | NVG589 | https://forums.att.com/conversations/att-internet-equipment/how-to-change-the-dns-server-on-the-motorola-nvg589-router/5defc72dbad5f2f6063137f9 | | **Netgear [(Vulnerable)](https://kb.netgear.com/000062628/Security-Advisory-for-Multiple-Dnsmasq-Vulnerabilities-on-Some-Routers-PSV-2020-0463)** | R7800, WNDR3800, RBR20, others | Orbi | https://community.netgear.com/t5/Orbi/DNS-Forwarding-and-dnsmasq-on-RBR20/td-p/1694521 | | **Openstack** | | | https://ask.openstack.org/en/question/117787/dnsmasq-as-dns-proxy/ | | **Parrot** | drone | | http://secuinside.com/archive/2014/2014-2-5.pdfhttps://www.linkedin.com/in/hugoycharles/?locale=en_US | | **Peplink** | suf series routers | | https://forum.peplink.com/t/peplink-security-advisory-dnsmasq-cve-2017-14491-14496-cve-2017-13704/12677 | | **Qualcomm** | multiple products | | https://nvd.nist.gov/vuln/detail/CVE-2018-13897 | | **Raspberry** | pi-hole | | https://docs.pi-hole.net/main/origins/ https://docs.pi-hole.net/ftldns/dns-resolver/ | | **Red Lion** **Controls** | sixnet series | others | [https://www.redlion.net/sites/default/files/1328//Upgrade_Guide_with_Release_Notes_3.28_4.28.pdf](https://www.redlion.net/sites/default/files/1328/Upgrade_Guide_with_Release_Notes_3.28_4.28.pdf) | | **Redhat [(Vulnerable)](https://access.redhat.com/security/vulnerabilities/RHSB-2021-001)** | codeready containers | | https://access.redhat.com/documentation/en-us/red_hat_codeready_containers/1.0/html/getting_started_guide/troubleshooting-codeready-containers_gsg | | **Ruckus** | access points | | https://www.kb.cert.org/vuls/id/973527 https://www.ruckuswireless.com/security/1/view/txt | | **Siemens [(Vulnerable)](https://cert-portal.siemens.com/productcert/pdf/ssa-646763.pdf)** | scalance | | https://ics-cert.kaspersky.com/news/2017/12/05/dnsmasq/ | | **Synology [(Vulnerable)](https://www.synology.com/en-global/security/advisory/Synology_SA_21_01)** | nas | | https://community.synology.com/enu/forum/2/post/124897https://community.synology.com/enu/forum/17/post/106357?reply=355093 | | **Technicolor (Vulnerable)** | Routers/modems | TG799vac | https://www.kb.cert.org/vuls/id/973527https://www.shodan.io/host/122.175.44.218 | | **Teltonika** | rut95x | other routers | https://community.teltonika-networks.com/4942/does-the-rut955-support-dns | | **Tesla (Low Risk) ** | Infotainment | | https://blog.lookout.com/hacking-a-tesla | | **Ubiquiti Networks** | Edgerouter | other | https://help.ui.com/hc/en-us/articles/115002673188-EdgeRouter-DHCP-Server-Using-Dnsmasq | | **Virtual Access** | | | https://virtualaccess.com/wp-content/uploads/2017/03/GW2028UserManual.pdf | | **Volkswagen/ Harman** | Infotainment | | https://www.computest.nl/documents/9/The_Connected_Car._Research_Rapport_Computest_april_2018.pdf | | **Xiaomi** | 3g | k20pro | https://www.reddit.com/r/Mi9T/comments/hr3262/what_is_dnsmasq_k20_pro/https://www.usenix.org/system/files/sec20-zheng.pdf | | **ZTE** | Mobilephones | | http://download.ztedevice.com/device/global/support/opensource/mobilephones/open_source_notice.html | | **Zyxel** | | | https://www.kb.cert.org/vuls/id/973527 | ## Attack Scenarios There are several possible attack scenarios, depending on the device configuration. These include: * **Open forwarders:** For the approximately 1 million dnsmasq servers openly visible on the Internet (according to [Shodan](https://www.shodan.io/search?query=dnsmasq)), attacks through the Internet are very simple. This may be possible in some cases, (we believe rare), even if the forwarder is not open to the Internet. * **Closed network with internal attacker:** If a dnsmasq server is only configured to listen to connections received from within an internal network, and an attacker gains a foothold on any device in the network, the attacker would be able to perform the attack. * **Browser-based attack:** This variation of the attack is more complex to pull off but _is much more dangerous_ , since the attack can be performed with only a basic level of access. Even if a dnsmasq server is closed off to the outside world, and is only configured to listen to connection received from within an internal network, if attackers are able to get a device within the network to browse to their website, they could perform the attack this way. This includes cases where only a part of the website is crafted by the attacker, such as if the attacker were able to display crafted ads in a victim's browser through an ad network. This version of the attack is more complex, may take some time, may have lower success rates, and will not work on every browser. For example, this method has been tested and shown to work on an iPhone with built-in Safari, working on a single device. It did not work in Chrome running on Windows. We have not completed extensive tests, but believe that Chrome is probably immune. Chromium-base browsers and Microsoft browsers were not tested. * **Open Wi-Fi or wired network:** If a dnsmasq server is only configured to listen to connections received from within an internal network but the network is open, such as an airport network or a corporate guest network, an attacker will be able to perform the attack. ## Disclosure The story of **DNSpooq** begins in the summer of 2020, when we began researching dnsmasq vulnerabilities. We identified some vulnerabilities and moved forward to reproduce them under different configurations. Once we validated the vulnerabilities, we kicked off a coordinated vulnerability disclosure (CVD) process. Given how dependent the Internet is on DNS technology, and how widespread dnsmasq, is we certainly believe the situation is of high importance to home users and enterprises. The disclosure started on August 2020 and the Embargo ended on January 2021, marking approximately 5 months in total of Coordination of the vulnerabilities. With the help of CERT/CC and volunteers from several companies, a working group was formed, combining the expertise and extended reach of members from JSOF, CERT/CC, Cisco, Google, Red Hat, Pi-hole, and Simon Kelley, the maintainer of dnsmasq, to ensure that the DNSpooq vulnerabilities would be effectively fixed and well documented and communicated. Since we are coordinated DNSpooq through CERT/CC, we do not have direct visibility into what the various vendors will decide to do, in terms of integrating patches and fixes to their customers. Generally, we believe the major OS distributors and vendors will issue patches simultaneously, and the other vendors publish updates soon afterwards. ## Mitigation and Workarounds While several workarounds exist, and are documented in our [technical whitepaper](https://www.jsof-tech.com/dnspooq-technical-wp/), the best and only full mitigation is to update dnsmasq to version 2.83 or above. ## Summary DNSpooq is a series of vulnerabilities found in the ubiquitous open-source software dnsmasq, demonstrating that DNS is still insecure, 13 years after the last major attack was described. 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.