In this blog we discuss dangling DNS and how if left unresolved, an attacker can mar the reputation of a victim company.
First let’s start by defining Domain Name System (DNS). A Domain Name System is an assortment of databases that translates hostnames to IP addresses. So, when you type “google.com” into your browser, a request is sent to a DNS server that asks for the IP address that is behind the domain name “google.com”. This is obviously much easier than navigating the internet via obscure IP addresses. Similarly, an internal network DNS makes it easier for system administrators to name individual machines in their environment; making it easier to manage.
We can use a DNS lookup to find the IP address hidden behind a domain address or hostname. A popular tool to do this is “dig”.
Now that we have an understanding of what DNS is and what it’s used for, we need to understand “CNAME” and “A” records:
- Canonical names or CNAME records can be used to alias one name to another.
- An A record points a domain name to an IP address of the computer hosting the domain.
A common example is when you have both example.com and www.example.com pointing to the same application and hosted by the same server. To avoid maintaining two different records, it’s common to create:
- An A record for example.com pointing to the server IP address
- A CNAME record for www.example.com pointing to example.com
The last thing to note before we get to Dangling DNS is understanding that there can be multiple CNAME or A records for a specific address.
We can see that by using the same tool we used earlier “dig”.
Now that we have a solid understanding of DNS, pointers and aliases we can talk about dangling DNS.
The term “dangling” refers to when a DNS administrator forgets to remove an alias in their DNS zone after they are done using it, thus leaving it “dangling” in the wild.
If an attacker notices a CNAME entry with a decommissioned destination address, they can grab the destination address and deploy arbitrary code to it.
I found this image on google that helps visualize this.
The attacker sends a request to the CNAME entry app-contogreat-dev-001.azurewebsites.net and receives a 404 (page not found) response. They then assume that the alias has nothing living behind it and proceed to acquire the destination DNS address. Now, the attacker can masquerade as the victim organization.
If the platform allows it (like Azure Websites, Elastic BeanStalk, Github, etc.), an attacker can register anything under that alias, essentially having full control of where the DNS request points to. This is referred to as a “DNS take over”.
Surprisingly enough, dangling DNS is not an uncommon vulnerability. Bug bounty hunters love to look for this sort of “low hanging fruit” because of how easy it is to find, and how severe the consequences can be – no matter the size of the company.
Luckily, if your company has dangling DNS entries, the remediation process is easy. Simply delete the unused alias from your DNS zone and regularly monitor for empty aliases in your zone.
References and Additional Readings:
https://support.dnsimple.com/articles/a-record/
https://support.dnsimple.com/articles/cname-record/
https://nominetcyber.com/dangling-dns-is-no-laughing-matter/
https://github.com/EdOverflow/can-i-take-over-xyz
(Microsoft developers have created a powershell tool to identify Dangling DNS for Azure Developers, found at this link)
https://docs.microsoft.com/en-us/azure/security/fundamentals/subdomain-takeover
As with all of my blog posts, my goal is to arm the reader with the knowledge needed to understand a vulnerability and apply it to their own circumstances. Thanks for reading and remember to subscribe to our newsletter below to be notified when we publish future blog posts.
