An exploration of a critical bug which is a waking nightmare for large companies on one hand and a goldmine for the bug bounty hunter on the other.
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!
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, 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.
So, what makes a subdomain vulnerable to takeover?
event.vulnerable-site.comu-faqs.event.vulnerable-site.com.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.faqs.event.vulnerable-site.com which is still pointing to github pages.u-faqs.event.vulnerable-site.com as shown here.
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.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">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>This can prove to be more fatal if the anchor tag is used without rel="noopener noreferer" attribute.
1if (window.opener) {
2 opener.location = 'https://malicious-attackerdomain.com/x';
3}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.rel=noopener for any target=_blank link]To find subdomain takeover vulnerabilities in an organisation, you need to start off by gathering all the subdomains.
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
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:
#!/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
The impact of subdomain takeover depends on many factors such as:
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.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.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.
- **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.
- **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.
- **Scope Analysis:** Keep an up-to-date list of the organisation's subdomains at all time and apply the monitoring process to them.
- **Automated Tools:** Leverage automated tools like Subjack, SubOver, or security scanners that specialize in detecting subdomain takeover vulnerabilities.
- **Awareness Programs:** Educate developers about the risks associated with subdomain takeovers and the importance of proper configuration and removal of unused subdomains.
- **Cookie Security:** Implement SSO using secure alternatives like SAML or OAuth instead of shared session.