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.