Impact of DNS over HTTPS (DoH) on DNS Rebinding Attacks
DNS over HTTPS (DoH) is a new protocol to perform DNS resolution over HTTPS. It has been in the news recently as Google and Mozilla have both implemented DoH in Chrome and Firefox respectively. DoH encrypts DNS traffic using HTTPS. This prevents internet service providers and anybody in a privileged network position to observe the traditional plaintext DNS traffic sent from the browser to the DNS server. Note that DoH service providers can observe the DNS traffic destined to them.
Last year, we presented our DNS rebinding attack prevention techniques at BSidesLV and DEF CON (slides, video) and released a tool, Singularity of Origin to simplify the exploitation of vulnerable services. Singularity includes built-in detection and attack payloads to identify and exploit vulnerable services along with state of the art techniques to automate and speed up DNS rebinding while evading protections. It has been successfully used in client engagements as we continue to uncover DNS rebinding vulnerabilities in local and remote applications with impact which can include sensitive information leaks, loss of money, or remote code execution.
We were obviously curious to understand the impact of DoH on DNS rebinding attacks; this blog post explores this impact. Note that the DoH protocol does not claim any protection against DNS rebinding attacks but protocol differences between DoH and plaintext DNS, or even DoH individual implementation choices, may adversely impact them. Furthermore, several DoH service providers do claim to have DNS rebinding protections and we were eager to evaluate them.
What is DoH?
DNS over HTTPS (DoH) enables Domain Name System (DNS) resolution via the HTTPS protocol. The classic DNS protocol transmits information in plaintext and therefore does not provide protection against network eavesdroppers. The primary goal of DoH is to incrementally improve user privacy by using HTTPS to encrypt the data between the DoH client and the DoH server. This hides in effect the name of web sites that users are accessing using their web browsers from public or private network owners or users, including from ISPs or guest Wi-Fi networks.
One major change introduced by DoH is that users can bypass local DNS resolvers and instead query a DoH server directly, therefore hiding queries from network operators such as ISPs and public Wi-Fi networks.
Most DoH providers support the DNS UDP wire format and JSON format. The DNS wire format (RFC 1035) is binary encoded and this is what browsers use by default. The JSON format is easy to read for humans and can be utilized using a simple curl command:
$ curl -H "accept: application/dns-json" "https://cloudflare-dns.com/dns-query?name=nccgroup.com type=A" | jqResponse:
{
"Status": 0,
"TC": false,
"RD": true,
"RA": true,
"AD": false,
"CD": false,
"Question": [
{
"name": "nccgroup.com.",
"type": 1
}
],
"Answer": [
{
"name": "nccgroup.com.",
"type": 1,
"TTL": 600,
"data": "199.83.128.134"
},
{
"name": "nccgroup.com.",
"type": 1,
"TTL": 600,
"data": "199.83.132.134"
}
]
}While you can set up your own DoH server with tools such as dnscrypt-proxy or DNS-over-HTTPS, most users will use a public DoH provider. Chrome currently supports the following 7 providers:
Firefox ships with Cloudflare and NextDNS as built-in providers but allows the easy configuration of any DoH server in its settings.
DNS Rebinding Attacks – A Refresher
Before going further, we provide a short, high-level refresher on what DNS rebinding attacks are. First, let’s define a few concepts, starting with the origin of web documents.
The origin of a web resource is a tuple consisting of the scheme such as http://, host such as example.com, and port such as 80. Two documents share the same origin if they have identical scheme, host and port components. So https://example.com/hello.html and https://example/world.html share the same origin but https://example.com/hello.html and https://nccgroup.com/hello.html do not because the origins’ host tuple components differ.
The same-origin policy dictates how two different origins may interact. A number of interactions are typically permitted when two resources share the same origin. More importantly, most interactions between resources of different origins are denied by browsers, to prevent a malicious site from accessing your webmail for instance.
DNS rebinding attacks permit to bypass restrictions imposed by the same-origin policy using DNS trickery, by essentially mapping an origin’s host component from an attacker to a victim domain. This forces web browsers to believe they are interacting with a specific domain, the attacker domain, when they are in fact interacting with another one, the victim domain. DNS rebinding attacks can be used to exfiltrate sensitive information, perform privileged operations or even trigger remote code execution if you run a vulnerable service on your network.
Our Singularity of Origin tool implements all this trickery using the plaintext DNS protocol. We were curious whether DoH would prevent Singularity from performing DNS attacks for any reasons including protocol differences or DoH service provider implementation idiosyncrasies.
More information on DNS rebinding attacks is available in our DEF CON presentation. Now that we understand at a high-level what DoH and DNS rebinding attacks are, let’s determine whether DoH introduced changes that would prevent these attacks.
Testing Singularity of Origin with DoH
Using our DNS rebinding framework, Singularity of Origin, we tested several DoH services to determine whether DoH prevents or adversely impacts DNS rebinding attacks. Our results show that DoH does not prevent DNS rebinding attacks and all rebinding strategies and techniques implemented in Singularity still work, including the fast multiple answers strategy and DNS cache flooding technique that allow rebinding in just a few seconds.
Test Setup
For our test setup, we configured the operating system DNS servers to the IPv4 and IPv6 addresses of the corresponding DoH provider. For example, when testing Cloudflare, we set the OS DNS servers to 1.1.1.1, 1.0.0.1 for IPv4 and 2606:4700:4700::1111, 2606:4700:4700::1001 for IPv6. We enabled the experimental dns-over-https flag in Chrome and set the DoH provider URL in Firefox to https://cloudflare-dns.com/dns-query.
We tested the following combinations:
- Chrome on Windows 10
- Chrome on macOS
- Firefox on Linux (Ubuntu 19.10)
We chose Chrome as it is the most used browser. On Linux, Chrome (and Chromium) does not support DoH so we used Firefox. Microsoft Edge and Apple Safari do not support DoH yet.
We tested with the following three DoH providers: Cloudflare, Google, and OpenDNS. Using Singularity of Origin, we targeted a vulnerable service listening on the localhost (127.0.0.1) and on the internal network (private IP address). We employed the following rebinding strategies:
- First then second: This strategy first returns the IP address of the Singularity server so that the browser can load the attack payload. Subsequent DNS requests will return the second IP address which points to the target service. This is the most reliable rebinding strategy that works on all tested platforms in 40 to 60 seconds.
- Multiple answers: This strategy can achieve a near instant DNS rebinding attack in less than 3 seconds. We tested this strategy with the interval option set to 1 second and the target address set to “0.0.0.0” on macOS and Linux and to “127.0.0.1” on Windows 10.
Results
All DNS rebinding tests conducted with the setup described above succeed using DoH. Our test results show that using DoH instead of plaintext DNS does not have a negative impact on DNS rebinding attacks. The table below summarizes our test results:
| Browser | Operating System | Strategy | DoH Provider | Success |
|---|---|---|---|---|
| Chrome | Windows 10, macOS | First then second, Multiple answers | Cloudflare, Google, OpenDNS | true |
| Firefox | Linux | First then second, Multiple answers | Cloudfare, Google, OpenDNS | true |
Not all DNS providers initially worked out of the box when using the multiple answers DNS rebinding strategy with Firefox on Linux. When troubleshooting the issue, we observed repeated DNS queries, which “refreshed” the time variable at which the last DNS query was seen. This indefinitely delayed the implementation of a Linux iptables firewall rule that forced the browser to switch to the target IP address three seconds after Singularity saw the last DNS query. The fix was easy to implement – Singularity now considers the time of the first DNS query instead of the last to decide when to perform rebinding.
Some DNS and DoH service providers advertise DNS rebinding protection functionality; are these protections effective? We shall see shortly.
DoH Service Provider’s DNS Rebinding Protection Features and Bypasses
DoH service providers such as NextDNS and OpenDNS advertise DNS rebinding protection features that are supposed to prevent DNS rebinding attacks. This is usually achieved by blocking DNS responses containing IP addresses that are commonly used in DNS rebinding attacks such as private (RFC 1918) or localhost IP addresses.
Singularity features multiple DNS rebinding bypass techniques presented during our DEF CON 27 talk in August 2019. These bypass techniques still work with DoH services that implement DNS rebinding protection features.
One bypass technique is using the 0.0.0.0 IP address, a non-routable meta-address. On Linux and macOS, this IP address can be used to access services listening on the loopback interface. NextDNS by default returns the “UNSPECIFIED_ADDRESS” (0.0.0.0) when they block a DoH request and their DNS rebinding protection feature is enabled. The NextDNS DNS rebinding protection will therefore not work to protect services listening on the loopback interface as Linux and macOS forward requests to this IP address of the local host.
Another DNS rebinding protection bypass is achieved using CNAME DNS records. This technique can bypass protection features that block all internal IP addresses. Canonical Name records (CNAME) map one domain name to another domain. Singularity can return a CNAME DNS record instead of an internal IP address (e.g. wiki.nccgroup.com or jenkins.internal.corp.com). This bypasses protections that block DNS responses containing private IP addresses. The local internal DNS server will then resolve the CNAME. We verified that this technique works well on Unix systems using DoH, even when “protection features” such as provided by NextDNS are enabled. The reason this still works with DoH is that browsers such as Firefox implement DoH in fallback mode (described in more detail in the next section), which falls back to the DNS servers configured in the operating system when DoH cannot resolve the name.
Do you want to try DoH for yourself to see how it affects your browsing? The next section explains how Firefox and Chrome implement DoH, how you can enable it today, and how to inspect DoH requests.
Configuring DoH in Firefox and Chrome
Firefox and Chrome are the two major browsers that have started testing DNS over HTTPS. Firefox has rolled out and enabled DoH in September 2019 in “fallback” mode. This means that if the domain name lookups that are using DoH fail, Firefox will fall back and use the default DNS configured by the operating system instead of displaying an error. This configuration allows all existing DNS rebinding strategies to work. When the DoH server receives a DoH request that it cannot resolve such as a CNAME pointing to an internal, private IP address (e.g. wiki.nccgroup.com), the DoH server will return the CNAME DNS response and Firefox will revert to a plaintext DNS request to the internal DNS server.
Chrome includes the DoH experiment since Chrome 78 (October 22, 2019). Unlike Firefox, Chrome only uses DoH when the user has configured one of the (currently 7) preconfigured DoH providers. When a user has configured their browser to use one of these public DoH providers (e.g. Google, Cloudflare, OpenDNS), internal IP addresses will not be resolved, which eliminates certain DNS rebinding strategies, such as using CNAMEs. DNS rebinding using Chrome still works using all other strategies including the fast multiple answers and cache flooding.
How to Setup DoH
Configuring Firefox and Chrome to use DoH is straightforward, though testing and debugging can be a bit tricky. The following sections explain how to enable DoH and monitor DoH and DNS request to verify that it is working properly.
Enable DoH in Firefox
- Click the menu button and select Options.
- In the General panel, scroll down to Network Settings and click the Settings button.
- In the dialog box that opens, scroll down to “Enable DNS over HTTPS”.
- Select the “Enable DNS over HTTPS” checkbox to enable DoH.
- Select a provider or set up a custom provider.
Enable DoH in Chrome
Type ‘chrome://flags/#dns-over-https‘ in the URL bar and select ‘Enabled’ from the drop-down menu. Chrome only uses DoH when the operating system DNS configuration is set to one of the (currently 7) supported (Cleanbrowsing, Cloudflare, Comcast, DNS.SB, Google, OpenDNS, Quad9) DNS providers. For example, to use Cloudflare as the DoH provider, set the DNS servers of your OS to 1.1.1.1 / 1.0.0.1.
Verify Your DoH Configuration
DoH providers such as Cloudflare and NextDNS provide an easy way to check if DoH is enabled in the browser. For Cloudflare, browse to https://1.1.1.1/help and check if “Using DNS over HTTPS (DoH)” says yes. For NextDNS, browse to https://my.nextdns.io/start and check if the page displays “This device is using NextDNS”.
To look at the content of the DoH HTTPS requests and responses, common HTTP proxies such as Portswigger’s Burp Suite or the OWASP Zed Attack Proxy (ZAP) can be used. Browsers by default use the POST method for DoH requests which encodes messages in DNS binary wire format defined in RFC 1035 with Content-Type application/dns-message in the request body and in the DoH HTTP response. This makes it harder to read in HTTP proxies (e.g. Burp Proxy).
Wireshark on the other hand comes with an excellent DoH decoder. To enable Wireshark to decrypt the DoH TLS packets, browsers can be configured to log TLS keys to a log file with the SSLKEYLOGFILE environment variable. Using Wireshark also has the advantage to see plaintext DNS packets on port 53. This allows you to verify for which requests the browser is using DoH and for which DNS requests the browser is reverting to plaintext DNS. Once the SSLKEYLOGFILE environment variable has been set (e.g. export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt), start Wireshark first, then the browser. In Wireshark set the display filter to ‘dns’. This will only show plaintext DNS traffic (port 53) and decrypted DoH messages.
Conclusion
DoH allows users to encrypt DNS traffic by using a TLS channel directly to a single provider they trust. We saw that using DoH instead of plaintext DNS does not have an impact on DNS rebinding attacks; we were able to successfully perform all DNS rebinding attack strategies implemented in Singularity of Origin when targeting a vulnerable service. Some DoH service providers implement DNS rebinding protection controls but none are fully effective when employing Singularity of Origin.
Authors
Roger Meyer (@sanktjodel) and Gérald Doussot (@gerald_doussot).