How we dodged a Subdomain Takeover Bullet

A white hat security researcher recently brought an unused subdomain pointing to an AWS IP address to our attention.
While in this case the attacker’s intentions were good, the incident serves as a clear reminder of the potential dangers lurking in forgotten corners of your online presence.

The well intentioned hacker demonstrated that they were able to host their own content on a specific subdomain of ours, indexing their results in the Internet Archive (Wayback machine), proving they were able to “takeover” the subdomain before respectfully removing the exploit (and presumably moving on).

How this particular attack (probably) worked.

In our case, the unused subdomain was pointing at an AWS Ip address for EC2.
As far as I am aware, it is not possible to request a specific IP address from AWS, so I suspect, we were caught in a dragnet-like approach that I imagine was automated similarly to this:

Create an EC2 machine, with nginx or similar configured to serve a splash screen to any http visitor regardless of the domain they request.
Get the IP address of your machine.
Perform a reverse lookup to see what (sub)domains are associated with an IP address. For a simple example try using MxToolBox - though a well prepared a hacker would presumably have access to much more comprehensive and detailed lists/databases.
If a match is found, you should now be serving your splash screen via their domain. Either exploit it for malicious purposes, or notify the owner for a bounty.
Get a new IP address and carry on enumerating.

A similar dragnet like attack could of course be used for various clouds or hosting providers.

How this could have been exploited.

While we just received a rather polite, informative email, presumably in expectation of a reward, the consequences could have been much worse.
The suggested exploit in the email was session hijacking: accessing the cookies for the root domain, potentially enabling the attacker to impersonate legitimate users with other systems hosted on the domain.
But there are some difficulties for the attacker to overcome here, the cookies would need to be insecurely configured, allowing access from non-https connections and being available to all subdomains. On top of this, the attacker still faces the challenge of directing logged in users to the subdomain in the first place.

A two pronged attack

Whilst on its own, the exploit is difficult to take advantage of, when coupled with an exploitable legitimate domain, it could easily be used for an XSS attack, or session hijacking.

Even without another easily exploitable domain though, the exploit could be used for phishing.
Recently we had a number of LinkedIn users contacting us, claiming they’d been given offers of employment, had done “test” work in advance - in some cases they’d even apparently paid fees.
This job scam had it’s own portal, which cloned our corporate branding - had it also been hosted on our corporate domain, using this subdomain attack, it would have been much more convincing, (though it would have still lacked SSL). It may even have become a legal issue, as it would have been being served via a domain we control.

Mitigating the risks

Conducting regular audits of your DNS records, and removing any stale records is an obvious way to prevent subdomain takeovers.
Combine this with proper access control to your DNS records, monitoring and reporting on changes to records, and a good configuration by restricting the use of wildcard records and setting a low TTL (to ensure changes propagate quickly) to reduce the risk of subdomain takeovers.

Couple the above with a good policy for monitoring the use of third party services (like github pages) and ensuring good security practices in application development, for example secure HTTP responses, headers and cookies.

And finally have a plan in place to implement if a subdomain takeover does occur. Although the solution is simple (change/remove the effected records), it’s important to be able to judge the radius of the potential damage, and reflect upon how it occurred, and what steps can be taken to prevent it in future.

Conclusion

Our experience seems to have been random, requiring the chance designation of an AWS IP address, but more targeted exploits are also common.
Dangling DNS records often point to named resources (for example github pages, netlify apps or S3 buckets) and a wide variety of tools exist to enable hackers to look for these unused records. Once one is found, the attacker simply has to recreate the named resource for the takeover to be complete.

To make matters worse, phishing attacks hosted on a genuine corporate domain could become a legal nightmare - visitors could be forgiven for believing they were genuine, and the domain owner may potentially be responsible for their losses.

Tidying up DNS records isn’t fun, especially if the knowledge of who created them and why has been lost in the sands of time, but it is absolutely essential to keep your records clean and up to date.

Whilst we received nothing more than a polite email, the potential for abuse is high, offering both an entryway for unauthorized system access, and an opportunity to hijack and potentially damage your brand.

To learn more about subdomain hijacking, particularly targeted approaches, Can I take over XYZ?” provides a list of resources to learn more.