Mastering the Art of Subdomain Takeover: Tips, Tricks and Profits

Hello Hackers! My name is Bhavarth Karmarkar and in this blog post, we are going to look at some of the techniques and mitigation of Subdomain Takeover. We start by first understanding what is subdomain takeover, it's impact and how an organisation can secure itself from this attack. Let us jump right in then!

Browser Transparency

Have you ever visited a website with a domain name like shop.site.com and it just turns out to be hosted on shopify's cloud platform. But instead of the default XXX.myshopify.com, it is a subdomain of the company's primary domain. This is a classic scenario of Browser Transparency where a CNAME record pointing to the original subdomain: XXX.myshopify.com, has been setup in the DNS zone file of the organisation. This allows for the content to be served from the subdomain of the cloud hosting provider while allowing the customers to view the website from the subdomain of the company. This allows for the company to maintain it's branding. A visual representation of this can be seen in the image below:

Subdomain Takeover

Subdomain takeover, as the name suggests, is an attack which enables the attacker to Takeover the subdomain of an organization. This means that the attacker now owns the subdomain and controls the content served from that subdomain. For example: Imagine that facebook is vulnerable to subdomain takeover, and a subdomain renew.accounts-v1.facebook.com has been taken over by a malicious attacker. This means that if you will visit this subdomain, the content of the site will be controlled by the attacker. The attacker will usually place a login form to trick you into signing in and the credentials will be sent to the attacker's server instead. And if the page is high up in SEO ranking, then a lot of traffic will fall prey to this advanced phishing attempt.

Attack Scenario

So, what makes a subdomain vulnerable to takeover?

1. Suppose that a company organizes an event for a short time, with a url event.vulnerable-site.com
2. The Company also creates an faq page related to this event at u-faqs.event.vulnerable-site.com.
3. The event.vulnerable-site.com subdomain is hosted on the company's cloud whereas the u-faqs.event.vulnerable-site.com is hosted on github pages.
4. Now the event gets over at a certain point in time,and the Github hosting plan is expired, but the company forgets to remove the DNS zone record for the subdomain faqs.event.vulnerable-site.com which is still pointing to github pages.
5. Now whenever we visit the site, it gives a generic "There isn't a GitHub Pages site here." message.
6. An attacker can now create his own repository and set it's domain name to u-faqs.event.vulnerable-site.com as shown here. This attack utilizes stale DNS entries pointing to Service Providers where the subdomain, which is pointed to, is currently not in use. Depending on the DNS-entry configuration and which Service Provider it points to, some of these services will allow unverified users to claim these subdomains as their own. An attack scenario can be seen in the following image: Here the CNAME record for the subdomain greatapp.contoso.com is pointing to an Azure resource app-contogreat-dev-001.azurewebsites.net which is no longer owned by the company, but now an attacker can easily create another resource on azurewebsites.net with the same name. And all the traffic from greatapp.contoso.com will be routed to the now, attacker-controlled domain.

Second - Order Subdomain Takeover

This method is also referred to as broken link hijacking and it occurs when a resource used by the website is not longer owned by the intended party and is available to be claimed by the public. One such scenario can be a website using a javascript code from a third party subdomain which is vulnerable to takeover. This allows for the hacker who now has the control of the domain, to inject malicious javascript code and steal cookies and other personal information.

```javascript
<script src="doesnot-exist.tpdomain.com"></script>
```

If the website serves images or stylesheets from a third party subdomain, then it can lead to the defacement of that website, if the third party subdomain falls into the hands of a malicious attacker.

1<img src="doesnot-exist.tpdomain.com"></img>
2<link rel="stylesheet" type="text/css" href="doesnot-exist.tpdomain.com">
3

Another scenario will be if an anchor tag on the webpage provides link to a vulnerable subdomain which can be used as a form of phishing attack depending on the context the link is used in by the website.

1<a href="doesnot-exist.tpdomain.com"></a>
2

This can prove to be more fatal if the anchor tag is used without rel="noopener noreferer" attribute.

• rel="noopener": This is used to prevent the newly opened tab from tampering with the tab which opened. This means that the newly opened page, which is hypothetically in the attacker's control, can change the location of the tab which opened it and can be used for phishing.

  1if (window.opener) {
  2    opener.location = 'https://malicious-attackerdomain.com/x';
  3}
  4

• rel="noreferer": This directive simply disables the Referer header from being sent to the website on the link. This is useful as the referer header can sometimes contain sensitive information like the object IDs and session tokens. [NOTE: Most modern Browsers now implicitly set rel=noopener for any target=_blank link] To find Second-Order Subdomain Takeover:
• Use a crawler to scrape all the pages on a site.
• Grep for script and anchor tags and parse out their source.
• Now use the same techniques as described above to find subdomain takeover in any of the third party domains.

Detection and Automation

1. To find subdomain takeover vulnerabilities in an organisation, you need to start off by gathering all the subdomains.

2. After we have enumerated all the subdomains, we can run a dns recon on all the subdomains to check if any of the domains contains a CNAME record. $ dnsrecon -d domain.com

