Subdomain Takeover: Ignore This Vulnerability at Your Peril

The Domain Name System (DNS) is often described as the address book of the Internet; A and AAAA records map a human-friendly hostname (e.g., honeybadger.io) to some machine-friendly IP address (104.198.14.52, in this case). Other types of DNS records also exist; in particular, CNAME records are records that map a hostname to some other hostname, thereby delegating IP resolution to the latter.

Unsurprisingly, DNS is not immune to misconfiguration, and poor DNS hygiene opens the door to all kinds of abuse that can wreak havoc on the security of your organization and its stakeholders. Of course, if attackers gain access to your DNS configuration and are able to create records or modify existing ones,

That's it, man! Game over, man! Game over!

However, attackers don't need such a strong foothold in your system to cause harm. In some cases, a dangling CNAME record on one of your subdomains is all they need to take control of some (or all) of the content served by the subdomain in question. Such a security issue is known as a subdomain takeover.

In this post, I will do the following:

• show you how subdomain takeovers typically arise,
• explain why this type of security issue should be on your radar,
• delve into how an attacker may use a subdomain takeover against you,
• provide some guidance for protecting yourself against vulnerabilities of this kind.

A Typical Scenario

To fix ideas, let's go over a typical subdomain-takeover scenario. Let's assume that your organization, ExampleDotOrg, whose domain name is example.org, wants to use some service from a vendor called TipTop.

A typical subdomain-takeover scenario

1. You register an account at TipTop and create an instance of their service, which is accessible at example-dot-org.tiptopapp.com.
2. For brand-consistency reasons, your organization would like to make your TipTop instance accessible from one of its subdomains: tiptop.example.org. No problem, as TipTop allows you to do that. All you have to do is create a CNAME record that points tiptop.example.org to example-dot-org.tiptopapp.com.
3. After a while, your organization decides to cancel its TipTop subscription. Your TipTop instance is then deleted but, crucially, you forget to remove the associated CNAME record!
4. An attacker later notices the dangling CNAME record. Because TipTop doesn't prevent anyone from reclaiming the example-dot-org instance name on their platform, the attacker is able to create his or her own TipTop instance at example-dot-org.tiptopapp.com, which your subdomain tiptop.example.org now points to! From then on, and for as long as the CNAME record remains, the attacker has control over the content served by your subdomain.

You've just fallen victim to a subdomain takeover!

Why You Should Pay Attention

Subdomain takeover was pioneered by ethical hacker Frans Rosén and popularized by Detectify in a seminal blogpost as early as 2014. However, it remains an underestimated (or outright overlooked) and widespread vulnerability. The rise of cloud solutions certainly hasn't helped curb the spread.

In many ways, subdomain takeover is an insidious security issue:

• Finding out whether a subdomain takeover is possible and taking control of the subdomain typically require remarkably few technical skills from the attacker.
• Detecting that a subdomain takeover is being actively exploited is difficult; you may realize it too late, when your users start complaining.
• A subdomain takeover may pose a relatively minor threat in itself, but when combined with other seemingly minor security misconfigurations, it may allow an attacker to cause greater damage.

Impact of a Subdomain Takeover

What harm could a subdomain takeover bring to your organization? Well, the impact mainly depends on three factors:

The nature of the third-party service (if any) that the vulnerable subdomain points to. Does the vendor offer little to no customization, or does it allow you to modify the style of the landing page via custom JavaScript or CSS code? Does it restrict you to serving static content, or is it a full-blown platform-as-a-service (PaaS) offering on which you can deploy a Web server?

The purpose and popularity of the vulnerable subdomain. What was the subdomain used for before becoming vulnerable? Was it used to simply host API documentation or was it instead used to authenticate users? Is the subdomain still receiving traffic? Is the subdomain name long and obscure (e.g., exctxzzxxp09.test.example.org) or short and simple and, thus, unlikely to raise suspicion (e.g., auth.example.org)?

The trust relationship that the organization's other Web assets have with the vulnerable subdomain. Would example.org blindly trust requests originating from the vulnerable subdomain? Would it accept to share sensitive data with that subdomain? Would it accept to load and execute JavaScript code hosted on that subdomain?

Now that you have a better idea of what factors into the impact of a subdomain takeover, let's see how a malicious actor might exploit one.

Defacement

