Forgot password? Taking over user accounts Kaminsky style

The "Forgot password?" feature and how DNS vulnerabilities may allow the takeover of user accounts.

TL;DR

After analyzing 146 web applications for vulnerabilities in their DNS name resolution, Timo Longin (SEC Consult Vienna) discovered that some web applications are still vulnerable today. Kaminsky as well as IP fragmentation attacks may allow to take over user accounts of these web applications via the "Forgot password?" feature. To identify vulnerable web applications, the DNS Reset Checker is provided.

  • Does this attack vector affect me?
  • How can I protect myself?
  • Should I be on the lookout for this attack vector?

The Q&A section covers these and many more questions.

 

Forgot password?

It's hard to imagine login forms without this question.

  • Specify e-mail address
  • Receive password reset URL
  • Change password

Easy! But how is the "Forgot password?" feature related to DNS vulnerabilities?

The following scenario brings this closer:

Assuming an attacker can inject arbitrary DNS records into the cache of the DNS resolver used by a web application (DNS cache poisoning), he will then be able to manipulate the mapping of e-mail domains to IP addresses. A DNS name resolution of "gmail.com" therefore no longer necessarily leads to the IP address of Google's e-mail server, but, for example, to the IP address of the attacker's e-mail server.


That way, said attacker can receive all e-mails destined to "gmail.com". Including password reset e-mails.
The following picture illustrates this:

Illustration showing DNS traffic from web app (left), ober DNS resolver (middle) to the ADNS (right).
Figure 1: Redirecting e-mails via DNS cache poisoning [14]

So, if an attacker can manipulate the DNS name resolution of a web application, the "Forgot password?" feature could be abused to take over user accounts.

Dan Kaminsky already presented this attack vector in 2008 at the Black Hat conference [1]. The following analysis of 146 web applications, which was conducted during Timo Longin's diploma thesis "DNS vulnerabilities in web applications" [14], shows that the attack vector is still relevant today.

Figure 2: DNS traffic between web application, DNS resolver and ADNS of the "analysis.example" domain [14]

The Basics

So, how do you check the DNS name resolution of 146 web applications for vulnerabilities?

By registering 146 users! Multiple times!

When a user registers on a web application, the web application most commonly sends an e-mail to verify the e-mail address. Take the e-mail address is "test@analysis.example". In order for an e-mail to be sent, the e-mail domain of said e-mail address must first be resolved to an IP address. So, for "analysis.example", the IP address of the e-mail server must be determined. After a few DNS queries, this results in a DNS query with the type "MX" being sent to the authoritative name server (ADNS) of "analysis.example" (see figure 2).

Figure 3: DNS traffic flowing through the DNS proxy [14]

If we now want to analyze the DNS name resolution of a web application, then the DNS traffic flowing to and from ADNS is a suitable option. To make it possible to manipulate DNS queries and responses in an "on-path" fashion, it was necessary to develop the "DNS proxy" software component shown in the following diagram (see figure 3).

The DNS proxy allows to read and modify DNS queries as well as responses sent to and from the ADNS. Thus, it is possible to passively analyze DNS messages and actively manipulate DNS responses. Furthermore, the DNS proxy or rather the source-code of the entire analysis server is freely available on GitHub! (More on that later!)

In a nutshell: If a user registers on a web application, it is possible to examine the properties of the web application's DNS name resolution.

E-Mail Addresses for DNS Analysis

With the setup shown above, it is possible to analyze the DNS name resolution of web applications. But what happens if the e-mail address "test@analysis.example" is registered on multiple web applications?

This causes "analysis.example" to be resolved by multiple web applications, and it's no longer possible to differentiate between DNS requests from the different web applications. For this reason, we must register users on different web applications using different e-mail addresses. For this purpose, we used the following format:

test@VVAAIIIIII.analysis.example

V: Versioning

A: The method to check for a specific attack requirement

I: Identifier of the web application

If we checked a web application in test run 1, with the first method (starting at 0) and the identifier 1337, we would register a user with the following e-mail address:

test@0100001337.analysis.example

DNS Attacks and their Requirements

At this point, it is possible to differentiate between DNS traffic from different web applications. But what should actually be analyzed?

To find this out, we look at previous DNS attacks and break them down to determine their attack requirements. In this way, it is possible to determine which properties a DNS name resolution must have to be attackable or vulnerable.

