Subdomain takeover vulnerabilities occur when a subdomain (subdomain.example.com) is pointing to a service (e.g. GitHub pages, Heroku, etc.) that has been removed or deleted.
This allows an attacker to set up a page on the service that was being used and point their page to that subdomain.
For example, if subdomain.example.com was pointing to a GitHub page and the user decided to delete their GitHub page, an attacker can now create a GitHub page, add a CNAME file containing subdomain.example.com, and claim subdomain.example.com.
Safely Demonstrating A Subdomain Takeover
Based on personal experience, claiming the subdomain discreetly and serving a harmless file on a hidden page is usually enough to demonstrate the security vulnerability. Do not serve content on the index page. A good proof of concept could consist of an HTML comment served via a random path:
$ cat aelfjj1or81uegj9ea8z31zro.html
<!– PoC by username –>
Please be advised that this depends on what bug bounty program you are targeting. When in doubt, please refer to the bug bounty program’s security policy and/or request clarifications from the team behind the program.
You can submit new services here: https://github.com/EdOverflow/can-i-take-over-xyz/issues/new?template=new-entry.md.
A list of services that can be checked (although check for duplicates against this list first) can be found here: https://github.com/EdOverflow/can-i-take-over-xyz/issues/26.
|Akamai||Not vulnerable||Issue #13|
|Campaign Monitor||Vulnerable||‘Trying to access your account?’||Support Page|
|Cargo Collective||Vulnerable||Cargo Support Page|
|Cloudfront||Not vulnerable||ViewerCertificateException||Issue #29||Domain Security on Amazon CloudFront|
|Desk||Not vulnerable||Issue #9|
|Fastly||Edge case||Issue #22|
|Freshdesk||Not vulnerable||Freshdesk Support Page|
|Github||Vulnerable||Issue #37Issue #68|
|Gitlab||Not vulnerable||HackerOne #312118|
|Google Cloud Storage||Not vulnerable|
|Help Juice||Vulnerable||Help Juice Support Page|
|Help Scout||Vulnerable||HelpScout Docs|
|Heroku||Edge case||Issue #38|
|Intercom||Vulnerable||Issue #69||Help center|
|JetBrains||Vulnerable||YouTrack InCloud Help Page|
|Mashery||Edge Case||HackerOne #275714, Issue #14|
|Microsoft Azure||Vulnerable||Issue #35|
|Netlify||Edge Case||Issue #40|
|Shopify||Edge Case||Issue #32, Issue #46||Medium Article|
|Statuspage||Vulnerable||Visiting the subdomain will redirect users to https://www.statuspage.io.||PR #105||Statuspage documentation|
|Tilda||Edge Case||PR #20|
|Unbounce||Not vulnerable||Issue #11|
|Webflow||Not Vulnerable||Issue #44||forum webflow|
|WP Engine||Not vulnerable|
|Zendesk||Not Vulnerable||Issue #23||Zendesk Support|
The authors of this document take no responsibility for correctness. This project is merely here to help guide security researchers towards determining whether something is vulnerable or not, but does not guarantee accuracy. This project heavily relies on contributions from the public; therefore, proving that something is vulnerable is the security researcher and bug bounty program’s sole discretion. On top of that, it is worth noting that some bug bounty programs may accept dangling DNS record reports without requiring proof of compromise.