Subdomain Takeovers – CNAMEs And Cloud Services
A Subdomain takeover, you guessed it – refers to the hostile takeover of a subdomain by an attacker.
This vulnerability arises mainly when resources hosted on third-party hosting services/cloud providers are discontinued but the DNS records pointing to those cloud resources still remain.
Potential subdomain takeovers are a high-severity threat for organizations that frequently provision, and decommission resources, especially on cloud hosting service providers.
Subdomain takeovers can become a looming threat when an organization’s DNS record points to a currently non-existent or discontinued resource. Such DNS records are also known as “dangling DNS” or “stale DNS” entries. Commonly vulnerable to this threat are dangling CNAME records.
Common Scenario leading to subdomain takeover
- The domain name (e.g., greatapp.contoso.com) uses a CNAME record to another domain (e.g., greatapp.contoso.com CNAME great app.third-party.hosting).
- At some point in time, great app.third-party.hosting expires or is deprovisioned and is available for registration by anyone using the hosting service.
- Since the CNAME record is not deleted from the contoso.com DNS zone, anyone who is able to register greatapp.third-party.hosting has full control over greatapp.contoso.com until the CNAME record is present.
Note that HTTP redirects (301 or 302) could be also be used instead of CNAMEs to redirect from http://www.battlinjack.buzz to http://aws.battlinjack.buzz.s3-website.ap-south-1.amazonaws.com.
This method is less frequently used, as it will entirely replace the domain in the browser’s URL bar. CNAME records, on the other hand, do not change the domain in the URL bar of the browser as DNS resolution happens behind the scenes.
What’s in a CNAME?
A Canonical Name i.e. CNAME record is a category of DNS record that associates an alternate name to the canonical domain name.
The domain name (e.g., greatapp.contoso.com) uses a CNAME record to another domain (e.g., sub.example.com CNAME great app.third-party.hosting).
Hosted services commonly provision a subdomain for individual organizations on the hosting provider’s domain (e.g. organisation.hostname.com), and use a CNAME to point to the customer’s domain (www.organisation.com).
Looking up the CNAME of a subdomain
Tools like nslookup can be used to find out the CNAME for a specific subdomain (if it exists). The resulting output indicates the hosting provider that is in use.
In this case, the CNAME record for source subdomain aws.battlinjack.buzz points to a resource (aws.battlinjack.buzz.s3-website.ap-south-1.amazonaws.com) hosted on the AWS S3 bucket.
Is there a dangling DNS record (CNAME) for the subdomain?
Browsing to the source subdomain aws.battlinjack.buzz in this example, an error message thrown by the cloud service provider (AWS S3) stating that the bucket (resource) does not exist.
This is in fact a dangling DNS record, wherein a CNAME record pointing to the AWS S3 bucket (resource) exists, however, the resource (aws.battlinjack.buzz.s3-website.ap-south-1.amazonaws.com) is no longer available. A subdomain takeover is likely in this instance.
The exploitation of subdomain takeover differs based on the service provider which was used to host the presently non-existent resource that existed earlier.
Taking over an AWS S3 bucket
In the case of AWS S3, the subdomain identifying the unique cloud resource (bucket) used for website hosting is named in the format of bucket-name.s3-website.region-name.amazonaws.com.
The CNAME record of the source subdomainaws.battlinjack.buzz points to the resource aws.battlinjack.buzz.s3-website.ap-south-1.amazonaws.com. The part before “.s3” is the bucket name.
All the attacker needs to do for successful exploitation is to create a bucket with the name aws.battlinjack.buzz as the CNAME record for this subdomain already exists.
If the bucket is successfully created then voila! The subdomain takeover is complete.
Note: If the bucket name aws.battlinjack.buzz were already in use, AWS would give an error and exploitation could not be possible in this case.
Taking over a github pages website
GitHub provides free web hosting using their GitHub Pages project. This web hosting is usually used for project documentation, technical blogs, or supporting web pages to open-source projects. GitHub Pages supports custom domain names in addition to the default domain name undergithub.io.
The github page subdomain format for a user is like username.github.io
The CNAME record for a source subdomain hosted on github looks something like this.
Verifying whether the github pages site on github.battlinjack.buzz exists.
All the attacker needs to do for exploitation is to add the custom domain name github.battlinjack.buzz to their github pages repository battlinjack.github.io. Takeover complete!
Note: If the custom domain github.battlinjack.buzz were already in use, github would give an error and exploitation wouldn’t be possible in that case.
Side Note: GitHub uses virtual hosting like many cloud services and verifies the actual subdomain name based on the host header. So, if there were a dangling CNAME record for github.battlinjack.buzz pointing to anyhost.github.io then subdomain takeover would still be possible. This is because all github pages website subdomains point to the same server. Check out the image below.
Manually browsing to a given subdomain and analyzing the server response usually gives a good indication regarding the possibility of subdomain takeover.
However, for determining potentially vulnerable subdomains from a bulk of domains – tools like subjack are very useful. Subjack scans a list of subdomains concurrently and identifies the ones which are potentially vulnerable based on the fingerprints in its database.
The fingerprints are basically the error messages associated with the respective hosting/service providers when a non-existing or deprovisioned resource is requested.
Once an attacker takes over a legitimate domain name, it is very difficult for a normal user to figure out whether the content hosted on that domain is controlled by a legitimate party or an attacker.
Mass phishing or targeted phishing campaigns can be run by the attacker, asking users to log in to and harvest credentials on the legitimate subdomain under their control. The probability of successful phishing attacks amplifies with control over legitimate domains.
If the base domain (e.g.contoso.com) of the hijacked subdomain (greatapp.contoso.com) shares cookies across all its subdomains (*.contoso.com) then cookie stealing is another possibility.
In the best-case scenario, a subdomain takeover leads to a loss of trust in the brand or organization.
The remediation steps for domain names vulnerable to subdomain takeover are simple enough:
- Remove the dangling DNS entry — The easiest way is to remove the stale record from the DNS zone. If the organization concludes that the affected source domain name is no longer needed, this step solves the issue.
- Take control of the domain name— This means registering the resource in the cloud hosting provider or in the case of a normal internet domain, rebuying the expired domain.
If you would like to delve deeper into this topic, here are a few resources I recommend:
- https://github.com/EdOverflow/can-i-take-over-xyz – This community-driven repository maintains a list of vulnerable services and how-to steps for claiming subdomains with dangling DNS records on these services.
- https://0xpatrik.com/ – Super rich info involving subdomain discovery, enumeration, takeover, you name it!
Attack & Pen Test Team
Varutra Consulting Pvt. Ltd.