Have you ever deleted a site with a domain set up and cloud resources intact? What if CNAME was left unchanged in DNS (domain name services) settings?
This is something that many administrators have experienced, and attackers know it. The attacker creates and occupies the site in the subdomain record using the part that the administrator forgot. Subdomain takeovers are very common in large enterprises that create and delete many resources. In particular, CNAME records are exposed a lot to occupancy. Malicious actors use these sites to redirect traffic and activities to various other sites. Even Microsoft is not free from this problem.
DNS is often misunderstood in network infrastructure, and incorrect DNS configuration is very often leading to serious network problems. It's just that the record has changed, and the website can appear to be hacked. In addition, assets can be exposed and used in attacks.
How attackers exploit subdomains
As Microsoft announced, it starts to be exposed to subdomain occupancy from the time Azure resources are set up and provisioned. For example, the Azure resource is named app-on-azure001. Suppose it is azurewebsites.net.
It assigns a CNAME record to the real DNS zone with a subdomain that routes traffic to this Azure resource, and directs users to easierurl.domain.com instead of sending them to app-on-azure001.azurewebsites.net After some time, it determines that this subdomain is not needed, so it deprovisions and deletes the website. At this point, you need to remove subdomain.yourdomain.com from your DNS zone. The remaining CNAME advertises that it is the active domain, but does not route traffic through the active Azure resource. This is called the “dangling DNS record”.
Attackers use various tools and scripts to search and find subdomains in this state. An attacker can easily find out which CNAME record is not currently being routed with a basic DNS lookup. The attacker provisions the Azure resource with the same name you assigned to the currently missing Azure resource. Now their attacking website is named app-on-azure001.azurewebsites.net, and your subdomain.domain.com routes the attacker's site through the domain name resource. If attacked, you may lose control of the content or transfer cookies and visitor information to the attacker's site.
How to prevent subdomain occupancy
To identify potential problems, use a custom tool or Get-DanglingDnsRecords from the Microsoft GitHub Powershell tool to check the CNAME associated with Azure resources. Find all vulnerable CNAMEs or CNAMEs that point to assets that you don't own, then go to where your DNS zone is hosted and delete all CNAME records that point to the fully qualified domain names of resources that are no longer provisioned. You also need to search for specific subdomains in your website or application code to update inaccurate or outdated subdomain references.
If authentication information or other sensitive information from a third-party authentication process such as OAuth has been delivered to a subdomain, it is necessary to initiate incident response and check the level of exposure. An attacker can decorate a subdomain like this as a trusted subdomain by embedding iframes of other domains. Then use it for internal phishing attacks or attacks on external customers. You need to identify the process that took place to trigger the incident and take steps to prevent it from happening in the future.
Azure has a basic process to make sure your network doesn't get stuck in cases like this. One of these is the use of an asuid. (subdomain) TXT record with a domain verification ID in Azure App Service. This prevents other Azure subscriptions from verifying and seizing the domain. Alternatively, you can have a coding process that increases the interaction between developers and operations to avoid building occupancy-sensitive websites.
Another way to protect yourself from subdomain occupancy is to educate the developer to be aware of this problem and add a checklist or check the remaining DNS entries to the process. Establish a process to review DNS records for resources pointing to *.azurewebsites.net or *.cloudapp.azure.com.
Application security engineer Arun Jones made a presentation on the subdomain occupancy vulnerability at the RSA conference in February 2020. Jones explained the case where the CNAME remains in DNS because the organization responsible for the destruction of the webserver and the organization setting the DNS records are different. Jones explained that cloud providers shouldn't expect to provide the same security processes as enterprises, and ultimately, the issue is an internal organizational issue where developers don't fully understand how the infrastructure is set up.
A common solution is to run an hourly script review of all DNS records to find empty CNAME records, but Jones takes less than an hour for hackers to find vulnerable subdomains, so this method preemptively eliminates the problem. Said it could not be resolved.
In preparation for removing a website, simply deleting a resource group is something you can do without being an educated developer and lacking in ensuring the safety of your website. Jones recommends increasing the frequency of automated scans. Jones also advises against relying on DNS record reconciliation. This is because the validity period (TTL) of DNS is about 24 hours, so the subdomain can remain active for a long time and exist in various web caches.
You can find vulnerable subdomains by enumerating them with OWASP Amass and Sublist3r. SubOver can be used as an auto-occupancy tool, but it cannot be used when Azure is selected as the cloud platform. Several cloud providers provide processes to better protect customers and ensure that websites belonging to companies remain under their control.
Jones emphasized the need to better understand the DNS environment, and to educate developers on basic DNS concepts, especially in relation to TTL. Finally, you should ask your cloud provider what they are doing to avoid this problem.
0 Comments