Find below two examples:

Attack requirement - IP fragmentation: The DNS attack discovered by Amir Herzberg and Haya Schulman [2] requires a DNS resolver to accept IP-fragmented DNS responses. This requirement can be checked by actively manipulating DNS responses using the DNS proxy. For example, a DNS response for testing IP fragmentation looks like the following (see table).

;; QUESTION SECTION:

;0100001337.analysis.example.          IN      MX



;; ANSWER SECTION:

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

The length of this DNS response exceeds the Maximum Transmission Unit (MTU) and must therefore be transmitted in multiple IP packets (IP fragmentation). If the requesting DNS resolver accepts this fragmented DNS response, it carries out an attempt to resolve "a.jlguehdhzo.if.0100001337.analysis.example". As soon as the DNS proxy receives such a DNS request, we can assume that the DNS resolver of the web application supports IP fragmentation.

Attack requirement - Source Port Randomization: Another example is requirements of a Kaminsky attack [1]. One of the requirements is that DNS requests have a low entropy and thus DNS responses are easy to guess. This low entropy results from the fact that source ports are not randomly assigned. We can check this requirement by analyzing log files of the DNS proxy. Scatter plots are particularly well suited for this purpose (see figure 4).

Figure 4: Scatter plot of randomly distributed UDP source ports

In this case, source ports are chosen randomly, which makes Kaminsky attacks hardly feasible.

The Eternal DNS Resolution

Now, the DNS proxy allows to check for a variety of attack requirements for multiple web applications. However, we need to discuss one more important detail about the DNS proxy. Namely, the DNS proxy does not reveal the IP address of the e-mail server under any circumstances. Why is that?

If a web application manages to resolve an e-mail domain into an IP address, as a result, the e-mail to be sent will be sent. This means that the web application doesn't need to make any further DNS queries.
For this reason, we remove all DNS records that reveal the IP address of the e-mail server in all DNS responses. For example, if a web application attempts to resolve DNS records returned in an IP-fragmented DNS response ("a.jlguehdhzo.if.0100001337.analysis.example"), then the DNS proxy removes the answer section set by the ADNS. This way, the web application subsequently tries to resolve the e-mail domain again and the different attack requirements can be checked one after the other.

Register Now!

Now the time has come! Nothing holds us back from analyzing the DNS name resolution of 146 web applications!

The test procedure looks like this (see figure 5).

Figure 5: Test procedure for checking web applications for DNS vulnerabilities [14]

Everything starts with a registration. In this case, we use the e-mail address "test@0100000001.analysis.example" to register on the web application with identifier "000001". This initiates a DNS name resolution that can be used to test for one or more attack requirements. To see which attack requirements have already been tested and which are still missing, the log file of the DNS proxy can be checked. Depending on the requirements already checked, we may have to register further users. To not test the same attack requirement multiple times, we can specify the test method to perform in the e-mail address (01XX000001.analysis.example).

After about 20 hours of registering users and several hundred hours of research, scripting and analysis, the results are now available.

The DNS (in)security of the 146 web applications

So, how does the DNS security of the assessed web applications fare?

A total of 8 different attack requirements were tested for 5 different DNS attacks. DNS attacks for which all attack requirements were met at least once are the following:

  • Kaminsky attack: 2 of 146

  • IP fragmentation attack: 62 from 146

Note: Due to ongoing disclosure processes, we will not publish specific names of web applications.

Kaminsky attack: The attack requirements tested for the Kaminsky attack are fulfilled for 2 of the 146 web applications. These requirements are specifically the following:

  • Low entropy of DNS requests

  • No usage/enforcement of DNS security features (DNSSEC, DNS cookies, etc.)

  • It is possible to trigger a large number of DNS queries to a "victim" domain (for example, "gmail.com")

Figure 6: Web application with static source port distribution [14]

The low entropy of DNS requests is particularly interesting here. As already shown, it can be visualized with scatter plots of UDP source ports. The scatter plot of a vulnerable DNS name resolution of an online casino looks as follows (see figure 6).

Every second DNS request uses source port 30200, other DNS requests use incremental source ports. This makes it easy for an attacker to guess used source ports and perform a Kaminsky attack.

The second web application (a news station) with guessable source ports has the following scatter plot (see figure 7).

Figure 7: Web application with incremental source port distribution [14]

