Mismanaging your DNS infrastructure could put you at risk of destructive cyberattacks – especially as your cloud attack surface expands. Read on to learn about DNS vulnerabilities, the impact of DNS takeover attacks, and best practices for DNS security, including how new Tenable plugins can help you.

Many organizations overlook the security of their domain name system (DNS) infrastructure, a grave mistake, particularly if their cloud adoption is growing. Mismanaging your DNS records can allow attackers to take over any of your subdomains that are inactive and forgotten. Once hackers control one of your subdomains, they can craft a variety of devastating cyberattacks.

In this blog, we’ll unpack how the DNS protocol works; outline common DNS vulnerabilities and their impacts; and drill down into detection, prevention and mitigation best practices. We’ll also explain how newly-released Tenable Vulnerability Management, Tenable Web App Scanning and Tenable Attack Surface Management plugins can help you secure your DNS infrastructure.

Why cloud growth intensifies the importance of DNS security

Organizations increasingly want to integrate new cloud services and SaaS applications into their IT infrastructure to provide them to their users and customers. As part of this process, organizations often create a custom subdomain for their users or customers to access these third-party cloud applications. 

In order to do this, organizations need to create a new DNS record. It’s critical for organizations to keep track of these DNS records so that attackers don’t hijack the custom subdomains. Unfortunately, DNS infrastructure management is often overlooked, creating a blindspot for the organization’s security team. 

DNS resolution basics

The DNS protocol, historically a critical component of the internet infrastructure, translates numerical IP addresses into human-readable names.

DNS protocol provides various record types, including these four:

• "A" records, which are the basic translation between a subdomain and an IPv4 address.
• Canonical Name (CNAME) records, which allow organizations to have more than one domain alias pointing to a single domain name linked to one IP address. For instance, five domain aliases can point to example.com. If the IP address tied to example.com ever changes, its DNS record is the only one that needs to be updated. The CNAME aliases that point to example.com can remain as they are. CNAME records never point directly to an IP address – only to other domain names. The target domain name can be either in the aliases' same domain name or in a different one.
• Mail Exchange (MX) records, which direct email traffic by specifying which mail servers are responsible for accepting incoming email messages for a domain.
• Name Server (NS) records, which identify which DNS servers are authoritative on a given DNS zone. An authoritative DNS server contains the DNS zone with all the records.

To map a third-party service to an organization’s custom domain, the third-party vendor will request to configure one of these four record types. Once the process is completed, the organization’s traffic will be properly routed via the custom domain. 

The following diagram shows a basic example of how a DNS resolution mechanism works for a CNAME record that isn’t already in any cache of the DNS resolution chain:

