Well, via a responsible disclosure, we proactively performed a Subdomain Takeover on a vulnerable subdomain of USA.gov (see the proof).
A subdomain takeover is considered a high severity threat and boils down to the registration of a domain by somebody else (with bad intentions) in order to gain control over one or more (sub)domains. - Sweepatic Blog
Through our reconnaissance platform, we are able to create visibility in large dynamic digital footprints around the world and hunt for all kind of threats including active subdomain takeovers. When monitoring the USA.gov domain we discovered a significant security gap which enabled us to take over their subdomain. Of course, we proactively secured it against threat actors and, through coordination by the National CSIRT in the US, we helped to make USA.gov aware of this vulnerability.
In this blog post, we explain what exactly happened and how you can protect your organization from those very Subdomain Takeovers.
So what happened to USA.gov? In June 2017, our reconnaissance platform alerted us on a suspicious subdomain api.usa.gov.
After an inspection by one of our Sweepatic hunters, we found that the HTTP request to api.usa.gov resulted in HTTP code 404 (Not Found) on GitHub Pages.
As shown on the screenshot below, the api.usa.gov points to CNAME record api-usa-gov.domains.api.data.gov which in turn has A records pointing to AWS servers. The idea was probably to redirect the traffic for api.usa.gov over AWS servers to one of GitHub Pages' websites.
Unfortunately, the subdomain was not registered in the GitHub Pages anymore. It is a pretty unusual setup because it is possible to use CNAME records directly in order to achieve the same behaviour. Therefore, the domain api.usa.gov could have been registered by any attacker who in return would have full control over one of the USA.gov subdomains.
What are the dangers?
A vulnerable subdomain like this presents many options to an attacker. It is perfect to setup an infrastructure to fuel several attacks e.g.
- Phishing / Spear phishing
- Malware distribution
- Cross-site scripting (XSS)
- “Man-in-the-browser” attacks
- Brand / reputational damage
This makes it clear: an active, hostile subdomain takeover represents and is considered a high risk.
How to repair the domain?
In order to mitigate a subdomain takeover, you first need to create the visibility over all your DNS records and hunt for dangling CNAME records. This can be tedious hence you need to rely on automation. Once discovered, the remediation of the subdomain is simple, either you remove the subdomain from your DNS records or you point the subdomain elsewhere.
If you're passionately curious, our blog post on the principles of a Subdomain Takeover will explain the topic in more detail.
After we discovered (and proactively remediated) the security issue in the digital footprint of one of the US-based government organizations, we submitted a responsible disclosure through the Incident Reporting System support system of the National CSIRT in the US at the end of June 2017. After followup with our contactperson, they then coordinated the responsible disclosure to USA.gov, who secured their subdomain at the end of August 2017.
We believe this to be a prime example of the collaboration between the private and public sector in reporting security issues, denying opportunities for bad actors. Through several responsible disclosures, we were able to communicate and coordinate similar security issues to closure before any harm was done.
We hope this responsible disclosure is perceived as a positive message and an example on our ongoing research and collaboration in making organizations around the world more safe.