Every hacker has their favourite bug type. For me it is Subdomain Takeover, STO for short. In my 3 years of experience in bug bounties, the biggest reward was for an STO; at the same time it was the easiest money too: after identifying the vulnerable subdomain it was a matter of 10-15 minutes to exploit it and build a PoC.
Now you might be thinking (as I did too, being a novice hacker at the time): hm, if I find one of these each month I will be making a living by working 15 minutes a month! Patience young padawan. As always, it is not that simple. First of all, what is a Subdomain Takeover anyway?
~$ whatis STO
No, don’t run this on your terminal, there’s no man page for it :P . In simple words an STO occurs when an attacker gains control of a subdomain of a target domain. This means that, until the attack is spotted, the attacker can host content on, say, forgottensub1-prod.example.com, even though they ’re not the ones that have registered example.com. They would also be able to read star scoped cookies, eg cookies with a scope of *.example.com. They can also, potentialy, bypass CSP protections and perfome cross-site-scripting attacks. At the very least they can perform easy phishing attacks, tricking even security-aware users. If you use example.com and receive an email or visit a link, you will most likely trust it if the domain is the familiar example.com. It might even have the little padlock we tell users to look for, if there’s an SSL cert for *.example.com in place. Phishing couldn’t be more EZ.
How does it happen though
Look at the image on top of this article for the answer: it’s DNS (as always). The most common type of STO is a CNAME-based STO. What happens usually is that the company wants to use a third party service, so they add a CNAME record on the subdomain, pointing to the third party who offers said service. This was the case in the first STO I ever found. A third party, let’s call them awesomesearch.com offered a search functionality for their customers, back when google was just starting out and we were using altavista, lycos and yahoo search (damn, I am getting old). The company in question was a customer and used a subdomain like awesome.example.com that was pointing to example.awesomesearch.com. Years and years went by, awesomesearch.com stopped offering a search service as it became obsolete and they changed their domain to awesomesystems.com. The folks over at example though didn’t remove the CNAME record on awesome.example.com. That’s when I found the subdomain by running dig awesome.example.com (you can also use host awesome.example.com for the same purpose). I then searched awesomesearch.com on my domain registrar and it was availiable. I spent ~$6 and now it was mine. I pointed it to a server I owned, created
the subdomain example.awesomesearch.com and now awesome.example.com was pointing to my server. I hosted a simple html file to prove the takeover and also demonstrated, by browsing the subdomain and taking a screenshot of Firefox Developer Tools, that I could read cookies from example.com. So basically, the impact was XSS and account takeover just by a user visting the subdomain.
The dangers of living in the clouds
This case though is pretty rare. In this day and age, most companies opt for a cloud-based infrastructure. Especially large multinational companies (which the ones that have bug bounty programs typically are) prefer this approach as it saves on maintenance and sysadmin costs while making it easy to spin up subdomains and machines, whether it is to try something, test something, or any other reason, to teach something to a new employee for example. In computing though, moreso on complex systems, no solution is perfect. While a cloud-based infrastructure is convenient, it gave rise to a plethora of STO cases. A common one, and the one I was talking about in the first paragraph is an Amazon S3 bucket takeover. The most common occurence is based on the same prinicple. Company points a subdomain to an S3 bucket (eg subdomain.example.com pointing to subdomain.example.s3.amazonaws.com), company deletes bucket, company forgets to remove the CNAME record. Now an attacker can just create a bucket with the same name (subdomain.example) and takeover the subdomain.
Amazon S3 bucket service, however, is not the only case . A plethora of third party services can be taken over in one way or another. As the techniques became more widely known, the companies offering these types of services put in place warnings or mitigations. Amazon for example has scary messages now to make you aware that by deleting a bucket someone else can claim it. Other services, like heroku, give you a randomised CNAME that you have to add to your DNS records. Moreover, a few great hackers have focused on this type of vulnerabilty and automated the whole process, operating a fleet of machines dedicated to scan specifically for subdomain takeovers on their list of targets, claim the service and even write the report. Any hacker who is looking for STO will surely, at some time, visit a subdomain and see another hacker “greeting him” with something like “Subdomain Takeover PoC by @rhinestonecowboy” (that’s me, if you see this, send me a message and say Hi!). At the same time that companies put mitigations in place, hackers find new techniques or edge cases on services that were thought to be safe. The STO space is very fluid. One peculiar case is Amazon EC2 Takeovers.
The Amazon EC2 case
EC2 stands for Elastic Compute Cloud. It’s basically a vps in the Amazon Cloud. The instance gets an IP adress from the amazon ip pool when it is created. By terminating the instance, the IP gets released and re-enters the IP pool, ready to be given out to someone else. If you don’t remove the DNS record, the new IP resolves to the new customer who gets it and they accidentaly take over your subdomain.
Note that there’s a key difference: Here you don’t use a CNAME record to point your subdomain to your EC2 instance (although that can be done too this is similar to what I have already discussed). You use an A record pointing the instance’s IP, same as you would do with any vps or a self-hosted server on a machine with a static IP. As an attacker, you can identify if an IP belongs to an Amazon EC2 instance. However there’s no indicator in the DNS records as to what that IP hosts. How do you determine if the EC2 instance has a dangling record?
One thing you can do is simply visit the IP in a web browser. If the new Amazon customer hosts their own content the vulnerability is obvious and can be demonstrated by pressing one key on your keyboard: PrintScreen :D. The first time I came across an EC2 takeover, a news/media organization had a subdomain pointing to an IP which I visited and was greeted by a cute DIY site of a car dealership in Arkanso. Another thing to check is SSL cerificates: if the new customer has set DNS records you will see an SSL cert issued to a totally differnet organization than your target. There’s more to identifying this type of issue but I’ll stop here.
The issue with the PoC || GTFO argument, as regards to EC2 takeovers
Is this a takeover though? One can argue that it isn’t. After all we didn’t take over the subdomain; someone else did with no malicious intent. There’s a saying in the bug bounty space: PoC || GTFO, meaning provide a Proof Of Concept OR Get Out Of Here (yeah the acronym doesn’t match but i want to keep this blog family-friendly: hackers can be vile creatures, especially in their sense of humour).
Actually, we could try to take over the IP for real, but only if it hasn’t been issued yet. If it has (like in the car dealership example) we have to wait for them to release it (if they ever do). Still it is extremely cost-intensive and we need to be lucky.
What we can do in a nutshell is to programatically start and stop our own EC2 instance. Each time it will be issued a new IP. Eventually we might get the right one (given no one else takes it in the meantime) and takeover the subdomain. Anyone who uses aws or any other cloud computing instance can understand that this gets really expensive really quick. A reward for a Subdomain Takeover varys on the program and the impact we can achieve with it (for example if we can steal cookies or not) but it is usually considered Medium-High on HackerOne. This usually means 3 digits after the $ sign. The average bug bounty hunter is a member of the working class and most likely can’t afford to invest that kind of money in hopes of perhaps getting a triple digit bounty. They will most likely turn to looking for other issues. That’s not the case for a malicious actor though. If someone is after a particular company, for any reason it might be, they might have the funds or they might have hijacked someone else’s account and use their funds. That’s why, in my opinion, the PoC || GTFO mantra should be discarded in cases like this. This would incentivice ethical hackers to look for these types of issues and find vulnerable subdomains before a black hat does.
That is just my opinion though. What do companies think? Well, it varies. If you look at the picture above, which shows some instances of this issue I reported, you will see little circles on the left of the titles. If you ’re not familliar with hackerone, the green circle means the bug was triaged and resolved (and I got paid for it). The gray circle means that it was closed as Informative. This causes no harm to the hacker’s “score” but there is no reward.
In conclusion, my advice to hackers is to report this issues if you happen to bump on them: it takes little time and effort to report and you might get paid. You will only lose the time it takes you to write the report. However, I don’t think the effort to actively look for them is worth your time. My advice to companies running bug bounty programs is to accept these types of reports. That way all the awesome hackers on your bug bounty program, who more often than not know your infrastructure better than your employees do, will actively hunt for them and everyone will benefit from this.
So you wanna hunt for STO?
Be prepared for a lot of false positives. Be prepared to find subdomains that look vulnerable only to find out the automation master (and wholesome human) that is todayisnew (or some other hacker) has already taken them over. Bookmark the amazing resource Can I Take Over XYZ? by Ed Overflow and the community that contributed to it for a reference (some stuff in it are outdated but it is a great starting point for research). Read evrything by 0xpatrik who has done amazing research on the topic. Familiarise yourself with different services and how they work, create your own vulnerable suddomains and take them over from yourself. Don’t stop trying because you ’ve read somewhere that X can’t be taken over: test it out yourself instead. It might be an edge case, or you might find a way to do it that no one thought of. Even if you don’t succeed you will gain great knowledge and insight. Automate as much as you can but remember that while computers are great for some stuff there are other stuff that only a set of human eyes can see. And finally, as the SLIME REPL (google this if you don’t know what it is) tells me from time to time when I open it: