A Guide to DNS Takeovers: The Misunderstood Cousin of Subdomain Takeovers

Introduction

Let's start with this: A DNS takeover is not the same as a subdomain takeover.

Subdomain takeovers are old news. Hackers who caught onto them early made busloads of bounties by automating their detection and exploitation. They're still out there, but competition is fierce. Crafty hackers built bots that detect and report subdomain takeovers within minutes of them becoming vulnerable.

DNS takeovers are the new Orange. They've become popular among seasoned bug bounty hunters, but are often misunderstood or mistaken for subdomain takeovers.

By the time you've finished reading this article, you'll understand:

What a DNS takeover is
How it differs from a subdomain takeover
How to detect DNS takeovers
How to perform DNS takeovers
Which providers are vulnerable

Onward! 👇

Domain Name Service (DNS) primer

Put simply: you send a hostname to a DNS server and send back the IP address to which the hostname points.

In practice, DNS is far more complex.

Firstly, the process of resolving hostnames to IP addresses is quite complex and typically requires at least 3 or 4 DNS servers around the internet.

Secondly, DNS does more than just resolve hostnames to IP addresses, DNS also stores other information about domains, verification codes, subdomains, instructions on how/where to send emails, and more.

Resolving a hostname

When we want to resolve a hostname to an IP address, we send that hostname to a DNS server and ask for the corresponding IP address. The DNS server may have the hostname's IP cached, in which case it can just return the IP address to you. If it doesn't have the IP address cached, a whole other process begins.

Let's say we're resolving the hostname "www.google.com" without caching.

We'd first ask one of the Internet's root DNS servers where we can find details for domains ending in .com. These root servers are listed below:

a.root-servers.net.
b.root-servers.net.
c.root-servers.net.
d.root-servers.net.
e.root-servers.net.
f.root-servers.net.
g.root-servers.net.
h.root-servers.net.
i.root-servers.net.
j.root-servers.net.
k.root-servers.net.
l.root-servers.net.
m.root-servers.net.

The response will be another list of DNS servers (below). We then ask one of these servers where we can find the details of domains ending in google.com.

a.gtld-servers.net.
b.gtld-servers.net.
c.gtld-servers.net.
d.gtld-servers.net.
e.gtld-servers.net.
f.gtld-servers.net.
g.gtld-servers.net.
h.gtld-servers.net.
i.gtld-servers.net.
j.gtld-servers.net.
k.gtld-servers.net.
l.gtld-servers.net.
m.gtld-servers.net.

The response we get is another list of DNS servers (below), we're getting closer! We then query one of these servers, asking what IP address www.google.com is pointing to. You'll see that we're now querying the authoritative DNS servers that Google themselves maintains.

ns1.google.com.
ns2.google.com.
ns3.google.com.
ns4.google.com.

Finally, one of these authoritative nameservers will respond with the IP address that www.google.com points to (it will vary):

172.217.167.100

What is a DNS takeover?

A DNS takeover occurs when an attacker can take control of any DNS server in the chain of DNS servers responsible for resolving a hostname. In other words, if we wanted to perform a DNS takeover on www.google.com, we'd need to take control of one of these DNS servers:

a.root-servers.net.b.root-servers.net.
c.root-servers.net.
d.root-servers.net.
e.root-servers.net.
f.root-servers.net.
g.root-servers.net.
h.root-servers.net.
i.root-servers.net.
j.root-servers.net.
k.root-servers.net.
l.root-servers.net.
m.root-servers.net.
a.gtld-servers.net.
b.gtld-servers.net.
c.gtld-servers.net.
d.gtld-servers.net.
e.gtld-servers.net.
f.gtld-servers.net.
g.gtld-servers.net.
h.gtld-servers.net.
i.gtld-servers.net.
j.gtld-servers.net.
k.gtld-servers.net.
l.gtld-servers.net.
m.gtld-servers.net.
ns1.google.com.
ns2.google.com.
ns3.google.com.
ns4.google.com.

If we controlled any one of these DNS servers, we could change the www.google.com DNS record to point to a server we own instead of Google's website. Not only that, we could also create our own *@www.google.com email addresses, add falsified DNS records for any subdomain of *.www.google.com, and more.

What's the difference between a DNS takeover and a subdomain takeover?

A subdomain takeover occurs when you take over the service that some DNS records are pointing to. A DNS takeover occurs when you take over the DNS server that is assigned to that host.

DNS takeovers are typically more severe because they give the attacker more control. When you achieve a subdomain takeover, the activities you can perform on that host are limited to the capabilities of the service you takeover. For example, if you take over a S3 bucket - you can only host a website/files. When you achieve a DNS takeover you can host any service that takes your fancy, and you can log everything in the process.

How do DNS takeovers work?

So, how exactly can we take control of these DNS servers?

These days, most organizations don't host their own DNS servers - they use cloud providers. All major cloud providers offer a solution for hosting DNS infrastructure.

Most of these cloud providers allow you to create DNS "zones". A zone is just a set of DNS servers that can be managed through the provider's web interface. Here's an example of 4 DNS servers that you might be assigned when you create a Route53 zone in AWS (Note: Route53 is no longer susceptible to DNS takeover attacks):

ns-261.awsdns-32.com.
ns-1032.awsdns-01.org.
ns-1739.awsdns-25.co.uk.
ns-1001.awsdns-61.net.

If you registered a new domain name and you wanted to use a cloud DNS provider as your authoritative nameservers, you would:

Create a new zone in the DNS provider
Set your nameservers to the DNS servers associated with your zone
Use the cloud provider console to add/remove/edit the DNS records associated with the domain

Now consider this scenario:

