How Does a Subdomain Takeover Work?
Many cloud services, when you deploy a service, will give you the option of assigning the service a fully qualified domain name (FQDN). For example, Azure services will be hosted under *.azurewebsites.net. I could choose for my service to be accessible through uksouth-app01-coolservice.azurewebsites.net. However, I don’t want my customers or employees to access the service through this FQDN, so I also create a CNAME (alias) record with the subdomain “coolservice.example.com”.
Now my customers can access my service through “coolservice.example.com”, without needing to remember the long and uninteresting azurewebsites.net subdomain. Sounds great so far, except, a little bit in the future, I decide to delete my virtual machine or rename it to something else, but forget to remove my CNAME record for “coolservice.example.com”.
An attacker stumbles across this and decides to create their own virtual machine on Azure and assigns it the same FQDN I used of “uksouth-app01-coolservice.azurewebsites.net”. Now, my subdomain “coolservice.example.com” points to the attacker’s virtual machine, rather than a resource.
An important thing to keep in mind is that this is not unique to Azure. Any cloud service, Software-as-a-service, etc. may be vulnerable if you assign CNAME records to point to it.
The Impact of Subdomain Takeovers
Phishing
Phishing is a massive threat to organisations, some of the largest data breaches occur due to social engineering. If an attacker was able to host a malicious login page on internalservice.example.com, even a well-informed employee may enter their credentials. After all, if their email is on outlook.example.com and their file storage is on ftp.example.com, how could internalservice.example.com be malicious?
An attacker, using a subdomain takeover attack, does not need to use slightly off domain names (e.g. internalservice-example.com) or homoglyph attacks (e.g. eχample.com), but can instead masquerade as one of example.com’s legitimate services hosted on their subdomain.
Furthermore, some password managers may automatically fill credentials into the page (because of the trusted relationship of subdomains), meaning an attacker may be able to steal credentials just through having an employee load the page in their browser.
Cookie Theft & Browser Protection Bypasses
When setting cookies (the information that websites can store on your computer to identify who you are), they are usually only sent to the same origin that set them (e.g. a cookie set on internalservice.example.com will only be sent back when accessing internalservice.example.com). However, cookies can be configured to be sent to all subdomains of the origin site too. For example, example.com could set a cookie that will be sent to example.com, internalservice.example.com, dev.internalservice.example.com, etc.
Why is this a problem? Well, if an attacker now has control of internalservice.example.com, they now have access to any cookies set on the example.com domain. Those stolen cookies might give access to other internal services, without ever needing to phish the user into giving their username and passwords.
Subdomains takeovers might also give attackers the ability to use their privileged subdomain to do other attacks such as cross-site scripting or client side request forgery on other subdomains.
Brand & Malware
An attacker may choose to negatively represent your brand by hosting offensive or illegal content on your subdomain, publicising your organisation’s lack of control of their assets, or even host malware on your subdomain. Using a real organisation’s subdomain for malware may allow bypassing reputation-based firewalls or safe-web browsing software.
How to Prevent Subdomain Takeovers?
Subdomain takeovers are fairly easy to fix:
- Remove the CNAME record during the process of deleting or removing the cloud service.
- Ensure policies are put in place when decommissioning resources to ensure any related resources are deleted.
- Perform regular external infrastructure and web application security assessments.
