How I found my first Subdomain Takeover vulnerability

Finding your very first vulnerability as a newbie security researcher can be really intimidating and can easily burn you out especially when you don’t know where to start from. Read on to know how I managed to find a Subdomain Takeover vulnerability and how I was able to leverage that into a CSRF attack with the ability to takeover the victim’s account

Report- Subdomain Takeover + CSRF

Scope: Other/ Subdomain Takeover

Program: Private

Platform: Intigriti

Payout: €375

Date Resolved: 06/07/2021

Severity: High

The first step involved in the Recon was enumerating all the subdomains within the master domain under the scope, you always want to check if the program allows a wildcard domain name, only then subdomain takeovers are treated as a valid report, for example a program should contain .example.com. That being said a few programs may still accept your submission, so always do try your luck with it.

Subfinder is the tool I use to enumerate all the subdomains of a target, it gives out consistent results, if you prefer an online tool instead try out Virustotal or Spyse. The scan sent back 175 enumerated subdomains. It was now time to scan these subdomains to check which ones sent back a 404 response which would mean that those subdomains are potentially exploitable. I use Medic or HTTPStatus

Doing so returned 12 subdomains out of the 175. It was now time to check which of these subdomains were vulnerable to a Subdomain Takeover. For this, I visited each subdomain and inspected the error messages returned by each attached service, 404 pages tell the tale of this attack, use the repository maintained by Ed from Live Overflow which is called “Can I Take Over XYZ” which has a list of 3rd party services with their corresponding error messages and if they are vulnerable or not : https://github.com/EdOverflow/can-i-take-over-xyz

Before seeing the list you need to first verify if the said subdomain has any CNAME records which are pointing to a dead 3rd party service page. In my case explore.*********.com was pointing to a Netlify DNS server as seen below

Netlify had fixed their issues of Subdomain Takeovers a while ago, which means they now would verify your ownership to the website and netlify site names would automatically append a random number to their fronts to make them unique. But in this case, there were no unique numbers and I was able to create a new Netlify site and attach this subdomain to my Netlify site and voila! My content was now being served on explore.*********.com :

Some things to remember while creating a PoC for Subdomain Takeover:

- Never serve the PoC on the index of the subdomain, always hide the PoC into a unguessable file name, for example in this case i used ```oc-2bdg3erf2i6td.html```

- No login page, never try to recreate the company’ login page as a Poc, you will be in trouble

- No funny business, keep the PoC message minimal, no memes/Gifs

We had now taken over this subdomain, whats next? If you had to go and report this right away to the company, there are high chances your report will be marked as a Low severity due to lack of loss of any kind of confidentiality, instead you now you think like the attacker, about how would an attacker leverage this to his benefit and takeover your account?

CORS is the easiest way through which the attacker can now do CSRF (Cross Site Request Forgery) attacks. What does this mean? CORS is web mechanism by which you prevent unauthorized websites from sending requests on behalf of the victim to the website and steal info/change data. In this particular case , the CORS header for the program’s host had a subdomain wildcard ```*.programhost.com``` What does this mean? This means that this website has allowed Cross Site requests from any of its subdomains and allowed full access to its resources.

So, now the question boils down to, how will the attacker use this? The attacker will now recreate the company’s login page, lure in the victims, let them login using credentials, and then make a request to the login endpoint of the application (Thanks to the CORS policies) and then steal away all the cookies the server sends back (No cookies for you :p ), steal your credit card info, do anything that you would do as an user and in return the attacker may now even send back a malware/script, cheers to the immense power the hacker now holds.

This was verified by sending a request to one of the endpoints of the main host and in turn I got back the header:

access-control-allow-origin: https://explore.******.com

This now confirms that the main host has allowed this request to pass through.

1. Representing company in various wrong ways

2. XSS Attacks

3. Authentication Bypass

4. Phishing/ Spear Phishing