What Are Subdomain Takeovers, How to Test and Avoid Them?

Introduction

Hostile Subdomain takeovers consist of a class of attacks. These attacks have appeared quite frequent in large organizations due to the increased number of factors, like human negligence and an attack surface. A similar sort of attack is called stale DNS entries, which often leads to the hijacking of the domain itself. This has already happened a number of times to companies like Starbucks and Uber, which has already paid thousands of dollars for these security vulnerabilities reported by researchers. Uber actually had more than one subdomain takeovers in the past. This often leads to companies losing the trust of their users and various other implications due to the loss of millions of dollars. When a successful subdomain takeover is maliciously executed, an attacker puts up a successful phishing campaign. In this article, I will discuss practical use cases, impact, and mitigation of this attack to share useful tips on how to avoid such situations.

Servers for DNS monitoring can become a bit tedious for organizations with a large number of assets. However, DNS monitoring can be automated with in-house solutions as well as paid ones to avoid manually checking that you don't leave stale DNS entries (CNAME records).

What Are Subdomain Takeovers?

Subdomain takeover vulnerabilities occur when a subdomain is pointing to a service (e.g. GitHub pages, Heroku, etc.) that has been removed or deleted. This allows an attacker to set up a page on the service that was being used and point their page to that subdomain. For example, if subdomain.example.com was pointing to a GitHub page and the user decided to delete their GitHub page, an attacker can now create a GitHub page, add a CNAME file containing subdomain.example.com, and claim subdomain.example.com.

Not only can this happen with your company's GitHub hosted pages but also with Amazon S3 buckets, which are no longer in use but a subdomain is still pointing at it.

As an attacker can make use of this stale DNS record to own the AWS S3 bucket or point to one's own GitHub pages to your (sub)domain, there is no longer a use by your organization. Therefore, it can be used to target innocent users, leaking their account details via XSS and phishing pages hosted on your companies' domains.

In many cases, an attacker can easily steal a victim user's cookies via XSS if they are allowed on the subdomain, so that needs even less user interaction than usual phishing pages, which are set up to steal user credentials.

Some Notable Cases of Subdomain Takeovers

Below are companies that have been victim to this attack in the past:

1. Slack through podcasts.slack-core.com, which was serving content via Feedpress.
2. US Government via GitHub pages
3. GitLab
4. Uber, which lead to an account takeover
5. Unbounced contained many different pages/domains belonging to different companies

And, many more...

Mitigation

As an end user of a service, going through your organization's DNS records in a routine manner or while discontinuing or terminating a service will safely remove it's DNS records.

As a service provider, implementing stricter methods will prove (sub) domain ownership.

Testing for Subdomain Takeovers

Below, we take a look at the heuristic testing methodology to determine subdomain takeovers.

Heuristic Tests to Determine if a Sub-Domain/Domain Can Be Taken Over