The Domain Name System (DNS) provides a convenient platform for distributing resources in domains. A domain owner just needs to create a record with a new resource and anyone on the Internet can use DNS resolvers to look up the resources in any domain. DNS resolvers retrieve the resources transparently and this transparency has helped fast and smooth deployment of new technologies over the DNS. In this article we of Fraunhofer SIT and Goethe-Universität Frankfurt explain that, along with the huge benefits, the transparency of the DNS also introduces a gaping hole in Internet security.
We developed attacks that exploit the transparency of the DNS lookups to tunnel injection payloads over DNS records. These attacks exploit two key factors. Firstly, DNS resolvers do not alter the DNS records received in lookups, so the malicious payload is preserved intact. Secondly, the receiving applications do not sanitize the received records. During an attack, the adversary encodes injection payloads into the DNS records in the zone file of a malicious domain that it controls. When these records are processed by the receiving victim applications, a misinterpretation occurs, resulting in injection attacks. The attacks vary depending on the victim application and its usage of the DNS.
What systems are affected?
In our study, we analysed the behaviour of a wide range of Internet applications and systems that use DNS lookups: from DNS caches, to eduroam, and routers. We found that none of them validate records from DNS lookups, which exposes them to injection attacks.
For instance, because the DNS lookup’s record is included in the HTML page unfiltered, this can lead to a cross site scripting vulnerability in OpenWRT routers. We show that this can be exploited to gain full control over the routers. Another example is configuration injection vulnerability in a script included with radsecproxy used in eduroam (among others) to route authentication requests to the authentication servers of remote organizations. Vulnerabilities also exist in security mechanisms that use lookups such as libspf2, used by email servers to implement email sender verification via the Sender Policy Framework (SPF).
Even the DNS caches are vulnerable. We found an attack payload against DNS resolvers (shown below) that lets an attacker poison the resolver’s cache simply by triggering queries to a subdomain of his own — this is possible due to misinterpretations when decoding this malicious domain name into textual form. In our Internet measurements, we found that more than 100,000 DNS resolvers are vulnerable to cache poisoning by encoding injections into DNS records. Furthermore, we showed that such attacks are the first cache poisoning attacks that cannot be prevented even with DNSSEC, since DNSSEC validation is performed before this misinterpretation occurs.
Zone file for attacker.com
attacker.com IN CNAME victim.com\000.attacker.com
victim.com\000.attacker.com IN A 6.6.6.6
Zone file for victim.com
victim.com IN A 1.1.1.1
Queries causing the vulnerability (by luring the victim to a malicious website)
attacker.com IN A?
or: victim.com\000.attacker.com IN A?
Records cached
victim.com IN A 6.6.6.6
Zone file and attack queries for injection-based cache poisoning attack.
Which components should validate DNS records?
We analysed standard recommended component behaviour in DNS lookups and the default behaviour of different popular implementations — from applications that trigger DNS queries, to stub resolvers, recursive DNS resolvers, forwarders and nameservers. DNS forwarders and resolvers are expected to handle the DNS records transparently, and our Internet measurements confirmed that this is indeed the case.
On the other hand, stub resolvers (the component translating an application query via an API like gethostbyname() to an actual DNS packet and vice-versa), are expected to validate that domain names in DNS records are valid hostnames (according to RFC 952) before passing them to applications. However, we found that nine out of ten popular stub resolver implementations do not perform these checks.
Finally, we also analysed the DNS usage of different applications and found that none of the applications we analysed validate the DNS data they receive from resolvers. Together with the fact that neither recursive nor stub resolvers implement this validation either, this implies that almost any application that performs DNS lookups might be vulnerable to such an attack.
Countermeasures — it’s complicated
One of the root factors allowing these attacks is a lack of a threat model in the standard RFCs and a lack of specifications on DNS and its interaction with applications. The procedure for handling DNS records from DNS lookups isn’t clearly defined currently. The only standard is RFC 2553, which is the base for the POSIX standardization of the gethostbyname() API but does not mention validation. This creates vulnerabilities in many implementations that use DNS lookups and introduces a security gap in the Internet.
The solution is not straightforward. Patching DNS resolvers to filter invalid inputs would make the DNS rigid, but DNS flexibility is what made the protocol popular and allowed quick and easy deployment of numerous applications. Regardless, we’ve provided a proof-of-concept DNS proxy that implements such a filter on our website.
On the other hand, integrating validation into applications is a challenging task. Not only does it imply that every application must be fixed, but it is also not possible for application developers to anticipate the syntax of the DNS records that the application may receive. Furthermore, during our disclosure efforts, we found that many developers initially don’t understand the issue because they are not aware that DNS data can even contain such unexpected values, making the effort to fix applications more difficult.
Although we initiated disclosure and are coordinating distribution of patches, we believe a systematic solution requires coordination within the IETF and vendors to amend the standard.
Patches and CVEs
Our research has already resulted in 10 registered CVEs and patches. It also suggests a need for follow-up engineering and standardization work within the IETF and the operational community. The results contribute to understanding application and system dependency on DNS lookups, and the extent of vulnerabilities caused by an unclear specification for DNS’s interaction with applications. We also provide a tool that enables anyone to test their DNS resolvers for injection vulnerabilities on our website.
This article is based on the paper ‘Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS’, co-authored by Philipp Jeitner and Haya Shulman, published at USENIX Security 2021.
Philipp Jeitner is a Security Researcher at the German national research centre for applied cybersecurity ATHENE. In his work, his goal is to make the Internet more secure by identifying vulnerabilities and demonstrating attacks to motivate the deployment of defences.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.