^{Chart showing how a DNS resolution mechanism works for a CNAME record that isn't already in any cache of the DNS resolution chain}

The overall flow is similar for other record types such as MX or NS records.

Understanding DNS takeover vulnerabilities

The risk of a DNS takeover emerges when a DNS record is left dangling – meaning that the DNS record points to a subdomain that is inactive or was deleted. This would allow anyone to claim this DNS record from the third-party cloud service. 

A common scenario at the origin of such vulnerabilities is:

1. An organization’s business unit sets up a third-party cloud service for its internal users.
2. This business unit then asks the IT department to create a DNS CNAME record for this service to make it look more legit with an “organization” owned domain.
3. Later, the business unit decides to stop using this third-party cloud service but does not ask the IT department to remove the DNS CNAME record from the DNS zone.
4. Any user, including an attacker, can claim the custom subdomain from the cloud service provider, and configure it to host malicious content under the victim organization’s domain.

As an example, let’s take an organization that wants to host a basic static website on an AWS S3 storage bucket for an event, such as a two-day conference, and map a subdomain it owns such as mysuperstaticwebsite.acme.corp. By following the official AWS documentation, the service is provisioned and available to all intended users.

After the event ends, the organization takes the website hosted on S3 offline but forgets to remove the custom subdomain’s DNS record. 

The website now displays a generic error showing that the S3 bucket does not exist:

However, an attacker who looks at the DNS record for mysuperstaticwebsite.acme.corp would see the following configuration: 

dig +short CNAME mysuperstaticwebsite.acme.corp
mysuperstaticwebsite.s3-website.eu-west-3.amazonaws.com.

Using this information, the attacker could then log on to the AWS console, create an S3 bucket named mysuperstaticwebsite in the eu-west-3 region and attract people who think they’re visiting the legitimate https://mysuperstaticwebsite.acme.corp website.

This risky scenario isn’t limited to CNAME records. MX, NS or A records are also vulnerable. For example, for around 5 years, a Mastercard DNS error went unnoticed just because of a typography issue in one of the NS records set on its az.mastercard.com. The record, using akam.me, was indeed targeting a non-existing domain which was available for registration. 

DNS takeovers can also happen when a domain name expires and is not renewed in the allocated time by the organization that owned it. The domain name then can be purchased by anyone, including hackers, leaving the previous owner open to multiple attack scenarios.

One takeover, multiple impacts

Organizations are often unaware of the potential impacts a DNS takeover attack can have, beyond damage to its brand reputation and to its customer confidence. 

Depending on the type of the compromised DNS record and the organization’s usage of this record, many exploitation vectors could have an impact on an organization's security, including:

• Phishing: Attackers can build realistic phishing websites hosted on a legitimate URL domain name to target the organization’s internal or external users.
• Email interception: MX records are a critical part of email infrastructure. When one or several MX records are left dangling and target-DNS records become unavailable, an attacker could take over the DNS records and receive e-mails intended for previous users of this service. This can have a huge impact. It can allow attackers, for example, to perform password-reset operations and log into active services from the organization. 
• Cookie tossing: Taking control of a subdomain could allow an attacker to set cookies for the parent domains and make them apply to other subdomains. Depending on how the cookies are handled on the other applications, this could help an attacker conduct further attacks.
•  Bypassing client-side security:
  • Content-Security Policy (CSP) allows website admins to control which resources a browser can load. If a compromised subdomain is in a CSP allow list, an attacker could exploit this vulnerability to bypass the CSP security controls and launch client-side attacks such as cross-site scripting (XSS).
  • A Cross-Origin Resource Sharing (CORS) policy defines the vulnerable subdomain in the allowed origins. An origin is a combination of the URI scheme, the host name and the port number, and adding it to the CORS policy defines the sources allowed to perform cross-site requests on a given web application. An attacker could host malicious JavaScript and exploit the CORS configuration to access sensitive information or perform operations on behalf of legitimate users.
• Cloud resources compromise: When the compromised target is, for example, a cloud resource such as a storage bucket or a database, it could have a broader impact on the rest of the infrastructure. For example, if a web application still refers to JavaScript static files on a storage bucket that has been taken over, an attacker could upload malicious JavaScript content and conduct stored XSS attacks on other internal or external web applications. 

The risks are even higher when the vulnerable record is an NS record. This type of record allows administrators to delegate the entire DNS zone management to a third-party server. If it is compromised, attackers can then create multiple other records in the delegated zone.

How to detect, prevent and mitigate

Mitigating DNS takeover vulnerabilities is not complex, and will mainly require following best practices for the lifecycle management of DNS records. 

For starters, you must have a well-established and documented process for provisioning external services so that you avoid these mistakes:

• The DNS record is created but you haven’t yet deployed the third-party cloud service.
• The DNS record is created and you’ve subscribed to the third-party cloud service, but you haven’t finalized the custom DNS configuration.
• The third-party cloud service is terminated but the DNS record is not removed from your organization’s DNS zone.

Instead, you must ensure that the DNS record is created only after the third-party cloud service has been created and configured. Once the third-party cloud service is no longer needed, the DNS record must be removed before the external service configuration is eliminated. 

If you are developing a SaaS application as a service provider, you should request customers to verify their domain name's ownership before assigning it a custom DNS record and routing it to your infrastructure. Common security protection requires organizations to add TXT DNS records in the subdomain DNS zone to confirm that they own the subdomain. It is also possible to generate a random and unique CNAME record to be used by each customer, preventing an attacker from re-using a previous CNAME record and hijacking the subdomain.

When attackers analyze an organization’s attack surface, they will enumerate the DNS records related to this organization and check if any dangling records exist. To achieve this, they will look for three different issues:

• Dangling services that provide an HTTP response. They will have a valid and resolvable DNS record, but will also provide a default HTTP response which can be used to fingerprint the vulnerable services.
• Dangling services with DNS resolution failure which, most of the time, have CNAME records targeting DNS records that are not resolvable, and makes the DNS resolver return an NXDOMAIN error.
• Dangling services targeting an IP address not allocated. Attackers can claim, for example, elastic IP addresses on public cloud infrastructures.

Tenable Vulnerability Management’s Attack Surface Management and Web App Scanning features let you comprehensively assess and remediate DNS security issues. By leveraging plugins 114146 (Subdomain Takeover) and 114572 (Danging DNS Record) in addition to Attack Surface Management capabilities, Web Application Scanning users can quickly check if their subdomain is targeting HTTP based dangling records and try fixing these issues before an attacker exploits them. 

Conclusion

Managing an organization’s attack surface requires solid DNS infrastructure management. While DNS records may seem like relics of early cloud adoption, the increasing complexity of modern architectures and rapid evolution of cloud services makes DNS infrastructure management more relevant than ever.

When attackers exploit DNS vulnerabilities, they can build an attack chain that can compromise user sessions, exfiltrate sensitive data or impersonate legacy services. That’s why organizations must embrace a proactive approach and adopt a solid DNS provisioning and management process.