DNS Reset Checker: assess the DNS security of web applications

by do son · September 9, 2021

DNS Reset Checker

Tools to assess the DNS security of web applications.

Background

DNS security of web applications? What?

The DNS is a central part of many functionalities of a web application. This includes sending e-mails. If a web application wants to send an e-mail, the e-mail domain first needs to be resolved to an IP address. This is done via a DNS name resolution. Easy!
But what happens, if this DNS name resolution is vulnerable?
In this case, an attacker could manipulate the resolution of the e-mail domain. This furthermore means that e-mails can be redirected to an attacker e-mail server, instead of the actual e-mail server.
This concept is summarized in the following image:

An attacker can receive e-mails, so what?

Among newsletters and account notifications there is another functionality that almost always uses e-mails:
The “Forgot password?” feature.
A successful attack on the DNS name resolution of a web application combined with the “Forgot password?” feature can therefore lead to the takeover of user accounts.
This attack vector is not new and has already been discussed back in 2008 when Dan Kaminsky “broke” the DNS. However, as recently discovered in my diploma thesis, some web applications still have a vulnerable DNS name resolution.
Now, to check for vulnerabilities in the DNS name resolution of a web application, the DNS Reset Checker comes into play.

A more in-depth look at the DNS security of web applications and the inner workings of the DNS Reset Checker can be found here.

How do I know if a web application is vulnerable?

As just mentioned, the analysis server tests for attack requirements. These are requirements for DNS attacks.
If all requirements for a DNS attack are fulfilled, the attack should be practically possible.
Currently, the DNS Reset Checker can be used to test for 2 DNS attacks:

Kaminsky attacks
IP fragmentation attacks

What exactly are their attack requirements, one might ask. Here’s a summary of some main requirements:

Kaminsky attacks:
1. Low/No random distribution of source ports
2. No usage/enforcement of DNS security features (DNS SEC, DNS cookies, 0x20 encoding, etc.)
IP fragmentation attacks:
1. The DNS resolver of the web application accepts IP fragmented DNS responses
2. No usage/enforcement of DNS security features (DNS SEC, etc.)
3. Maximum EDNS buffer size larger than 1232

For example, if the DNS name resolution of a web application is vulnerable to Kaminsky attacks, you might see the following scatter plot via the log analyzer:

The other requirements mentioned can be checked by reading the “General Info” section of the log analyzer output or by analyzing the dns_log.txt log entries directly.