The victim buys a domain (example.com)
The victim sets up a zone with the DNS provider
The victim sets the zone as the authoritative nameservers for their new domain
At some point, the victim decided they didn't want to host anything on this domain anymore
The victim deletes the zone in the DNS provider but doesn't ever change the authoritative nameservers assigned to the domain.

This creates a situation where a domain's DNS records are controlled by DNS servers that anyone can use, but no one within this service claims the domain. As an attacker, if we can create a zone that uses any of the same nameservers, we could add DNS records for that domain.

Most DNS providers don't allow you to choose which nameservers get assigned. We can overcome this by creating many zones until we get one with a matching DNS server. This would be an extremely tedious process to perform manually - but we can automate the process.

Currently known vulnerable DNS services

A GitHub repository called "Can I Take Over DNS?" documents DNS services currently vulnerable to DNS takeovers and how to perform a takeover on each of them. It is a spinoff of the (in)famous "Can I Takeover XYZ?" repo by EdOverflow (BBAC), which documents the services vulnerable to subdomain takeovers.

At the time of writing, this repo marks the following services as vulnerable:

000Domains
Bizland
Digital Ocean
DNSMadeEasy
DNSimple
Domain.com
Dotster
EasyDNS
Google Cloud
Hurricane Electric
Linode
MyDomain
Name.com
NS1
TierraNet
Reg.ru
Yahoo Small Business

I'm sure you can spot some big names on that list!

Detection of DNS takeovers

The exact way to check if a domain is vulnerable varies a bit depending on which service it is pointing to - but generally, there are two criteria:

The domain returns a SERVFAIL (or sometimes REFUSED) when you try to resolve it
The authoritative nameservers for that domain belong to one of the vulnerable services in the list above

Automating the process

Let's run through a process of detecting DNS takeovers that could be easily automated.

Finding the nameservers for a domain

Firstly, we need to find all nameservers used to resolve the domain we want to check. We can do this using a dig trace, like so:

$ dig tesla.com +trace

While this works well, it is quite a messy output, so I prefer to use my own fork of Olivier Poitrey's "dnstrace". I just added an option to the tool for a simple output of nameservers, without any other information.

$ dnstrace -nsonly A google.com

l.gtld-servers.net.
b.gtld-servers.net.
c.gtld-servers.net.
d.gtld-servers.net.
e.gtld-servers.net.
f.gtld-servers.net.
g.gtld-servers.net.
a.gtld-servers.net.
h.gtld-servers.net.
i.gtld-servers.net.
j.gtld-servers.net.
k.gtld-servers.net.
m.gtld-servers.net.
ns2.google.com.
ns1.google.com.
ns3.google.com.
ns4.google.com.

Checking each nameserver

Now, you can check each of these nameservers, to see if any of them belong to a vulnerable service (e.g. ns*.digitalocean.com, ns*.domaindiscover.com, ns****.name.com…). In this case they do not. So in this case, we could see that a DNS takeover is not possible, and move on.

If any of them belonged to a vulnerable service, the next step would be to see if they return a REFUSED or SERVFAIL status when we resolve the domain. For the sake of example, let's check ns*.google.com against ns1.google.com using dig:

$ dig @ns1.google.com google.com

; <<>> DiG 9.10.6 <<>> @ns1.google.com google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11314
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com.			IN	A
;; ANSWER SECTION:
google.com.		300	IN	A	142.250.76.110

We would repeat this process for ns2.google.com, ns3.google.com and ns4.google.com.

In this instance, the status returned is "NOERROR", meaning that the domain resolves properly and is therefore not vulnerable. If the status was "REFUSED" or "SERVFAIL" here, we can be fairly certain that the domain is vulnerable. The next step would be to take control of the domain!

Taking control of the domain

The exact method that we use to takeover the domain will depend on the DNS provider, but in general, the process looks something like this:

Register an account with the DNS provider
Create a DNS zone
Check the nameservers that we were assigned to the zone
If the nameservers don't match any of the authoritative nameservers of the domain, delete the DNS zone and return to step 2
Create DNS records for the domain (e.g. an A record pointing to an IP address that we control)
Wait for propagation (usually an hour or 2)

Using Nuclei

There are a few nuclei templates that are designed for DNS-based takeover detection, for example:

id: servfail-refused-hosts

info:
  name: DNS Servfail Host Finder
  author: pdteam
  severity: info
  description: A DNS ServFail error occurred. ServFail errors occur when there is an error communicating with a DNS server. This could have a number of causes, including an error on the DNS server itself, or a temporary
    networking issue.
  classification:
    cwe-id: CWE-200
  tags: dns,takeover

dns:
  - name: "{{FQDN}}"
    type: A

    matchers:
      - type: word
        words:
          - "SERVFAIL"
          - "REFUSED"

This template will print a line if a DNS lookup on the tested hostname returns a SERVFAIL or REFUSED status. It doesn't go as far as checking if the DNS service is vulnerable, but this is a great start for initial detection.

Mitigation

Despite the risks, many organizations still have not figured out a good workflow for removing assets online without creating situations where they become vulnerable to DNS takeovers. It can be difficult to orchestrate the removal of assets without falling into a vulnerable state because it often requires coordination from multiple service providers.

In general, it helps to think of the removal of assets from the top down, i.e. remove assets in this order:

Remove the domain, or change the authoritative nameservers to something that can not be hijacked
Remove the DNS zone in your DNS provider
Remove the actual asset/service

It also helps to monitor your own cloud environments for situations like this to give you a fighting chance of detecting it before a hacker does!

Conclusion

Hopefully, reading this has given you a good idea of how DNS takeovers work, how they differ from subdomain takeovers, and how to exploit them. Until next time - happy hacking!

- Ben Bidmead (@pry0cc) and Luke Stephens (@hakluke)

Interested in Nuclei Cloud? Learn more here...