Defending Against Subdomain Takeover Attacks

Subdomain Takeover

There is plenty of material covering these topics on the web, so I will try to keep this article simple and instructive. If you know enough about the basics already, just skip this part.

The Domain Name System (DNS)

One of the major features that drives the internet is DNS. It's the protocol that allows us to visit sites without having to type complex stuff like IP addresses in the browser - DNS resolves domain names to IPs for you.

DNS defines a hierarchical structure of domain names. These domain names are registered in DNS servers that receive queries (clients asking for details about domain names), and answer these queries with what they know - what's stored in their DNS records, which are organized in DNS zones.

When a server doesn't have the details that were requested, it will try to answer by referring to another server which is likely to have an answer. This server can then refer to another, and this chain of queries eventually gives the client an answer.

There are many types of DNS records that serve different purposes, such as CNAME, A, AAAA, TXT, SOA, MX, PTR, NS, etc. For purposes of this article we will be mainly talking about CNAMEs, A, AAAA and TXT records.

• A records store mappings from domain names (such as google.com) to IPv4 addresses (such as 142.251.134.110)
• AAAA records store mappings from domain names (such as google.com) to IPv6 addresses (such as 2800:3f0:4004:800::200e).
• CNAME records store mappings from domain names to other domain names.
• TXT records store arbitrary text that you want to have associated with your domain.

When you type a domain in the browser and hit enter, it will lead to a series of DNS queries. The main goal then is to find an IPv4 or IPv6 address that your computer can use to send out the IP packet that holds your request for the site.

When browsing the internet, since an IP address is required for your computer to build a packet that will reach the proper destination, A and AAAA records will usually be at the final answer from that chain of queries, giving us what we need.

CNAME records

CNAME records, on the other hand, are especially useful for cases where you don't have control over the IPs that host the application, such as when you need to publish a domain in your zone for an application hosted by a third-party.

Example. If you have applications that you need to distribute through a third-party CDN such as Akamai for performance, security and availability reasons, you will have to register some CNAMEs in your DNS zone to point your domains to Akamai's network.

Assuming you own the zone domain.com, you might have to register a CNAME record pointing www.domain.com to www.domain.com.edgekey.net, Akamai's entrypoint for client requests. Akamai will then do their magic - their DNS servers will answer to queries to www.domain.com.edgekey.net with another CNAME record pointing the user to a more specific name (such as e25254.a.akamaiedge.net), and then this third domain name in the chain will be resolved via an A record to a proper IPv4 address such as 23.73.216.41.

The problem

The problem that leads to subdomain takeovers lies on the hosted by a third-party part. If the third-party that hosts your target domain is an entity that does not guarantee that the target domain in their zone is uniquely yours, then your domain could be stolen in the future when you ask the third-party to deregister the target domain. The issue happens when you do that and don't remove the CNAME record pointing your source domain to their target domain.

An attacker who just happens to be searching the internet for attack vectors like this will find your source domain using a range of OSINT techniques. After realizing your domain is a CNAME to a third-party, the attacker will immediately access it to check if it's in use, and if it's not, try to look for ways to register the target domain with the third-party in order to steal your source domain and impersonate your site.

They may just use that power to earn some money in your bug bounty program, but they could also have less noble purposes such as performing phishing campaigns, distributing malware or causing reputational damage by altering the contents of your subdomain.

Many companies working with technology nowadays rely heavily on services from multiple third-party cloud providers, such as AWS, Azure and GCP, and it's not uncommon for a cloud provider to give customers access to claiming subdomains in their zones for usage with these services.

This means that cloud providers will sometimes allow you to register subdomains of their domains for use with their computing / storage services, and they will allow anyone to choose subdomains that were previously in use by other customers. The philosophy is that if another customer removed the subdomain from their account, then anyone should be able to register it.

Why it needs attention

