The Domain Name System (DNS) is often described as the address book of the Internet.
A and AAAA records map a human-friendly hostname like honeybadger.io
to some machine-friendly IP address like 104.198.14.52
. 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 record 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 can create records or modify existing ones, you'll have a huge problem!
A subdomain takeover is an interesting attack in which a dangling CNAME record is exploited to take control of content served on a subdomain, potentially inserting malicious content. Attackers don't need too strong a foothold in your system to cause harm.
In this post, you'll learn:
- How subdomain takeovers typically arise
- Why this type of security issue should be on your radar
- How an attacker may use a subdomain takeover against you
- Some guidance for protecting yourself against vulnerabilities of this kind
A Typical Scenario
To get oriented around the problem, let's walk through 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
- You register an account at TipTop and create an instance of their service,
which is accessible at
example-dot-org.tiptopapp.com
. - 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 the custom domaintiptop.example.org
toexample-dot-org.tiptopapp.com
. - 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!
- 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 can create his or her own TipTop instance atexample-dot-org.tiptopapp.com
, which your subdomaintiptop.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 care about subdomain hijacking
The subdomain takeover was pioneered by ethical hacker Frans Rosén and popularized by Detectify in a seminal blog post 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, but when combined with other seemingly minor security misconfigurations, it may allow an attacker to cause greater damage.
How bad is a subdomain attack?
What harm could a subdomain takeover bring to your organization? Well, the impact mainly depends on three factors:
The third-party service for the vulnerable subdomain
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 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 the organization has in the vulnerable subdomain
Would example.org
blindly trust requests originating from the vulnerable subdomain? Would it share sensitive data with that subdomain? Would it load and execute JavaScript code hosted on that subdomain?
Exploiting a subdomain takeover
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 embarrassing for Trump. However, I'm sure you can imagine how a defacement, possibly consisting of more malicious content than Trump's hacker used, could seriously harm your organization's reputation.
Phishing
Another obvious way to exploit a subdomain vulnerable to takeover is phishing. Most phishing sites masquerading as legitimate sites (e.g., payments.example.org
) usually do not survive the 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 attack.
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 still view the use of HTTPS as a reliable indicator of 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 questionable 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 they are 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,
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 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 from where a given page is allowed to get framed or load resources (JavaScript, CSS, etc.).
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 for avoiding subdomain attacks
Now that you're familiar with these sorts of attacks, here are a few things you can do to prevent subdomain takeovers:
Incorporate subdomain takeovers into your threat model
Ask yourself what an attacker could achieve after taking over one of your subdomains. Fix seemingly unimportant misconfigured subdomain, such as those mentioned above, to prevent subdomain takeovers.
Practice good DNS hygiene
Regularly audit your DNS records. Don't let a DNS record gather dust and don't let dangling records accumulate. Periodically validate you're still in control of everything your subdomains point to. Otherwise, immediately remove the corresponding CNAME DNS record.
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 DNS entry to prove that they're in control of their DNS record settings
- Enforcing sufficient entropy in instance names
- Disallowing clients from reclaiming instance names once used by another client
Close the attack window.
Ethical hacker Edwin Foudil 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 DNS record before deleting your instance.
This will effectively close the window during which you're vulnerable to subdomain takeover.
Protecting yourself from a subdomain takeover
While this post only scratches the surface of subdomain takeovers, I hope reading it has raised your awareness of the risks associated with this kind of attack. 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.
Now, go audit your DNS records, protect your domain ownership, be picky about vendors, and beware of subdomain takeovers!