In this case, source ports are incrementally distributed on 3 "levels", which also makes them easy to guess.

IP fragmentation attack: 62 of the 146 web applications tested meet the following requirements, analyzed for IP fragmentation attacks:

  • Web application DNS resolvers accept IP-fragmented DNS responses

  • No usage/enforcement of DNS security features (DNSSEC, DNS cookies, etc.)

  • It is possible to trigger a large number of DNS queries to a "victim" domain (for example, "gmail.com")

It should be noted at this point that only the requirements regarding the DNS name resolution of the web application were checked. IP fragmentation attacks, for example, also require that an attacker can fragment DNS responses sent from a target ADNS to a target DNS resolver.

Other data: What about DNS security features? What about DNSSEC? The following table gives a brief overview:

DNS security feature Usage* Enforcement**
DNSSEC 20 of 146 9 of 146
DNS cookies 1 of 146 1 of 146
0x20 encoding 0 of 146 0 of 146
EDNS buffer size limitation(<= 1232 Bytes) 0 of 146 0 of 146

*: A DNS security feature is considered used if it is used for every DNS query. For example, if 0x20 encoding is used only for "MX" queries, "A", "AAAA" and queries for other record types are still unprotected. An attacker can exploit the absence of such security features. For this reason, the usage of a DNS security feature is disregarded until it is actually used for every DNS query.

**: In some cases, DNS security features are optionally used but not enforced. For example, DNS resolvers can request signed DNS responses without validating them. When security features are used in this way, they do not provide any additional protection. The Enforcement column thus indicates whether DNS security features are used as well as enforced.

The DNS Reset Checker

As mentioned before, the used analysis server is freely available on GitHub. It is one of the two tools included in the DNS Reset Checker, which can be found here:

https://github.com/The-Login/DNS-Reset-Checker

The DNS Reset Checker consists of the analysis server and a log analyzer.

The analysis server is used, as already shown, to obtain DNS data as well as to check attack requirements. The log analyzer is used to analyze the gathered data. Scatter plots, probed attack requirements, DNS security features and much more can be analyzed with the log analyzer. In addition to the scatter plots seen above, the following infos are provided:

Analysis of domain identifier: 999997

General Info

* Number of DNS resolver IPs: 64

* Public DNS resolvers: Outgoing IP addresses of big public DNS resolvers: 32 / 64

* Number of queries received: 346

* Active methods probed: ip_fragmentation, edns_removal, recursive_delegation

* EDNS maximum size: Not all DNS requests specified a response size.

* DNS cookies: At least one DNS query did not include a DNS cookie.

* DNSSEC: At least one DNS query did not require DNSSEC.

* Removal of EDNS (OPT): A response with a missing EDNS record was returned by the server and accepted by the resolver.

* IP fragmentation: An IP fragmented response was returned by the server but denied by the resolver.

* 0x20 Encoding: At least one DNS query did not use 0x20 encoding.

Sneak peek of the infos provided by the log analyzer

Detailed instructions on how to install and use the DNS Reset Checker can be found on GitHub.

Questions and Answers (Q&A)

Should I be on the lookout for this attack vector in future security assessments?

Yes, definitely! Since this attack vector may allow account takeovers, it should be included in security assessments if applicable. Furthermore, checking for this attack vector can be done rather quickly with an already set up analysis server.

How do I know if I am affected?

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

How can I protect myself?

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

Whether vulnerabilities still exist after securing the DNS infrastructure can be checked with the DNS Reset Checker.

My DNS resolvers are all up to date, so I'm safe... right?

