Subdomain Takeover Exploit: Turning a Dangling CNAME Into Parent-Domain Cookie Control

Subdomain takeovers are well documented, but most guides cover the same providers, like AWS and Azure, and follow a repeatable playbook. When the dangling record points to an undocumented service, proving impact means learning that provider’s features better than the playbook does.

How Dangling CNAME Records Create Subdomain Takeovers

For the most part, subdomain takeovers refer to a dangling subdomain DNS record pointing to a third-party asset, which has either been decommissioned from the target’s infrastructure, or was planned for release and not deployed at all. Below is an example pseudo-scheme:

Since explaining different DNS variations and types of takeovers is beyond the scope of this article, the presented technique focuses on a CNAME record pointing to a third-party portal.

The Initial Takeover: Claiming the Third-Party Portal Behind the CNAME

Subdomain takeovers are trivial for the most part and essentially occur when an attacker claims the asset, hosts a web page and proves that any session-related data would be propagated through the client’s infrastructure. In this case, the initial finding reported was just the claimable resource pointing to the third-party portal, which had the following layout:

As the screenshot shows, it’s a CNAME record on the target’s domain, pointing to a third-party resource, which could be reclaimed by an attacker. The portal has an option to point the resource back to an arbitrary domain, completing the trust chain and enabling the domain to be accessible via the subdomain.target.com subdomain.

The initial triage response, however, set a higher bar for impact: “The attack here is assessed to be an Unclaimed Domain in Use. This is due to the impact being very much like an unregistered domain. …If you are able to show us that further attacks are possible, please let us know and we can evaluate the suitability of the higher category.”

While the client’s domain pointing to a third-party resource now reclaimed by Synack was shown, no sufficient security impact has been demonstrated at this point to meet Synack’s criteria under the Subdomain Takeover vulnerability category, except that an attacker could host arbitrary text content under the portal’s layout, and the page could be rendered under the client’s domain.

Escalating Impact With Custom JavaScript and Parent-Domain Cookies

Instead of stepping back, I spent more time on subdomain takeover research and then went through the portal’s features in detail. What looked like a static page with no control over its source actually allowed custom CSS and HTML header/footer code. In addition to that, the portal also delivered what’s usually most useful to an attacker for client-side attacks (especially in cases where HTML sections are filtered/sanitized), JavaScript.

In addition to other techniques demonstrated in my report, which fall beyond the scope of this article, the following reference provided the strongest supporting argument for proving security impact, and demonstrated how the vulnerability affects all of the parent domain’s subdomains:

“A cookie’s domain attribute determines which domains can access the cookie. Browsers will automatically submit the cookie in requests to in-scope domains, and those domains will also be able to access the cookie via JavaScript. If a cookie is scoped to a parent domain, then that cookie will be accessible by the parent domain and also by any other subdomains of the parent domain. If the cookie contains sensitive data (such as a session token) then this data may be accessible by less trusted or less secure applications residing at those domains, leading to a security compromise.”

By default, cookies are host-only and are not sent to subdomains unless a Domain attribute is specified. Historically, some browsers, including older versions of IE/Edge, deviated from this behavior and could send cookies without an explicit Domain attribute to subdomains. Without a Domain attribute, modern browsers limit a cookie to the exact host that set it. Setting the Domain attribute to the parent domain, as in the code below, widens that scope to the parent and every one of its subdomains.

By using the following code, the impact was non-ambiguous, strictly defined and of high CVSS score:

document.cookie="username=Synack;domain=.target.TLD";

With just one line of code, it was demonstrated that complete control of cookies and session data was achieved, not just over the target subdomain and apex/root domain. The above code snippet would affect any neighbour subdomain structure similar to sub.target.TLD or inner.sub.target.TLD. While the specific demonstrated attack path applies to cookies without the HttpOnly attribute set, there are alternative routes to exploitation, which fall beyond the scope of this article.

This allows an attacker to gain complete control over adding, modifying or manipulating any cookie data set programmatically, which could affect authentication and/or authorization endpoints across the target’s infrastructure, leading to compromise of sensitive data and discovery of additional attack surface through alternative attack techniques.

Subdomain Takeover Mitigation: DNS Hygiene and Cookie Scoping

Countering subdomain takeovers involves good DNS hygiene:

• If the subdomains are no longer needed, the CNAME record should be removed
• If a resource pointing to a subdomain is intended for future use but is not currently used, reclaim the subdomain for legitimate use
• An internal audit should be done in order to discover any additional CNAME DNS records that could facilitate other subdomain takeovers
• Continuous monitoring and periodic checks are recommended as best practice

Key Takeaways

• Don’t stop at what public write-ups document. Enumerate the provider’s features to find the highest real impact
• While exploitation of some vulnerabilities might occasionally be straightforward, others require you to put some OOB thinking into it
• Keep investigating how the identified weakness could interact with the surrounding infrastructure and whether it can be combined with other conditions to demonstrate a greater impact

Conclusion

No public write-up covered this provider. The finding came from focused research into how to clearly demonstrate the risk in an impactful manner, without leaving room for argument.

While subdomain takeovers are for the most part easy to fix and do not require much technical involvement to prevent, mitigation requires strict observation and monitoring, especially across broadly scoped infrastructures where changes are often applied, and details are easy to miss.

Thanks for reading. To learn more about the global community of researchers uncovering vulnerabilities like this, check out the Synack Red Team and apply today. Be sure to follow Synack and the Synack Red Team on LinkedIn for upcoming blogs in the Exploits Explained series.