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.
