Domains Gone Astray

The Domain Name System (DNS), comparable to an address book, forms the backbone of today's communication on the Internet. With IPv4, IT administrators could memorize their most important servers' IPv4 addresses, but there is no alternative to DNS with IPv6. In this article, I will show you how attackers exploit old DNS records to hijack parts of your domain, as well as show you how to protect yourself against these attacks.

DNS is divided into zones (a portion of the DNS namespace) managed by individual organizations or administrations. New entries are quickly created, and many projects sometimes result in very large zone files. Often, remnants of test setups or projects will remain in a zone even after they are no longer in use. Combine this with external services, such as external hosting or cloud service providers, and outdated entries can become dangerous.

Subdomain Hijacking

A simple example involves an A or AAAA entry from a subdomain on a cloud provider's IP address. When a project ends, all paid services are canceled with no further access to the cloud server. If this DNS entry does not result in explicit costs, users often simply forget to delete the entry. Because the entry still points to the provider's IP address, this entry becomes a dangling record – at least as long as the resource is not accessible. If a potential attacker gets the newly freed IP address for their server, the address can also be reached through your company's subdomain, but the services or content offered at the IP address are no longer under your control.

If you rely on cloud providers for your projects' resources, your subdomains will come from the provider's zone. A generic domain such as xyz.example.com is then made available to let you access your files. Of course, you could now resolve the IP address and add it as an A record for cloud.linux-magazine.com to your DNS. However, cloud providers usually operate a content delivery network (CDN), so your file is usually accessible from multiple IP addresses, and these addresses can change.

To avoid dealing with these underlying provider-side infrastructure changes, it makes sense not to use A records. Instead, you can use a CNAME record that points directly to xyz.example.com. Much like a shortcut on a filesystem, this changes the name resolution for your subdomain when the entries for xyz.example.com change. By doing this, you can still benefit from the dynamics offered by your cloud provider without having to worry about name resolution yourself. When you use your own domain name, you will not even notice the difference, because the resolving name server takes care of everything and simply returns the IP address that you need to access the files.

Name Assignments in the Cloud

Your data in the cloud is stored alongside data from your provider's other customers. The provider evaluates the hostname transmitted in the request in order to determine what information needs to be delivered when the data is accessed. However, this hostname is no longer xyz.example.com but the name of your subdomain, which resolves to the IP address of xyz.example.com thanks to the CNAME record.

Once you have finished the project and released the resources from the cloud, the assignment to your subdomain also disappears from the provider's system. Access is now no longer possible using the hostnames from your subdomain. In many cases, however, the admin responsible for the DNS zone is not notified, and the CNAME record continues to exist – your provider's xyz subdomain is so long and random that it would probably never be assigned to anyone a second time.

If an attacker sees that you connect to your cloud provider via your domain's CNAME record (e.g., by assigning the IP address resolved by your subdomain to your provider), the attacker could attempt to store the hostnames originally used in your company's subdomain under the attacker's account with the same provider. Depending on your provider, checks may not be performed to ascertain whether use of the stored name is actually legitimate. In addition, the name can only be used if a CNAME record is stored for it in DNS.

Rebound Attack

While the attacker will not get the same subdomain xyz.example.com as you did for your projects, it could be something like zyx. In fact, a real A record for your xyz entry in your provider's DNS zone has never existed. Instead, wildcards (*.example.com) simply resolve all the requested subdomains to the availble IP addresses in your provider's CDN. Your provider handles the actual assignment to the data via the hostname supplied with the request – and this hostname is now stored under the attacker's account.

With the data available in the attacker's project, which can be accessed through your company's domain, the attacker can now disseminate information claiming to be your company. They can also specifically attack your company or your customers, for example, by embedding manipulated content from this domain via a vulnerability in a web application. By using your subdomain, the same-origin policies of modern web browsers may allow active content to be executed in the context of your website.

In addition to attacks based on stored files, the same techniques can be used for access by other services. CNAME records can be created for any type of server, including the names of namespace (NS) or mail exchange (MX) records. Armed with these, an attacker can then control an entire subdomain or use one of your company's subdomains to send and receive email.

Taking Countermeasures

In an ideal world, the DNS zone's administrators would immediately be notified upon completion of a project and subsequently would remove the CNAME record, ensuring these attacks couldn't happen. Unfortunately, this sometimes does not happen in real life. On a positive note, there are a number of tools to help admins to check active and passive DNS entries.

Punk Security's DNS Reaper [1], an actively maintained open source tool, is one such solution. You can download DNS Reaper from GitHub and install it on your system. Punk Security also offers a pre-built image for use in a Docker container, which lets you use DNS Reaper directly without managing the runtime environment and any dependencies yourself. To view DNS Reaper's options and download the Docker image, simply use the following command:

docker run -ti --rm punksecurity/dnsreaper --help

You can use the output to get oriented and identify potential arguments for your use case. Of course, DNS Reaper needs a way to check all the existing entries in your zone. A black box check (i.e., without further knowledge of your DNS zone's structure) is not possible. While there are techniques to determine different entries in the DNS, applying them will not give you all of the existing entries.

For a comprehensive check, your best bet is to export your entire zone from the DNS server and make it available to DNS Reaper. If this is available in a BIND DNS compatible format, the software can use it directly. To use a zone file named domain.zone in the Docker container, you need to mount it as a volume in the image. You can then start it using the following command:

docker run -it --rm -v ./domain.zone:/domain.zone punksecurity/dnsreaperbind --bind-zone-file /domain.zone

Alternatively, you also use providers supported by DNS Reaper, such as AWS or Azure, by passing in your access credentials with the call. Transferring the zone directly from a DNS server is also possible, but this requires intervention in the server's configuration to allow a zone transfer.

Conclusions

Poorly maintained DNS records are more dangerous than they might appear at first glance. Attackers can use dangling records to run attacks that look like they originated in your organization. DNS Reaper helps you monitor your DNS records to protect against attackers.