Melting the DNS Iceberg: Taking over your infrastructure Kaminsky style

06.10.2022 vulnerability

Hidden DNS resolvers and how to compromise your infrastructure

By analyzing closed DNS resolvers on the Internet, we found numerous ISPs and hosting providers that are vulnerable to trivial Kaminsky attacks. This allows an attacker to manipulate the DNS name resolution of thousands of systems. As a consequence, e-mail redirections, account takeovers and even the compromise of entire systems may be possible. Closed DNS resolvers all across the world are affected.

This blog post describes the core problem of our research and how to find vulnerabilities in closed DNS resolvers. Furthermore, open-source tools such as the DNS Analysis Server, are introduced and provided. Lastly, we're showing how to take over a fully patched WordPress instance in a proof-of-concept exploit!

Does this affect me?
How can I protect myself?
Should I be on the lookout for DNS vulnerabilities?

The Q&A section at the bottom of this article covers these and many more questions.

The Core Problem

In our blog post “Forgot password? Taking over user accounts Kaminsky style” we showed how an attacker can take over user accounts of a web application by manipulating the DNS name resolution. Furthermore, we went into detail on how to find vulnerabilities in DNS setups of web applications and the fact that such vulnerabilities exist, even today. However, we didn’t tackle the core problem!

In general, if a system wants to resolve a name via DNS, a DNS resolver is used. A popular example for a DNS resolver is Google’s 8.8.8.8 resolver (as shown in figure 1). This resolver is public/open and can therefore be used by anyone on the Internet. Contrary to public/open resolvers, there are closed resolvers. Such resolvers reside in internal networks or are only accessible by a select group of systems. Closed resolvers may, for example, be provided to servers of a hosting provider, customers of an ISP or clients of a company. It is generally not expected that anyone on the Internet can access closed resolvers.

However, as shown in our previous DNS blog post, functionalities of web applications can be "abused" to analyze and attack these closed resolvers. Furthermore, it turned out that the most insecure resolvers were most likely closed resolvers. So, what if those closed resolvers are super insecure, but no one knows?

Or metaphorically speaking: What is hiding beneath the DNS resolver iceberg?

That’s what we’re going to find out!

Figure 3: Accessing closed resolvers with a spoofed source IP address

Aren't closed Resolvers... closed?

Closed resolvers are not directly accessible from the Internet, so how do we analyze and attack them?

In general, we need a way to send a DNS query to the closed resolver. In our previous blog post “Forgot password? Taking over user accounts Kaminsky style”, we achieved this by using registration, password-reset and newsletter functionalities of web applications. By specifying our special analysis domain as an e-mail address (e.g., test@0100001337.analysis.example), we were able to analyze the DNS name resolution of closed resolvers.

However, not every company exposes a web application, let alone has registration, password reset or newsletter functionalities. Another method of accessing closed resolvers is by spoofing the source IP address to an IP address that is permitted by the closed resolver [1] (see figure 3).

Though, this would not allow us to test resolvers in internal networks. That’s why we chose another, even easier, method. SPF, DKIM and DMARC are mechanisms for e-mail spam protection that utilize the DNS. Now, we can "exploit" these mechanisms to analyze closed resolvers. "But, how do we do that?", one might ask.

Exploiting Spam Protection

When sending an e-mail, the receiving e-mail server checks if the sender is allowed to send e-mails for the specified domain to prevent spam. For example, if we’re sending an e-mail as "test@gmail.com", the e-mail server will most likely send DNS queries for SPF, DKIM and DMARC information for "gmail.com". This means, that the resolver must contact the authoritative nameserver (ADNS) of gmail.com (as outlined in figure 4).

Figure 5: Closed resolver querying the analysis ADNS for SPF, DKIM and DMARC info

Figure 4: Closed resolver querying the ADNS of "gmail.com" for SPF, DKIM and DMARC info

Now, if we’re specifying our own analysis domain in the e-mail address (eg., test@0100001337.analysis.example), we can get the resolver to communicate with our own analysis ADNS for the "analysis.example" domain. This allows us to analyze the DNS name resolution of a potentially closed resolver. As always, a picture is worth more than a thousand words (see figure 5).

