Subdomain Takeovers – CNAMEs And Cloud Services
Introduction A Subdomain Takeovers
A hostile takeover of a subdomain by an attacker is known as a subdomain takeover. This issue mostly arises when organizations are integrating with either third-party hosting services or cloud service providers. The DNS records referring to these service providers remain while they have stopped their services. Subdomain takeovers are considered to be an acute threat to an organization that regularly activates and deactivates resources that depend on cloud computing service providers. It is an emerging threat especially when an organization’s DNS record points are discontinued or non-existent. These DNS records are referred to as dangling DNS or stale DNS. Dangling CNAME records are quite vulnerable to these threats.
Common Scenario leading to subdomain takeovers
- The CNAME record is used by domain names like greatapp.contoso.com for a different domain. Example: greatapp.contoso.com CNAME great app.third-party.hosting.
- Due to any circumstances, when domain name (great app.third-party.hosting) expires, then it will be available to others for registration by the hosting service providers.
- As the CNAME record does not get deleted from the hosting website i.e., costono.com, anyone can easily register for your previous selected domain name (great app.third-party.hosting).
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.
It is a method that is not used so frequently. It replaces the domain name from the browser’s URL bar while the CNAME record will not change the domain in the URL bar of your browser as DNS resolution takes place in the backend.
What’s in a CNAME?
CNAME or Canonical Name is a category in DNS record that means alternate name to canonical domain name. For example, a CNAME record is used by domain name (greatapp.contoso.com) for a different domain (sub.example.com CNAME great app.third-party.hosting).
Hosting service providers assign a particular subdomain for the organization on the hosting provider’s domain. It is represented as organizationname.hostname.com. It is followed by a CNAME to redirect towards the customer’s domain, i.e., www.organizationname.com.
Looking up the CNAME of a subdomain
Various tools and applications are available on internet to look for a CNAME if it is available. You can use nlookup to find out whether a CNAME for a particular subdomain exists or not. The result will indicate that is the hosting provider is in use or not. In this case, you can see that the CNAME record for source domain (aws.battlinjack.buzz) is directed to the resource (aws.battlinjack.buzz.s3-website.ap-south-1.amazonaws.com) which is hosted on the AWS S3 bucket.
Is there a dangling DNS record (CNAME) for the subdomain?
In the example here, while browsing aws.battlinjack.buzz (source subdomain), you can see an error message getting displayed by the AWS S3 (cloud service provider). This message means that the resource (bucket) does not exist.
It is a dangling DNS record issue. It means the CNAME record is directed towards the AWS S3 bucket (resource), however, aws.battlinjack.buzz.s3-website.ap-south-1.amazonaws.com (resource) no longer exists. This instance is a scenario for subdomain takeover.
Exploitation of Subdomain takeovers
The exploitation of subdomain takeover is different as the service provider that was earlier present and used to host the current resource (non-existing) that was existing in the earlier case.
Taking over an AWS S3 bucket
Here in AWS S3, the website hosting format for subdomain identifying the unique cloud resource (bucket) is bucket-name.s3-website.region-name.amazonaws.com. The CNAME record aws.battlinjack.buzz (source subdomain) redirects to aws.battlinjack.buzz.s3-website.ap-south-1.amazonaws.com (resource). The part before “.s3” is known as the bucket name. To carry out a successful attack, the hacker only needs to create a bucket with the name aws.battlinjack.buzz. It is done as there is already a CNAME record for this subdomain.
This subdomain take-over is complete if the bucket is successfully created.
Note: In case when aws.battlinjack.buzz (bucket name) is already in existence then AWS will show an error and exploitation will not be possible.
Taking over a github pages website
GitHub is mostly used for technical blogs, project documentation, or assisting in webpages for open-source projects as it provides free web hosting services using their GitHub Pages. It will assist the default domain name as well as a custom domain name that is registered in github.io. The subdomain format for the GitHub page for a user is username.github.io.
The appearance of the CNAME record for a source subdomain that is hosted on GitHub.
Verifying the existence of GitHub pages site on github.battlinjack.buzz.
In exploitation, to complete the take-over a hacker needs to insert the custom domain name (github.battlinjack.buzz) into their GitHub pages repository (battlinjack.github.io).
Note:
- In case, github.battlinjack.buzz (custom domain) already exists, you will receive an error message from github, and exploitation will not take place.
- Like many cloud service providers, GitHub also uses virtual and verifies the actual subdomain name based on the host header. If there is a case of dangling CNAME record for github.battlinjack.buzz directing to anyhost.github.io, then a subdomain takeover is possible. It is possible as all GitHub pages website subdomains share a common server.
Subjack
Browsing a subdomain manually and analyzing its server response is a good indication regarding the possibility of subdomain takeover. However, the subjack tool is very useful to find a potentially vulnerable subdomain from bulk domains. It can simultaneously scan a list of subdomains and identify those who are vulnerable depending upon their fingerprints in the database.
The fingerprints are the error messages associated with the respective hosting service providers when there is a request for a non-existing or deprovisioned resource.
Implications
If a hacker uses an authorized domain name, then it will a difficult situation for a normal user to figure out whether the content hosted on the website is controlled by a legitimate user or the hacker. When an attacker runs targeted phishing or mass phishing campaigns, they generally ask the users to log into their subdomain-controlled website so that they can acquire their login credentials. It can be said that the probability of a successful phishing attack can be amplified by taking control over legitimate domains.
There is also a possibility of cookie stealing when a base domain (e.g.contoso.com) of the hijacked subdomain (greatapp.contoso.com) shares cookies across all its subdomains (*.contoso.com). An organization or a brand can lose its credibility due to a subdomain takeover.
Remediation to Vulnerable Subdomain Takeover
Follow the steps to prevent your domain names from becoming vulnerable to subdomain takeover:
- Removal of the dangling DNS entry — The simplest way is by removing all the stale records from the DNS zone. This step will resolve the issue for an organization that has affected the source domain name.
- Taking control of domain name — In simple words, it means repurchasing the expired domain or registering the resource again to the cloud hosting provider or in the case of a normal internet domain.
Further reading
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!
Author,
Akshay Khilari
Attack & Pen Test Team
Varutra Consulting Pvt. Ltd.
