I participate in a lot of bug bounty programs, where I try to automate the discovery of as many security issues as possible. Many companies do not know all of the assets that they have on the internet. When you know their attack surface better than them, you can find a lot of otherwise trivial issues.
One of the easiest types of issues to automatically discover are subdomain takeovers, where a DNS record or a load balancer points traffic towards an unknowing third party. If
testing.example.com is pointed towards Amazon S3, what will S3 do if that bucket hasn't been created yet? It will just throw a 404 error — and wait for someone to claim it.
If we claim this domain inside S3 before
Knowing this, I was very surprised to see hundreds of alerts from my automation in a few minutes — all claiming to have successfully captured S3 buckets for root domains belonging to major companies. Thinking I had broken it and it had gone off the rails, I quickly took a look and noticed that it had indeed worked, and my content was being served on a ton of domains with bug bounty programs.
A lot of buckets
At this point I had no idea what to do — why were there so many impacted domains across many organizations, and how was I even going to submit all of these issues? However, I noticed that the domains were slowly being changed to a MarkMonitor parked domain page.
It became clear that these were all parked domains with varying degrees of use, and they were all registered via MarkMonitor. This is a bit surprising, because MarkMonitor sells themselves as the domain registrar that does not make mistakes. It would be hard to understate the cost of losing domains for a tech company — anything that is pointed to them will immediately begin directing their traffic elsewhere. MarkMonitor is not a cheap solution to this problem, but it is widely used (apparently by "more than half of the Fortune 100", per the page).
I sent a few bug bounty reports to companies that were most impacted by this issue, but these domains were in an indeterminate state and it was hard to prove there was an issue. While many domains began responding with an S3 404, others began switching from S3 to the parked page. What is interesting is that DNS was not involved — all domains pointed to
220.127.116.11 both before and after the issue.
After I sent an email to
firstname.lastname@example.org that went unacknowledged, domains stopped pointing to S3 over an hour after it began. I claimed over 800 root domains in this timeframe, and other researchers had similar amounts of claimed domains.
Many companies — including MarkMonitor themselves — do not run a vulnerability disclosure or bug bounty program, so they are not included in my scanning and would not have been detected. Luckily, since all of these domains use a static IP address, we can see exactly how many domains on the internet were pointed to the vulnerable service.
SecurityTrails offers a simple SQL browser we can use to look for all of these domains. In total, it identified over 62,000 domains pointed to MarkMonitor's parking service.
Some amazing entries are in here, including
coinbase.ca. Suffice to say, these would have been great targets for phishing.
Even though this only lasted for an hour, this is enough to perform impactful attacks like claiming a TLS certificate for the entire domain. It could then be MiTM'd in the future if, for example, Coinbase began operating in Canada.
Preventing this from happening
MarkMonitor does not have a way of disclosing security issues, which inhibited reporting this to them in a timely manner. They have not responded to any of our communications.
This issue is not entirely the fault of MarkMonitor. While they need to be careful with handling parked domains, AWS is at fault for not being more stringent with claiming S3 buckets. Google Cloud, for example, has required domain verification for years, rendering this useless.