3. And finally we can run the dig command on the CNAME records obtained to check for any of the following $ dig anothersub.domain.com

DNS errors worth investigating:

• NXDOMAIN: The queried domain does not exist in the DNS.
• SERVFAIL: The DNS server encountered an internal error or couldn't fulfill the request.
• REFUSED: The DNS server is refusing to respond to the query.
• No servers could be reached: Unable to connect to any DNS servers, indicating a potential network or configuration issue.

#!/bin/sh
while read line; do
echo "Sublist3r"
python3 sublist3r.py -d $line -o $line.txt
echo "Assetfinder"
assetfinder --subs-only $line | tee -a $line.txt
sort -u $line.txt -o $line.txt
done < scope.txt

Now we can use various tools like subjack or SubOver subjack -w subdomains.txt -t 100 -timeout 30 -o results.txt -ssl SubOver -l subdomains.txt These tools can provide different results so always cross check using this wonderful website by EdOverflow. Another interesting tool to discover subdomain takover is aquatone which can take screenshots of all the subdomains and let's you manually verify your findings. Along with the screenshots, the tool also saves the report in a well constructed HTML format which you can conveniently view in a web browser

Impact

The impact of subdomain takeover depends on many factors such as:

• The type of domain which is vulnerable (CNAME,NS or MX)
• The SEO ranking of the page
• How critical in nature the subdomain was.
• If the subdomain belongs to the target organisation or a third party organisation. With that being said, let us look at the impact of takeover of the different types of domain:
• CNAME : A CNAME domain takeover can be of a third level or fifth level subdomain which will reduce the impact of the takeover. For Eg. Takeover of a subdomain like support.organisation.com is potentially more harmful than the takeover of a subdomain staging-001.api.v1.support.organisation.com (you get the point!), since the chances of support.organisation.com of showing up in a google search for organisation.com are far more compared to the latter. An attacker can thus host malicious content under the legitimacy of the organisation's domain name.
• MX : Performing a simple dig MX some.website.com will reveal it's mail servers (Eg: ns-1527.awsdns-62.org). An MX record helps your Mail Transfer Agent to query where to send the email. What this means is that any email sent to @some.website.com will land up on a server which you have hosted. An MX record cannot point to a CNAME record and must directly point to an A record, so only if the base domain name of the record is available, will you be able to takeover the MX server.
• NS: It is a DNS record that stores the nameservers for a particular domain. If an attacker is able to take over the base domain of an NS entry, he can return any DNS response when your site is requested, and redirect the user anywhere she pleases.

Critical Subdomains

Imagine a scenario where an organisation implements SSO or Single Sign On. In single sign on, the users acquire a set of credentials and then this credential can be used to authenticate and authorize with any part of the organisation. There are three ways in which SSO can be implemented by any organisation.

• Cookie based: After logging in, some cookies get set in the browser of the user and is shared across every subdomain.

  Set-Cookie: cookie=abc123; Domain=facebook.com; Secure; HttpOnly
  

  This cookie will be shared across all the subdomains of facebook.com such as accounts.facebook.com or messenger.facebook.com etc.

• SAML: This involves allowing access to Service Providers after verifying the authorization and credentials using a trusted Identity Provider. The Service Provider trusts the Identity Provider and grants access to the service.

• OAuth: This involves presenting scope based access and an access Token obtained from an identity provider which allows the user to log in without requiring a password. Now suppose that a SSO enabled subdomain was vulnerable to a subdomain takeover. The SSO was implemented using cookie-sharing across the subdomains, this would allow the attacker to obtain the SSO cookie of anyone who ends up on the vulnerable subdomain. As a result, the attacker can potentially take over the user's entire account by using the SSO cookie on other subdomains of the organisation.

Mitigations

Regular Monitoring and Removal:

-   **Active Monitoring:** Regularly monitor the DNS records and subdomains for any changes or anomalies. This can be done using automated tools that alert you to any modifications.
-   **Timely Removal:** Remove DNS records for subdomains that are no longer in use or have been deprecated. This includes subdomains pointing to external services that are no longer under your control. 

Proper Configuration:

-   **CNAME Records:** Ensure that CNAME records are configured properly and only point to valid and active services. Remove CNAME records that are no longer necessary.
-   **MX Records:** For MX records, ensure that they point directly to A records and not CNAME records. This reduces the risk of an attacker taking over email services.

Subdomain Knowledge:

-   **Scope Analysis:** Keep an up-to-date list of the organisation's subdomains at all time and apply the monitoring process to them.

Subdomain Takeover Detection Tools:

-   **Automated Tools:** Leverage automated tools like Subjack, SubOver, or security scanners that specialize in detecting subdomain takeover vulnerabilities.

Educate Developers:

-   **Awareness Programs:** Educate developers about the risks associated with subdomain takeovers and the importance of proper configuration and removal of unused subdomains.

SSO Considerations:

-   **Cookie Security:** Implement SSO using secure alternatives like SAML or OAuth instead of shared session.