If possible, an attacker may decide to change the appearance of pages served by the vulnerable example.org subdomain to openly ridicule or embarrass your organization. This is exactly what happened in February 2017, when a hacker took control of secure2.donaldjtrump.com, a subdomain of Donald Trump's campaign-fundraising website, and left there a message that... well... did not really fall in line with the Trump campaign's strategy.

Defacement of Trump's campaign fundraising site thanks to a subdomain takeover

Although the issue was quickly resolved, the offending page was captured and persists in the Internet Archive's Wayback Machine to this day. This incident arguably was neither the first nor the last cause for embarrassment for Trump, and it certainly did not prevent him from winning the 2016 presidency—as he was already in office at the time. However, I'm sure you can imagine how a defacement, possibly consisting of more offensive content than Trump's hacker used, could harm your organization's reputation.

Phishing

Another obvious way to exploit a subdomain vulnerable to takeover is phishing. Most phishing sites masquerading as a legitimate site (e.g., payments.example.org) usually do not survive close scrutiny of the browser's address bar because phishers typically have no other option than to host them on a lookalike domain (e.g., payments.exarnple.org). Not so with a subdomain takeover! In fact, a subdomain takeover is the perfect spot for running a phishing campaign. After all, if the domain name example.org is trustworthy, then one would assume that any subdomain of example.org is also trustworthy, right?

Thanks to a subdomain takeover, phishers can readily leverage the reputation of the legitimate domain name to lure unsuspecting victims to it and elicit sensitive information (e.g., account credentials, personally identifiable information, and payment details) from them. Even tech-savvy visitors are likely to fall for the subterfuge.

In some cases, attackers may even be able to obtain and install a valid TLS certificate for the vulnerable subdomain to serve their phishing site over HTTPS; and, sad to say, many people (including Europol representatives, who should know better), still view the use of HTTPS as a reliable indicator for trustworthiness of the server on the other end of the connection.

Stealing Broadly Scoped Cookies

Run-of-the-mill phishing typically requires some gullibility and user interaction (beyond navigating to the malicious site) from the victim. A subdomain takeover is more powerful, though, as it may enable an attacker to steal sensitive cookies simply by the victim visiting the attacker's site.

Cookies have a Domain attribute, which determines where browsers are allowed to send them in HTTP requests. For instance, if a cookie is set from example.org with that hostname as the value of its Domain attribute, browsers will attach it to all HTTP requests sent to example.org or any subdomain thereof. Some sites, in a questionnable approach to implementing Single-Sign-On (SSO) authentication across all of their subdomains, set the Domain attribute of their session-identifying cookies to their root domain (example.org).

Now picture a malicious actor who has taken control over a subdomain and deploys their own malicious server there, which is set up to log all HTTP requests. By luring authenticated users to the compromised subdomain, the attacker will be able to harvest cookies scoped at the root domain simply by inspecting the server logs!

Exploiting a subdomain takeover to steal sensitive cookies

If session-identifying cookies are scoped this way, the attacker will be able to hijack user sessions and, perhaps, even take over user accounts.

Note that security cookie attributes cannot protect users who happen to visit the compromised subdomain. In particular,

• the HttpOnly cookie attribute is irrelevant here because the attack involves no client-side JavaScript;
• under the assumption that the subdomain has a valid TLS certificate, the Secure cookie attribute cannot be of any help because browsers will send cookies to the compromised subdomain, even over HTTPS.

Cross-Site Request Forgery

OWASP defines cross-site request forgery as follows:

Cross-site request forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which [he or she is] currently authenticated.

Let's take a social network as an example. A CSRF attacker may perform sensitive actions, such as

• liking another user's post,
• updating the victim's email address, or
• changing the victim's profile picture,

all on behalf of the victim but against his or her will.

The SameSite cookie attribute was introduced to protect users against such cross-site attacks, but few organizations are taking full advantage of it. Thus, CSRF remains a risk wherever cookie-based authentication is used.

One possible mitigation against CSRF is to check the source origin of state-changing requests against a list of trusted origins. The Origin request header, when present, provides this information in a reliable fashion (more so than the Referer header does), because altering this header programmatically is simply not allowed by modern browsers. Many sites therefore rely on an origin-header check to decide whether to reject or accept a cross-site state-changing request.

