Finding Candidates for Subdomain Takeovers
A subdomain takeover occurs when a subdomain (like example.jarv.is) points to a shared hosting account that is abandoned by its owner, leaving the endpoint available to claim for yourself.
Not only are takeovers a fun way to dip your toes into penetration testing, but they can also be incredibly lucrative thanks to bug bounty programs on services like HackerOne and Bugcrowd, where corporations pay pentesters for their discoveries.
For a deep dive on the implications of takeovers, which can be a pretty serious vector of attack for malicious actors to obtain information from users of the targeted company, Patrik Hudak wrote a great post here. Definitely take some time to skim through it and come back here when you're ready to hunt for a potential takeover yourself.
The most common services eligible for takeovers of abandoned subdomains are the following:
- Amazon S3
Amazon CloudFront(no longer vulnerable?)- Microsoft Azure
- Heroku
- GitHub Pages
- Fastly
- Pantheon.io
- Shopify
- Tumblr
- ...and many more.
On my GitHub profile, you'll find a Go-based tool named subtake (based on subjack).
This tool takes a list of CNAME records to check and outputs potential takeover candidates pointing to these services. But how in the world do we get a list of every CNAME on the internet?
Conveniently, Rapid7 publishes a monthly list for us through their Project Sonar survey!
Project Sonar is a security research project by Rapid7 that conducts internet-wide surveys across different services and protocols to gain insights into global exposure to common vulnerabilities. The data collected is available to the public in an effort to enable security research.
One of their free monthly datasets is called Forward DNS, where you'll find .json files named xxxx-fdns_cname.json.gz. Within the subtake repository, there's an automated script named sonar.sh, which downloads the dataset for you and outputs a simple text file of CNAMEs pointed to any of the services listed above. Once you've cloned the subtake repository and grabbed the timestamp part of the filename (the string that precedes -fdns_cname.json.gz), usage of the script is as follows:
./sonar.sh 2019-03-30-1553989414 sonar_output.txt
This new text file contains both active and abandoned subdomains pointing to any of the services listed above — we still need to narrow it down to the takeover candidates by attempting to actually resolve each of them, which is where subtake comes into play. To install subtake, make sure Go is installed first and run the following:
go get github.com/jakejarvis/subtake
For a detailed description of the different options you can play around with, see the full readme on GitHub — but here's a simple example command that uses 50 threads to take the CNAMEs listed in sonar_output.txt and outputs potentially vulnerable subdomains to vulnerable.txt.
subtake -f sonar_output.txt -c fingerprints.json -t 50 -ssl -a -o vulnerable.txt
This could take quite a while — up to a day, depending on your CPU, memory, and bandwidth — so I usually run it on a VM in the cloud and use Linux's screen command to keep it running and check in periodically. There will also be many unavoidable false positives that you'll need to check yourself by trying to claim the abandoned name on the corresponding service's portal, which is why I keep using the term potential takeovers.
I also have a collection of root domains of companies offering bounties through HackerOne or Bugcrowd at a different GitHub repository. Using the grep-friendly text file, it's easy to use grep to narrow down your vulnerable.txt list even more:
grep -f grep.txt vulnerable.txt
In my view, takeovers are a fantastic way to begin a side hustle in bug bounties, simply due to the fact that once you've taken over a subdomain, you don't need to worry about another hunter beating you to the punch and reporting it before you.
Since you have this luxury of time, it becomes extremely important that you let your adrenaline subside and follow responsible disclosure guidelines — especially in the creation of a "proof of concept" file with your username at an obscure location, not at index.html. I won't go over the details of writing a report because Patrik Hudak wrote another great post about it here. This is an example of one of my own reports (company name censored because it has not been publicly disclosed) on Bugcrowd:
I have found three subdomains of ********.com vulnerable to takeovers via unclaimed endpoints at Azure's Traffic Manager. I have claimed these endpoints and redirected them to a blank page to prevent a bad actor from doing so in the meantime, and hosted a POC file at obscure URLs. These are the following domains I discovered and the outdated endpoints on Azure to which they point:
xxxx.********.com --> aaa.trafficmanager.net
yyyy.********.com --> bbb.trafficmanager.net
zzzz.********.com --> ccc.trafficmanager.net
...and the proof-of-concept files are at the following locations:
http://xxxx.********.com/poc-d4ca9e8ceb.html
http://yyyy.********.com/poc-d4ca9e8ceb.html
http://zzzz.********.com/poc-d4ca9e8ceb.html
I have not hosted any other file nor attempted any other vector of attack. You're probably familiar with takeovers like this by now, but through this vulnerability, it would be possible for an attacker to obtain cookies and other sensitive information from your users via phishing, cookie hijacking, or XSS. It is also possible to obtain SSL certificates for ********.com subdomains from CAs that only require domain validation such as Let's Encrypt, but I have not attempted to do so. More info on possible attack vectors can be found here.
Please let me know when you've received this report and I'll delete the endpoints from my personal Azure account, so you can either reclaim them or remove the subdomains entirely from your DNS records. Thanks!
I removed the company's name because an important part of responsible disclosure is the disclosure, or lack thereof. Until the company explicitly gives permission to publicly disclose the vulnerability after patching it — and there are built-in features on both HackerOne and Bugcrowd to request this — it's not okay to talk about it publicly.
The poc-d4ca9e8ceb.html proof-of-concept file contained this single, hidden line:
|
|
No self-promotional links or redirects, no examples of XSS/cookie hijacking to be "helpful" (no matter how harmless), no funny business of any kind.
I have several more improvements I want to make to subtake (like integrating the sonar.sh script into the main Go executable, polishing the all-in-one automated Docker image, a self-updating list of service fingerprints, etc.) but still feel free to make a suggestion and/or contribute to the repository in the meantime.
Happy hunting, fellow penetrators! 😉