How to avoid subdomain takeover in Azure environments

Active but unused subdomains in Microsoft Azure give attackers the opportunity to use them for malicious purposes. Here's how to identify and delete vulnerable subdomains before attackers do.

Email takeover  >  Puppeteer hands manipulating strings
Spencer Whalen / Getty Images

Have you set up a domain and pointed to a cloud resource and then deleted the site? Have you left behind the CNAME in your domain name services settings? Many admins have, and attackers know it. These lapses allow attackers to create a site in your subdomain records and take over these sites. Subdomain takeovers are too common especially in large organizations that create and delete many resources. CNAME records in particular are open to takeovers. Malicious actors often use these sites to redirect traffic and activity to various other sites. Even Microsoft isn’t immune to the problem.

Domain Name Service (DNS) is an often-misunderstood part of network infrastructure. Too often misconfiguration of DNS can lead to massive issues in your network. It can make it look like your website has been hacked when merely the records have been changed. It might also expose your assets to being used in attacks.

How attackers exploit subdomains

As Microsoft notes, exposing yourself to subdomain takeover starts when you set up and provision an Azure resource. Let’s say the name of the Azure resource is app-on-azure001.azurewebsites.net. You then assign a CNAME record in your actual DNS zone with a subdomain that routes the traffic to the Azure resource. Rather than sending users to app-on-azure001.azurewebsites.net, you can send them to easierurl.domain.com. Later, you determine that you do not need the subdomain. You deprovision or delete the website. At this time, you should remove the subdomain.yourdomain.com from the domain name services zone. If the CNAME is still in place, it’s advertising that it’s an active domain but it’s not routing traffic through an active Azure resource. This is what is deemed as a “dangling DNS record”.

Attackers use various tools and scripts to search for and find these subdomains. A basic DNS lookup easily tells an attacker of CNAME records that are now non-routing. The attacker then provisions an Azure resource with the same name you assigned to your now missing Azure resource. Their attack website is now called app-on-azure001.azurewebsites.net and your subdomain.domain.com is now routing their site through your domain name resources. Attacks will include loss of control over your content and harvesting of cookie and visitor information to the attacker’s site.

How to prevent subdomain takeover

To identify potential issues, review CNAMEs associated with Azure resources using custom tools or Get-DanglingDnsRecords from Microsoft’s GitHub PowerShell tools. Once you’ve identified all vulnerable CNAMES or those pointing to assets that are not yours, go to where your DNS zones are hosted and remove all CNAME records that point to fully qualified domain names of resources no longer provisioned. You also need to search in any website or application code for specific subdomains and update any incorrect or outdated subdomain references.

If credentials from third-party authentication processes such as OAuth or other sensitive information was passed along to the subdomain, you may need to perform an incident response to determine your level of exposure. Attackers can embed iframes from other domains and make these subdomains look trustworthy. They then use them for phishing attacks internally as well as externally to customers. Always review what processes occurred to cause the incident and put in place processes to ensure it doesn’t occur in the future.

Azure has native processes to ensure that these dangling references do not occur in your network. One such process is to use asuid.(subdomain) TXT record with domain verification ID with Azure App Service. This ensures that no other Azure subscription can validate and take over the domain. Alternatively, you can put coding processes in place that provide with more interaction between developers and operations to ensure that you do not build websites that are susceptible to takeover.

Other manual ways to protect yourself from subdomain takeovers includes educating developers to be aware of this issue and adding checks for leftover DNS entries to checklists or processes. Have in place normal processes to review DNS records to ensure that any resource that points to *.azurewebsites.net or *.cloudapp.azure.com.

At the RSA Conference in February 2020, Alun Jones, an application security engineer, gave a presentation on subdomain takeover vulnerability. He explained how the decommissioning of web servers is often not controlled by the same organization that sets up DNS records in organizations, and thus CNAMEs are left behind in the DNS. He explained that cloud providers can’t be depended upon to provide the same security processes and it ultimately is an internal problem with your developers not fully understanding how your infrastructure is set up.

Jones said that one common solution, preparing a script review of all DNS records that runs every hour on the hour to find empty CNAME records, doesn’t proactively solve the problem because hackers can find vulnerable subdomains in less than an hour. Merely deleting a resource group when preparing a website for removal is not enough to ensure that websites are secured, nor is depending on educated developers. Jones recommends increasing the frequency of automated scans. Similarly, he advises not to rely on adjusting DNS records as DNS has a time-to-live (TTL) of about 24 hours. Thus, the subdomain can still be active and in various web caches for too long.

Subdomain enumeration can be done with OWASP Amass and Sublist3r to find those that are vulnerable. SubOver can be used as an automated takeover tool but cannot be used in Azure if that is your cloud platform’s service of choice. Several cloud vendors provide processes to ensure that customers are better protected and the websites that belong to a company stay with that company.

Jones urged that you understand your DNS environment better and ensure that developers receive training in basic DNS concepts, particularly around TTL. Finally, ask your cloud providers what they are doing to avoid the problem.

Copyright © 2020 IDG Communications, Inc.

How to choose a SIEM solution: 11 key features and considerations