Furthermore, a subset of these sites chooses to accept all requests originating from their subdomains. For instance, when api.example.org receives a request meant to update a user's email address, it may reject the request if the latter originated from somewhere like evil.org, but accept the request if the latter originated from example.org or any subdomain thereof.

If you guard your users against CSRF on the basis of an origin-header check but trust all subdomains of example.org, be mindful that a single subdomain of example.org vulnerable to takeover is enough to defeat this protection mechanism.

Exploiting a subdomain takeover to abuse a weak origin-header check and achieve a cross-site request forgery

Abusing Overtrusting CORS-Aware Servers

Malicious state-changing requests are not the only type of cross-site attacks you should be wary of, as attackers may also leverage cross-site requests to exfiltrate sensitive data. The same-origin policy (SOP), arguably the pillar of browser security, normally prevents such attacks.

However, cross-origin resource sharing (CORS) was introduced in HTML5 to allow developers to selectively lift some of the restrictions enforced by the SOP. For instance, to signal to the browser that another origin, such as https://jub0bs.com, is allowed to read responses to authenticated requests, api.example.org would respond with the following headers:

Access-Control-Allow-Origin: https://jub0bs.com
Access-Control-Allow-Credentials: true

Unfortunately, CORS is too often perceived as a nuisance by developers, who end up misconfiguring it without fully realizing the consequences. In this particular situation, if api.example.org were to be configured to treat any subdomain of example.org as a trusted origin for CORS purposes, a single subdomain takeover would be sufficient for the attacker to read and exfiltrate the contents of HTTP responses coming from api.example.org.

Exploiting a subdomain takeover to abuse a weak CORS configuration and exfiltrate sensitive user data

Defeating a Permissive Content Security Policy

Content security policy (CSP) is an important defense-in-depth mechanism that lets developers restrict where a given page is allowed to get framed or load resources (JavaScript, CSS, etc.) from. If example.org's CSP were to allow framing and/or loading resources from any of its subdomains, an attacker who would successfully mount a subdomain takeover would then be able to defeat the CSP and launch cross-site-scripting or clickjacking attacks against example.org.

Recommendations

Now that you're familiar with subdomain takeovers, here are a few things you can do to prevent them:

• Incorporate subdomain takeover into your threat model. Ask yourself what an attacker could achieve after taking over one of your subdomains. Fix seemingly unimportant misconfigurations, such as those mentioned above.
• Practice good DNS hygiene. Regularly audit your DNS records; don't let them gather dust or dangling records accumulate. Periodically make sure that you're still in control of everything your subdomains point to. Otherwise, immediately remove the corresponding CNAME record(s).

• Select vendors wisely. Heed the words of James Kettle (Director of Research at PortSwigger):

  Many companies have subdomains pointing to applications hosted by third parties with awful security practices.

  Don't be one of them. Treat every third-party service as you should any dependency: a liability. When shopping for a third-party solution that lets you point your subdomain to it, check whether the vendor protects its clients against subdomain takeover. Effective defense mechanisms include the following:

  • requiring clients to create a unique TXT record along with the CNAME record to prove that they're in control of their DNS settings;
  • enforcing sufficient entropy in instance names; or
  • disallowing clients from reclaiming instance names once used by another client.

• Close the attack window. Ethical hacker Edwin Foudil, in his can-i-take-over-xyz repository on GitHub, maintains a list of vendors that fail to protect their clients against subdomain takeover. If you decide to use any of these solutions, you have to be a bit more careful about the order in which you do things. Make sure to do the following:

  • point your subdomain to your instance only after creating the latter;
  • remove the corresponding CNAME record before deleting your instance.

  This will effectively close the window during which you're vulnerable to subdomain takeover.

Conclusion

I hope reading this post has raised your awareness of the risks associated with subdomain takeovers. Of course, this post only scratches the surface. Subdomain takeovers can be involved in other, more complex attacks. Moreover, some advanced forms of subdomain takeover involve DNS records other than CNAMEs.

If you would like to dig deeper, I recommend perusing Patrik Hudak's blog, which goes into much more detail about the mechanics and impacts of subdomain takeover than this post does. HackerOne's feed of disclosed bug-bounty reports is also an excellent resource on the topic.

Now, go audit your DNS records, be picky about vendors, and beware of subdomain takeovers!