Figure 6: Analysis process for closed resolvers

Analyzing the DNS Resolution

So, we can get a potentially closed resolver to communicate with our analysis ADNS by sending an e-mail. What now?

Now, we analyze! By using an updated version of the DNS Reset Checker, the DNS Analysis Server, we can read and manipulate DNS traffic that goes to and from our analysis ADNS. By doing this, we can analyze the closed resolver's interesting DNS security features like source port randomization, DNSSEC, IP fragmentation and more. In a nutshell, this analysis process can be summarized as shown in figure 6.

For an in-depth look on how the DNS Analysis Server works, check out our previous blog post or take a look at the GitHub repository https://github.com/The-Login/DNS-Analysis-Server.

Scanning the Internet

Now that we know how to test closed resolvers for vulnerabilities, the (mental) heavy lifting is done. All that is left to do is sending e-mails to some well-known domains and specifying the analysis domain as the sending domain. For example, the following e-mail would be sent:

ehlo analysis.example
mail from: <test@0100001337.analysis.example>
rcpt to: <test@victim.example>
data
Subject: This is a test
Just checking!
.

The subdomain “0100001337” is used to specify the version of the test (01), the analysis method to start with (00), and the identifier of the tested domain (001337). Especially the identifier of the domain is crucial to be able to differentiate between DNS traffic of multiple domains.

Furthermore, to also trigger DNS queries for DKIM records, we add a DKIM signature with a corresponding DKIM selector “_dkim.0100001337.analysis.example” to our e-mail. A tool to create and send such e-mails is also included in the DNS Analysis Server!

Now, we can send this e-mail to a number of somewhat important domains and hope for the best/worst!

Figure 7: Scatterplot of UDP source ports used by a closed resolver

First Results

After going through the data of the first hundred domains the results were… underwhelming. However, just as we thought that we’re not going to find anything interesting, we found a domain with the following scatter plot of UDP source ports (see figure 7). To some people this might just look like some dots on a white canvas, but for us these dots meant a lot more. This is because these dots visualize the random distribution of source ports of a DNS resolver. However, as we can see, these source ports are not distributed randomly, but statically. So, what does that mean exactly?

Figure 8: Off-path attacking a DNS resolver

Figure 9: Very simplified Kaminsky attack

A Kaminsky Detour

In 2008, Dan Kaminsky showed the world how important the random distribution of source ports really is, or, why it should be. When a DNS resolver sends a query for "gmail.com" to the ADNS of "gmail.com", what protections hinder an attacker to send a manipulated DNS response to the resolver, before the actual response arrives? Well, it’s not a lot. Since DNS mainly uses UDP, an attacker could perform an off-path attack (as shown in figure 8).

However, nowadays it’s not quite that simple. An attacker must also guess the correct random 16-bit DNS ID and the correct random 16-bit UDP source port of the legitimate response. Combined that’s 32 random bits that amount to roughly 4 billion different combinations. Have fun guessing that! But back in 2008, only a few DNS resolvers actually used random source ports, making guessing roughly 65 000 times easier! This eventually led to Dan Kaminsky discovering the Kaminsky attack, which allows to manipulate caches of DNS resolvers with arbitrary DNS records, as displayed in figure 9.

Figure 10: Getting from an external resolver IP to other vulnerable domains 1/2

Going down the Rabbit Hole

Finding a static UDP source port distribution is great (at least for us), but we had a feeling that there is more to it. Since, why would there be a closed resolver for only one server, and not for many? So, we did a little bit of digging!

By checking the autonomous system number (ASN) of the IP address of the resolver, we discovered that the IP belongs to a hosting provider. Furthermore, by doing a reverse DNS lookup, we saw that the IP address is also associated with the name "dns3.victim.example". This sounds a lot like the name of an ADNS! Using a passive DNS database, we then revealed hundreds of domains hosted on this ADNS. Sending e-mails to these domains then allowed us to analyze their DNS name resolution. That way, 306 more domains were identified to be using static source ports for DNS queries (see figure 10).

