We are living in extraordinary times. Global conflict has moved from peace time to war footing which is being enhanced by civilian armies of ‘pseudo authorised and encouraged’ cyber volunteers. In addition to this merger between civilian and military, the world is seeing a significant increase in hacktivism, based around a number of ideals, including motivations emanating from conflicts and indeed excuses, resulting in frequent impacts on business such as website defacement, data breaches and many other breakdowns in Confidentiality, Integrity and Availability of data. This report discusses one specific but frequently seen exploit, with an exploration of the attack methodology and a discussion of its potential impact.
Subdomain takeover
DNS Hijacking, dangling DNS, CNAME misconfigurations and subdomain takeovers (SDTO) are all names for a vulnerability in which an attacker can leverage redundant outbound CNAME records in order to control an asset that belongs to an organisation, and cause significant damage to both the company and clients.
In aims to reduce costs and streamline development and deployment, businesses have made rapid shifts toward using cloud infrastructure for hosting their operations. Services such as AWS, Azure, Heroku, Zendesk, Unbounce, Webflow and numerous smaller providers provide a convenient solution for storage, load balancing and hosting; with this, they also offer new attack surfaces and potential threats that were not previously present.
CNAME (Canonical name) records are DNS records which act as redirects. When a user tries to resolve “example.com”, as seen in the image below, instead of being given an IP in the form of an A record, it will fetch content from a different source, while still appearing to a browser as the original “example.com”. This is how these third-party cloud hosts operate: a company will set the CNAME to a resource owned by the host, typically in the form “xyz.domain.tld”, where xyz is a subdomain with a name chosen by the company when they configure the asset, “domain.tld” being the host’s domain; and when a browser tries to connect to the company site, the site will fetch the resource from the hosting service and provide it to the browser.
This situation becomes a vulnerability when the organisation stops paying for a subdomain and forgets to remove the CNAME record. For example, if blog.example.com points to companyblog123.tafficmanager.net (an azure load balancing service), and the company decides they are abandoning writing blogs, and thus stop paying Azure, Azure may allow anyone, including threat actors, to register “companyblog123.trafficmanager.net”. Now, if a victim visits blog.example.com, and the development team has not removed the CNAME record, the victim’s browser will fetch content from an attacker-controlled resource and display it under the name of blog.example.com.
Impacts of SDTO
Subdomain takeover has multifaceted exploit capabilities and is often used as a base to launch other attacks with high or critical severity.
The most common use for subdomain takeovers is the ability to host attacker-controlled content, masquerading under an official company site; with this, a threat actor can deploy highly effective bespoke phishing attacks imitating the victim site’s branding and page styling. For example, an attacker can display a login page, identical to one seen elsewhere on the company infrastructure, and then have the page send the entered credentials to an attacker-owned server. The harvested credentials can then be sold on or used to as a foothold to try to pivot into more company infrastructure.
It has also been observed in the past that the ability to host content has been used for defacement when a threat actor changes the page’s code with the aim to make their presence known by displaying inappropriate, offensive or just unexpected content. A known example of a subdomain takeover being used for defacement occurred in 2017 when secure2[.]donaldjtrump[.]com was exploited by “Pro_Mast3r” and deployed for political activism. Regardless of how an attacker chooses to exploit the ability to host content, the act of changing the appearance of a public asset is enough to cause brand damage and make clients question the security of the company.
Subdomain takeovers may be used in conjunction with previously benign server-side request forgery (SSRF) attacks to bypass whitelist-based string filters and exfiltrate AWS credentials and sensitive data or even achieve remote code execution. The best practice to mitigate SSRF is to create a whitelist of sites which can be accessed; for example, if the company owns domain.com and the whitelist is “*.domain.com” requests would only be validated if they met this filter criterion. A malicious request to http://169[.]254[.]169[.]254, an internal IP hosting AWS and Azure metadata services, would not be successful. However, an attacker who has performed a subdomain takeover can set up a redirect that fetches this internal service, so when domain.com tries to access “http://overTakenSubdomain[.]domain[.]com/?redirect=http://169[.]254[.]169[.]254” it will validate “overTakenSubdomain[.]domain[.]com”, as it is included in the whitelist of “*.domain.com”, then following redirects will fetch the internal resource or secrets, and return it to an attacker.
A subdomain takeover not only gives one the ability to control the files dictating the appearance of the site but also allows mandatory .js files to be served to visitors, and this becomes a stored cross-site scripting (XSS) vulnerability. XSS is a complex bug in its own right and has a host of capabilities, but the fact that it is executed on a subdomain gives it even more dangerous potential. Content Security Policy (CSP) is an added layer of protection, acting as a whitelist restricting the damage that a standard XSS can do. However, similarly to the SSRF prior, if the CSP filter is too broad, or encapsulated the vulnerable subdomain, an attacker can bypass the restrictions, which under the right circumstances can lead to stealing session cookies and achieving account takeover.
Lastly, subdomain takeovers can leak confidential data or personally identifiable information. Some assets are intended to be used by servers and automatic processes, not humans; these include content delivery networks (CDNs) or domains specialised in hosting APIs. If a subdomain is used as part of one of these services and then that functionality becomes deprecated, information and requests may still be sent to that asset; however, if an attacker now controls the subdomain, they will receive all incoming traffic, which can leak anything from emails to session tokens to API keys.
Mitigation
There are two ways in which subdomain takeovers can be prevented: from the provider’s side, and by having proper network visibility.
Subdomain takeovers are not the fault of hosting providers and occur when a company stops purchasing from the provider; thus, historically hosts have not had an interest in helping a non-paying former client. However, as hosting companies have evolved, they now offer protections regardless. This is done in the form of requiring a custom TXT DNS record as proof that someone is the proper controller of the nameserver, as well as the prior CNAME pointing to them. Because an attacker capitalises on an existing CNAME reference, rather than dictating it, they cannot pass this additional validation and thus cannot conduct a takeover.
Below is a real-world example of this. During a pentest we found a subdomain that pointed to highway-safetyoffice-egrants-system-pro[.]azurewebsites[.]net; azurewebsites is a hosting service owned by Microsoft. On visiting the page, the subdomain showed that the site was not being hosted.
After registering highway-safety-office-egrants-system-pro and uploading a proof of concept HTML page, visiting highway-safety-office-egrants-system-pro[.]azurewebsites[.]net would result in the following.
However, visiting the target domain itself resulted in a 404 page: this is because the CNAME does resolve to a live website. However, Azure, the provider, has taken extra measures to check the authority of the website owner.
Before Azure routes traffic from the target domain, it will check if the custom TXT record is set, and if not will block it. Below is the configuration page the attacker will see when trying to perform a subdomain takeover. As seen, they do not meet the “Domain ownership” requirement and thus are stopped.
The other method of mitigation is having proper network visibility and using this to remove redundant CNAME records. In order to maintain network visibility as infrastructure scales, it is important to remember edge cases, variations, services used and the types of subdomains that are commonly taken over.
Of the vulnerable subdomains in the reports, 57% of them were explicitly consumer-facing, and had intentions of providing user functionality. However, these were either never implemented or may have been available in the past but discontinued due to a change in business aims, possibly explaining why “blog” was the most common subdomain that was vulnerable, with 6 instances. Subdomains not intended for public use accounted for 27.1% of observed vulnerable subdomains; they often featured words or like “dev”, “stage” or “test”, which were stand-alone or used to alter existing subdomains with hyphens or dots, for example, “dev-admin” or “status.stage0”. It is important for developers to use secure measures when testing, even if the subdomain is deployed with the intentions of being temporary.
To our surprise, 56 different hosting providers were identified from the sample. Despite well-known providers such as AWS, Azure and Zendesk being the providers with most instances of vulnerable subdomains, it is important to appreciate that there is a significant amount of smaller, alternate providers that make up a large portion of the hosting. Even if your company uses only one hosting brand’s suite of services, it is worth researching how many endpoints need to be accounted for when removing CNAME records. For example, Microsoft Azure is one hosting provider, yet they have had 17 different domains that can be used to carry out subdomain takeovers, such as cloudapp.net, azureedge.net, blob.core.windows.net, etc
When auditing subdomains to secure an organisation from takeovers, it is important to remember variations of subdomains and edge cases. Companies may employ the use of subdomains when making the site language or region specific. For example, blog.fr.domain.com may have the site’s blog written in French, and blog.en.domain.com may display the text in English; if one of these is vulnerable to subdomain takeover, it is likely that the same misconfiguration is present in the other. Similarly, the same subdomain may be used under a different top-level domain, and administrators often forget to patch them for parallel domains. In 2019, mail.starbucks.com was not vulnerable to subdomain takeover; however, the Bulgarian version of Starbucks was. (source)
Conclusion
Despite recent preventative measures being implemented by some hosting providers, subdomain takeovers are still prevalent, being actively discovered and exploited. It is an unauthenticated remote vulnerability requiring relatively low sophistication, and the generic nature of discovery means finding these bugs can be automated by attackers and scaled with ease. This, combined with the high or potentially critical severity impact, highlights the importance of thorough network visibility and regular auditing to remove redundant CNAME records.