The Domain Name System (DNS) is a central element in the addressing and routing of all communication over the Internet. Many enterprise IT security professionals don’t always know how DNS works, or how attackers might use it to compromise their data. Following is a discussion about recent attacks and exploits that use DNS and some best practices for defending against DNS-based threats.
The Domain Name System is known to be insecure. For many years, the IETF has worked to address this, and it has published the DNSSEC (RFCs 4033, 4034, and 4035). DNSSEC provides DNS clients (resolvers) origin authentication of DNS data, authenticated denial of existence, and data integrity. It does not address availability or confidentiality. Unfortunately, DNSSEC is still not widely deployed.
In the meantime, new vulnerabilities and exploits of various DNS implementations continue to be discovered. A quick search of the National Vulnerability Database (NVD) on the term DNS returns 434 matching records. In 2016, 17 new DNS related vulnerabilities have been documented and published in the NVD so far. The CVSS scores of these 17 recent vulnerabilities have varied from a low of 4.3 to a high of 9.8.
Some of the most recently published vulnerabilities apply to a narrow range of products such as “CloudBees Jenkins prior to version 2.3” while others apply to a broad range of products.
In February of 2016, a flaw was found in an underlying library used by the DNS resolver implementation that is found on nearly all Linux machines, including many embedded devices that use Linux. This was published in the NVD as CVE-2015-7547. This also impacted product such as Oracle’s Exalogic and a variety of products from Blue Coat (https://bto.bluecoat.com/security-advisory/sa114) as well as many others. The vulnerability can lead to either denial-of-service or the remote execution of arbitrary code.
Different DNS vulnerabilities have different mitigations. For example the list of recommended mitigations for CVE-2015-7547 include:
- A firewall that drops UDP DNS packets > 512 bytes.
- A local resolver (that drops non-compliant responses).
- Avoid dual A and AAAA queries (avoids buffer management error) e.g. Do not use AF_UNSPEC.
- No use of `options edns0` in /etc/resolv.conf since EDNS0 allows responses larger than 512 bytes and can lead to valid DNS responses that overflow.
- No use of `RES_USE_EDNS0` or `RES_USE_DNSSEC` since they can both lead to valid large EDNS0-based DNS responses that can overflow.
However, some other recommendations that were effective against other DNS vulnerabilities were not effective for CVE-2015-7547, for example:
- Setting `options single-request` does not change buffer management and does not prevent the exploit.
- Setting `options single-request-reopen` does not change buffer management and does not prevent the exploit.
- Disabling IPv6 does not disable AAAA queries. The use of AF_UNSPEC unconditionally enables the dual query.
- The use of `sysctl -w net.ipv6.conf.all.disable_ipv6=1` will not protect your system from the exploit.
- Blocking IPv6 at a local or intermediate resolver does not work to prevent the exploit. The exploit payload can be delivered in A or AAAA results, it is the parallel query that triggers the buffer management flaw.
The primary defenses that companies must manage well are:
- Subscribe to services that will inform the IT staff when a security vulnerability for the company’s systems has been disclosed and when a new security update is available
- Apply security updates from your vendors in a timely manner
- When your vendors publish recommended mitigations to address a known vulnerability, test the recommendations and deploy them if possible
The recommendations above are not unique to DNS vulnerabilities.