Figure 11: Getting from an external resolver IP to other vulnerable domains 2/2

Bingo! But there is still more!

In some cases, the external IP address of the resolver is linked to a domain name like "id3451.mailprovider.example". This is a big indicator that the domain is using an external e-mail provider! By searching for the MX records of the originally identified vulnerable domain in a passive DNS database, we can find thousands of other domains that use the same MX records/e-mail servers. Testing these domains for static source ports in their DNS name resolution leads to hundreds of more vulnerable domains (as outlined in figure 11).

Figure 12: Heatmap of affected domains by IP address

The (in)security of closed DNS Resolvers

After sending e-mails to roughly 50k domains, we’ve received and analyzed DNS data for approximately 7000 of them. Among those 7000 domains, at least 25 were using static source ports. By going down the rabbit hole again, thousands of more domains using static source ports were discovered. Jackpot!

But what about DNS security features. Wouldn’t mechanisms like DNSSEC mitigate Kaminsky attacks? In theory yes, however, as discovered in our previous DNS blog post, most DNS resolvers don’t use these features or don’t enforce them. In this case, 0 of the 25 vulnerable resolvers were using/enforcing additional security features. This may be the result of misconfigured or outdated DNS software.

So, who was affected? Although we cannot disclose exact domains, here is a list of top-level domains (TLDs) that were identified to be vulnerable.

ie      eu      org     com     it      at      de      us      wien    jp      ch
es      uk      info    ca      net     cz      ua      cc      au      tel     ai
co      gr      sg      hk      tech    cn      biz     kr      la      me      fr
nz      gov     se      br      pa      pt      ru      li      ky      ms      lu

The heatmap of affected domains shows, that vulnerable servers are spread mainly across the northern hemisphere (see figure 12).

Affected services running behind these domains opens up a wide spectrum of possibilities. Lots of small-business websites were found alongside governmental services, political campaigns and websites of bigger companies.

Due to only having analyzed roughly 7000 domains, this is still probably only the tip of the closed resolver iceberg, as depicted in figure 13!

So, now we can manipulate the DNS name resolution of thousands of domains via Kaminsky attacks. But, where’s the problem?

Figure 14: Taking over user accounts Kaminsky style

Leveraging DNS

In general, by running a Kaminsky attack, an attacker can manipulate DNS entries of DNS resolvers. For example, an attacker could manipulate the MX entry for "gmail.com" to point to "attacker.example" (figure 14). As detailed in our first DNS blog post, this essentially allows an attacker to redirect e-mails!

This is especially delicate when thinking about administrative interfaces (e.g., WordPress, Joomla, etc.) and their password reset functionalities, since e-mails for password resets can be redirected as well (see example in figure 15). Even if a website does not expose any kind of "Forgot password?" functionality, sometimes the control panel of the hosting provider is affected as well (see figure 16).

Furthermore, it might be possible to manipulate SPF, DKIM and DMARC information, essentially allowing all kinds of e-mail spoofing (see figure 17). Also, by manipulating the DNS name resolution of a server, most network connections that depend on a DNS name resolution can be redirected, intercepted and maybe even manipulated. Dan Kaminsky gave a good overview of possible DNS attack vectors back in 2008!

Figure 15: WordPress login exposing "Forgot password?" functionality

Figure 16: Control panel login exposing "Forgot password?" functionality

Figure 17: Redirecting SPF lookups to the attacker

Proof of Concept

So, can we actually exploit closed DNS resolvers in practice?

As Dan Kaminsky already stated back in 2008, it is totally possible! The DNS cache poisoning exploit process looks somewhat like shown in figure 18.

The attacker sends an e-mail from the domain "XXX.mx.gmail.com" to the e-mail server, with XXX being a random subdomain not cached by the DNS resolver. The e-mail server then asks the closed DNS resolver for a TXT record for this name. Since the random subdomain is not cached in the DNS resolver, the resolver asks the ADNS of "gmail.com".

Figure 18: A Kaminsky attack on a closed resolver