Keeping DNS resolvers up to date is a step in the right direction, but vulnerabilities in the DNS name resolution may still exist. For example, network infrastructure such as NAT/PAT devices can have an impact on the randomness of UDP source ports, allowing Kaminsky attacks (see Herzberg et al. [9] and Vulnerability Note VU#800113 [10]). This is also the reason we don't talk about the security of DNS resolvers, but about the security of the entire DNS name resolution.

Do DNS vulnerabilities affect me even if I don't use a public DNS resolver?

Yes, at least partially. As Dan Kaminsky already underlined in 2008 [1] and as verified again in a Lab environment, the use of private DNS resolvers does not protect against Kaminsky attacks.

Can DNS vulnerabilities be prevented by using TLS for e-mail traffic?

In theory, yes. As in browsers, the severity of DNS vulnerabilities can be dampened by using TLS. However, it must be taken into account that TLS must be used correctly. Often TLS is used, but only with self-signed and untrusted certificates (Mayer et al. [11]). This provides protection against a passive observer, but not against an active attacker (on-path).

Is account takeover the only way to leverage DNS vulnerabilities in web applications?

No, depending on other functionalities of web applications that use the DNS, server-side request forgery (SSRF) or similar attacks could also be possible. Some of such attacker vectors can be found in Dan Kaminsky's presentation [1] . In this article, we focused on the "Forgot password?" feature, since it is used by many web applications.

How can results of the DNS Reset Checker be rated?

To rate the results of the DNS Reset Checker, you can look at fulfilled attack requirements. Depending on the fulfilled attack requirements, the DNS name resolution in question can be assigned a higher or lower risk.

If, for example, guessable UDP source ports are used, one of the main requirements for Kaminsky attacks is fulfilled and consequently Kaminsky attacks are very likely to be possible. Accordingly, there is a high risk.
If IP fragmentation is possible, but other attack requirements are unclear, then the probability of a successful attack is rather low. Accordingly, there is a lower risk.

Why exactly 146 web applications?

During initial testing, users were registered on approximately 190 web applications (Alexa Top 500, etc.). Since some web applications only allow e-mail addresses from large providers (gmail.com, outlook.com, etc.) or do not send registration e-mails, 146 web applications were ultimately checked.

Have attack requirements for new attacks such as SAD (Side channel AttackeD DNS) and DNSpooq also been checked?

No, since analyses were completed before these attacks were published. Testing methods for their attack requirements may be included in future versions of the DNS Reset Checker.

Has there already been done research regarding DNS security of web applications prior to this research?

Partially as well as indirectly. Most analyses regarding DNS security on the Internet deal with open DNS resolvers that are available on the Internet. This way, it can be detected that a DNS resolver is vulnerable, but not that a web application uses it.

An analysis specifically addressing the DNS security of web applications was not found.

Don't online tools for checking DNS security already exist?

Yes, there are several online tools for checking DNS security (e.g. GRC [12] or DNS-OARC [13]). However, these only test the DNS name resolution of the DNS resolver specified by the system. Since web applications sometimes use DNS resolvers that are not accessible from the Internet, testing in this way is limited.

How was this attack vector "rediscovered"?

In internal security assessments, it is common practice to exploit the "Forgot password?" feature of internal web applications to obtain password reset URLs in e-mails. This is easy to do in a local network, as malicious-in-the-middle attacks can be done using ARP spoofing to redirect password reset e-mails sent by web applications to the attacker. Based on this attack vector and with the potentially devastating consequences in mind, an attempt was made to apply this concept to web applications on the Internet.

References

[1] D. Kaminsky, Black ops 2008: It's the end of the cache as we know it, Black Hat USA 2, 2008.

[2] A. Herzberg und H. Schulman, „Fragmentation considered poisonous,“ in 2013 IEEE Conference on Communications and Network Security (CNS), 2013.

[3] https://developers.google.com/speed/public-dns/docs/security

[4] https://dnsflagday.net/2020/#action-dns-resolver-operators

[5] https://developers.google.com/speed/public-dns

[6] https://www.cloudflare.com/learning/dns/what-is-1.1.1.1

[7] https://www.opendns.com/cisco-opendns/

[8] https://blog.cloudflare.com/sad-dns-explained/

[9] A. Herzberg und H. Shulman, „Security of patched DNS,“ in European Symposium on Research in Computer Security, Berlin, Heidelberg, 2012.

[10] https://www.kb.cert.org/vuls/id/800113/

[11] W. Mayer, A. Zauner, M. Schmiedecker und M. Huber, „No need for black chambers: Testing TLS in the e-mail ecosystem at large,“ in 2016 11th International Conference on Availability, Reliability and Security (ARES), 2016.

[12] https://www.grc.com/dns/dns.htm

[13] https://www.dns-oarc.net/oarc/services/dnsentropy

[14] T. Longin, DNS-Schwachstellen in Webapplikationen: Eine Untersuchung der Sicherheit der DNS-Namensauflösung von Webapplikationen, 2020.

About the author

Portrait of Timo Longin SEC Consult
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!