The problem gets worse when companies grow a lot, creating tens of DNS zones for their domains, and then hundreds of CNAMEs in these DNS zones for their apps hosted in third-parties. If no one keeps track of which domains are in use and which ones are not (which is an exhaustive task), then over time it's likely that many CNAME records in their zones will become dangling (pointing to a decomissioned name).

This can also happen to A or AAAA entries, but it's a lot less likely that an attacker could take over an IP address of a third-party, since most of the times third-parties like cloud providers have large IP address spaces and will not allow you to "cherry-pick" the IP for your application.

Mitigation ideas for providers

There are two main ways a third-party provider can mitigate domain takeover scenarios:

• Don't allow users to register any target domain. A good example of this technique is what is done by AWS with the ELB service - they did a trade-off between security and usability by registering names with a sufficiently random component. When you create an ELB named yourname you get a name like yourname-RANDOM.region.elb.amazonaws.com. Even if you delete the ELB and someone tries to register yourname in the future, they will have to try it an impractical number of times in order to get the same random component you did.
• Check ownership of the source domain by requiring a DNS record that proves it belongs to the customer. This is the most common technique that providers do. Before registering an app with your source domain as a custom domain name on their platform, they will require you to add a record (most likely a TXT record) to your source zone with a random verification code. If you want to use www.yourdomain.com for an Azure App Service, for instance, it will require you to register a TXT for the asuid.www.yourdomain.com domain with a 32-byte (64 hexadecimal characters) verification code, so that they can verify that you own www.yourdomain.com. If they can't match the verification code with the one they provided, they won't allow it to be registered.

With subdomain takeover techniques being widely used in bug bounty programs, it should be clear by now that although these two mitigations are pretty simple, they aren't widely adopted yet. Some services will actually choose not to implement these in favor of user experience, or even leave a loophole, like using a not so random code that could be reproduced, or not validating ownership properly under certain conditions.

For instance, until recently Azure App Services would allow registering any custom domain that did not have a TXT record associated with it in their zone, and only deny the request if the TXT record existed and differed from the one they provided, pushing the responsibility of creating the TXT record to the customers that don't want to have their domains stolen. If customers decided to go the easy way and don't register the TXT record, they would be allowed to register the custom domain, also creating a future problem. I'm not sure whether this "loophole" still exists, but it's a good example.

Open-source resources

If you want to learn more about services that could be vulnerable to subdomain takeover, please check EdOverflow's can-i-take-over-xyz repo on GitHub. It's a collaborative list of domains that belong to providers that allow the takeover of decomissioned domains. The information there isn't always accurate (since it's a community effort), but it's a great starting point. And if you already have a list of domains that you need to check for possible takeover scenarios, regardless of whether you have access to the DNS provider or not, you can use LukaSikic's subzy tool to check for basic signs of a takeover scenario.

Another repository that tackles a similar problem is indianajson's can-i-take-over-dns, which documents providers that allow for the takeover of decomissioned DNS zones. DNS takeovers happen when the NS records (which point to the servers that are authoritative for an entire zone) for a domain point to nameservers of a third-party provider that allows registering decomissioned zones with the same nameservers. This problem is even worse, because if a DNS zone (such as yourdomain.com) is taken over, then the attacker can register any subdomain within that zone (such as sales.yourdomain.com). If you have a list of domains that you want to check for signs of DNS takeover scenarios, you can use zmap's zdns tool.

STARS

The best way to finally solve the issue is to have proper management of DNS records. Thinking about that I made a simple tool to help organizations understand the DNS records that they have hosted in popular cloud providers. If you host your DNS zones in AWS Route53, Azure DNS, Google Cloud DNS, CloudFlare or DigitalOcean, you can use this tool to check all your CNAME records to find dangling records, or just to dump all of your records in a JSON format and analyze them any way you want without having to navigate through dozens of DNS zones and dozens of pages of records in your cloud provider.

Don't hesitate to try it out and let me know what you think =)