An attacker can now try to race the actual response of the ADNS with a manipulated response. If the attacker's response wins the race, "mx.gmail.com" now points to "attacker.example". Otherwise, the attacker sends another e-mail with a different random subdomain and repeats the procedure until the DNS cache gets poisoned with the manipulated response. With a successful attack, an attacker can bend the example MX domain "mx.gmail.com" to point to the nameserver "attacker.example". This essentially allows the attacker to specify an arbitrary IP address for the e-mail server! The cache of a poisoned resolver would look as follows:

gmail.com.    300    NS    ns1.gmail.com.
              300    NS    ns2.gmail.com.
              900    MX    10    mx.gmail.com.
mx.gmail.com. 600000 NS    attacker.example.

By conducting this attack in a somewhat realistic environment, we confirmed that it is possible to poison caches of closed DNS resolvers and that we can take over fully patched WordPress instances by password reset redirection! However, to not wreak havoc on DNS resolvers world wide, we are not releasing the PoC infrastructure and PoC scripts for now.

Responsible Disclosure

To responsibly disclose this issue and contact affected ISPs and hosting providers, we submitted a vulnerability report to the CERT Communication Center (CERT/CC) in July this year. The CERT/CC immensely helped us with the coordinated disclosure. Huge thanks to the CERT/CC for their professional and quick communication and coordination!

However, since we cannot scan and fix the whole Internet, there are most likely still lots of vulnerable DNS resolvers out there.

Questions and Answers (Q&A)

We initially thought we were the first ones. However, after digging through some literature, we discovered that first tests were already done in 2018 [2]. Though, for some reason, no vulnerable resolvers were discovered. In a paper from 2020 [1], closed resolvers were again tested by IP spoofing internal IP addresses. The numbers from this paper are roughly the same as ours.

Yes, definitely, since DNS vulnerabilities may allow all kinds of bad things! Fortunately, checking for vulnerabilities in your DNS infrastructure can be done rather quickly with an already set up analysis server.

If there is uncertainty about used DNS resolvers and the DNS infrastructure in general, the easiest way to find out is with our DNS Analysis Server!

To prevent this attack vector, primarily the DNS infrastructure should be secured. Some best practices for securing your own DNS resolvers can be found at Google and at DNS flag day. Large public DNS providers such as Google, Cloudflare or Cisco can also be used. Countermeasures for new DNS attacks are usually implemented quickly by these large providers.

Whether vulnerabilities still exist after securing the DNS infrastructure can be checked with the DNS Analysis Server.

Yes! Firstly, due to the heaps of data we went through, it is fairly likely that we have missed some vulnerable resolvers. Furthermore, e-mails were sent to most likely non-existent e-mail addresses (e.g., test@victim.example). Depending on the e-mail server, this might not trigger a DNS resolution of our sender/analysis domain.

Out of the 25 vulnerable resolvers, only two of them were confirmed to be openly accessible. This supports the initial hypothesis that vulnerable resolvers are more likely to be closed. (Note that 35% of the analyzed resolvers were confirmed to be open and 65% to be closed).

Here you go! https://sec-consult.com/blog/detail/forgot-password-taking-over-user-accounts-kaminsky-style/

References

[1] Deccio, Casey, et al. "Behind closed doors: a network tale of spoofing, intrusion, and false DNS security." Proceedings of the ACM Internet Measurement Conference. 2020.

[2] Scheffler, Sarah, et al. "The unintended consequences of email spam prevention." International Conference on Passive and Active Network Measurement. Springer, Cham, 2018.

This research has been performed by Timo Longin and Clemens Stockenreitner and published on behalf of the SEC Consult Vulnerability Lab.

SEC Consult is always searching for talented security professionals to work in our team. More information can be found at: https://www.sec-consult.com/career

About the author

Timo Longin
SEC Consult
Senior Security Consultant

Timo Longin (also known as Login) is a senior security consultant at SEC Consult at day and a security researcher at night. Aside from everyday security assessments, he publishes blog posts and security tools, holds talks at conferences and universities, and has a passion for CTFs. As a well-rounded offensive security researcher, he tries to find forgotten and new exploitation techniques that make the unthinkable possible!

Back