# 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.
Se7en 关注了该漏洞
京公网安备 11010502034610号
暂无评论