Building to Prevent Subdomain Takeovers

There has been a lot written about subdomain takeovers. ¹

It’s also a very common bug bounty report.

While the average takeover mostly risks a reputational issue or phishing enablement, they can be higher impact by leading to ^{2 3} :

• Cookie harvesting (e.g recent research from Truffle)
• XSS, CSRF, CORS bypass, etc.
• Bypasses of Oauth Whitelisting or Content-Security Policies
• Password managers/autofill

This has led to some solid coverage of subdomain takeover prevention, for example:

• Prevent dangling DNS entries and avoid subdomain takeover from Azure
• Subdomain Takeovers - How Can I Prevent Them? from Mozilla
• Subdomain Takeover — Understanding the Risks, Tools, Impact, & Mitigations
• Subdomain Takeover by Anthony Pipia at CactusCon 12

However, everyone seems to focus on what consumers can do to prevent subdomain takeovers, leading to tools like OWASP domain-protect.

In this post, I instead summarize what platforms should do when building features reliant on custom subdomains. If platforms build these features safely, then all their users are protected by default.

Architectural Defenses against Subdomain Takeovers

📓 can-i-take-over-xyz offers a clearing house of information on which platforms are susceptible to subdomain takeovers. Reviewing safe platforms is a good way to see example documentation and implementation of the controls we’ll discuss.

There are a few options for preventing subdomain takeovers, when you’re building a platform offering custom domains.

1. Require validation of domain ownership

The most common technical control against subdomain takeovers is domain control validation.

There are several viable mechanisms to implement validation, including a draft RFC.

Most services appear to simply provide a verification string to be included in a TXT record, validated point-in-time at registration or on a continuous basis.

One example is Github Pages:

2. Add entropy to the record

During initial verification, you can generate a random string that is appended to the customer’s domain (in your application). So long as the string is of sufficient entropy and you implement reasonable rate limits on registration of a new custom domain, this will prevent an attacker successfully generating an identical random domain to allow the takeover.

For example: Heroku domains are of the format <app-name>-<random-identifier>.herokuapp.com. If you were to leave a subdomain (heroku.test.com) dangling, pointed at that domain, an attacker who claimed your defunct app-name would not be able to generate a Heroku domain with an identical random-identifier.

Heroku wrote up their approach in Security Improvement: Subdomain Reuse Mitigation

3. Don’t allow re-registration

Preventing re-use of a custom domain after it is first claimed is a strong blanket solution, with some product tradeoff. A compromise is to require interaction with support to re-register a previously used custom domain. In that case, ensure your support process is robust against social engineering for the purpose of subdomain takeovers.

4. Charge for custom domains

This is not a full preventative measure, but it’s true that if custom domains are locked behind a certain license tier, they tend to be exploited less frequently.

Cloud Service Providers have additional options

While researching this blog, I stumbled on Azure’s “Alias records”, which are an example of CSPs leveraging their end-to-end platform to offer secure defaults.

Azure Alias records tie the lifecycle of a DNS record with an Azure resource, so that when the resource is deleted the record is nulled out.

Currently, these records only support:

• Azure Front Door
• Traffic Manager profiles
• Azure Content Delivery Network (CDN) endpoints
• Public IPs

Platforms owe their users safety-by-default

While there are options for consumers to mitigate the risks of subdomain takeovers, it shouldn’t be a distributed responsibility.

Truffle Security recently shared a case study in which they reported susceptibility to subdomain takeover to a SaaS provider. That provider did not take the report seriously as a security issue. Truffle found this made over 600 companies potentially vulnerable, and were able to takeover those domains and report the issue to all the impacted companies. Because of one company’s failure to implement any of the aforementioned controls, hundreds of companies were vulnerable.

We should do better.