Securing Your Cloud Attack Surface by Reducing DNS Infrastructure Risk

Written by Rémy Marot.

Originally published by Tenable.

 

The domain name system is often one of the last things an organization thinks of when they consider their overall security posture. This is a big mistake, especially while cloud adoption has been growing so quickly. This kind of mismanagement of DNS records can give attackers an entry point to control inactive or forgotten subdomains. After hackers gain control of a subdomain, they’re free to create any number of cyberattacks that can devastate an organization.

This blog explores the inner workings of the DNS protocol. We’ll also outline current DNS vulnerabilities and how they can affect an organization. Then we’ll go deep into best practices for detection, prevention and mitigation.

 

DNS security has increased in importance alongside cloud growth

Organizations increasingly want to integrate third-party cloud services and SaaS applications into their IT infrastructure to provide them to their users and customers. In the process of doing that, they often create a custom subdomain to enable access to these third-party cloud applications.

This requires an organization to create a new DNS record. Keeping track of those records is important so those custom subdomains can’t be hijacked. However, many organizations overlook DNS infrastructure management as part of their cloud security best practices, causing security teams to often have blindspots.

 

The keys to DNS resolution

The DNS protocol has been central to the internet infrastructure since the 1980s, performing the unheralded job of translating strings of IP address numbers into names we humans can understand.

Four key DNS protocol record types:

• “A” records translate between a subdomain and an IPv4 address.
• Canonical Name (CNAME) records give organizations a way to point more than one domain alias to a single domain name with one IP address. For example, five domain aliases could point to example.com. This is helpful if the IP address behind example.com ever changes. The DNS record is the only thing that would need to be updated. Any CNAME aliases pointed at example.com can stay as-is. CNAME records only point at other domain names, never directly at an IP address. As such, the target domain name can be part of the aliases’ same domain name or in a different one.
• Mail Exchange (MX) records specify the mail server that accepts incoming email messages for a domain.
• Name Server (NS) records identify the DNS servers that are authoritative for a specific DNS zone.

A third-party vendor, when mapping a service to an organization, will request to configure one of these four record types. Once they complete the process, traffic in the organization’s route via the custom domain.

This diagram displays an 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

For other record types, such as MX or NX records, the flow is similar.

 

How DNS takeover vulnerabilities work

When a DNS record points to a subdomain that is inactive or was deleted, the risk of a DNS takeover grows. This kind of oversight enables anyone to go to a third party cloud service and claim the DNS record.

The origin of such vulnerabilities usually comes from a fairly common scenario:

• An organization’s business unit sets up a third-party cloud service for its internal users.
• 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. 
• 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.
• 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.

Let’s look at an organization with a basic static website hosted on an AWS S3 storage bucket. Maybe they need it for a two-day event so the organization maps a subdomain it owns — something like mysuperstaticwebsite.acme.corp. According to AWS documentation, the service is provisioned and available to all intended users.

After the event ends, things get interesting. The site on S3 is dutifully taken offline. But there’s an oversight — no one removes the custom subdomain’s DNS record.

As expected, the website displays a generic error that says the S3 bucket does not exist:

That might seem like the end of the story. But an attacker who looks at the DNS record for mysuperstaticwebsite.acme.corp will see a more revealing snippet of information in the configuration:

Armed with this information, an attacker could log on to the AWS console, create an S3 bucket called mysuperstaticwebsite in the eu-west-3 region and trick visitors into thinking they’re at the legitimate https://mysuperstaticwebsite.acme.corp site.

Attacks using CNAME records are just one scenario. Issues with MX, NS or A records make those avenues vulnerable as well. In one high-profile example, a Mastercard DNS error went unnoticed for about five years due to a typography issue in an NS records set attached to az.mastercard.com. The record, which used akam.me, targeted a domain that no longer existed but was available for registration.

When a domain name expires or is not renewed in time, this is an opportunity for a DNS takeover. Of course, anyone — including hackers — can purchase an expired domain name, which can lead to a number of attack scenarios.

 

A single takeover can have a wide-ranging impact

Organizations often don’t know about the ways a DNS takeover attack could affect them, apart from brand damage and customer confidence suffering.

Many vectors could be used to affect an organization's security, depending on the type of compromised DNS record and how the record was used, including:

• Phishing: Attackers can create phishing websites that target an organization’s users that appear to be realistic because they’re hosted on URLs that look legitimate domain name.
• Email interception: MX records are critical to email infrastructure, so when one or more are left unused and target-DNS records are unavailable, attackers have the opening they’re looking for to take over a DNS record and get e-mails sent to previous users, which  can enable attackers to perform password-reset operations and log into an organization’s active services.
• Cookie tossing: With control of a subdomain an attacker can set cookies for the parent domains and apply them to other subdomains, which could help an attacker conduct further attacks.
• Bypassing client-side security:
  • Content-Security Policy (CSP) gives website admins control over the resources that can load in a browser. So if a compromised subdomain is in a CSP allow list, an attacker could use it to bypass the CSP security controls and launch client-side attacks such as cross-site scripting (XSS).
  • Cross-Origin Resource Sharing (CORS) defines the vulnerable subdomain in the allowed origins, which combines the URI scheme, the host name and the port number. It then adds it to the CORS policy that defines the sources allowed to perform cross-site requests on a given web application. An attacker could use this approach to host malicious JavaScript and exploit the CORS configuration to access sensitive information or perform operations on behalf of legitimate users.
• Cloud resources compromise: A target that is a cloud resource like a storage bucket or a database could have a broader impact on the rest of the infrastructure. Maybe there’s a web application that still refers to JavaScript static files on a storage bucket that has been taken over. In this scenario, an attacker could upload malicious JavaScript content and launch stored XSS attacks on other internal or external web applications.

The risks increase when the vulnerable record is an NS record. This type of record gives administrators the ability to delegate the entire DNS zone management to a third-party server. Once compromised, attackers can create many additional  records in the delegated zone.

 

The keys to detecting, preventing and mitigating

It’s fairly simple to mitigate DNS takeover vulnerabilities. It just requires adhering to  best practices for the lifecycle management of DNS records.

First off, you need a well-established and documented process for provisioning external services. That way, you’ll avoid some common mistakes, including:

• Creating a DNS but you haven't yet deployed the third-party cloud service
• Creating the DNS record and you subscribed to a third-party cloud service, but you haven’t finalized the custom DNS configuration
• You terminated the third-party cloud service but didn’t remove the DNS record from your organization’s DNS zone

You should make sure that you create the DNS record only after creating and configuring the third-party cloud service. Once you no longer need the third-party cloud service, you should remove the DNS record before eliminating the external service configuration.

If you are a service provider developing a SaaS application, request that customers verify their domain name's ownership before assigning a custom DNS record and routing it to your infrastructure. Adding TXT DNS records in the subdomain DNS zone is a common security protection practice that confirms subdomain ownership. Another approach is generating a random and unique CNAME record for each customer, which will prevent an attacker from re-using a previous CNAME record and hijacking the subdomain.

Attackers looking at an organization’s attack surface, will often enumerate the DNS records related to the organization and try to spot dangling records. There are three different issues they’ll look for:

• Dangling services with an HTTP response that has a valid and resolvable DNS record and also provides a default HTTP response that can be used to fingerprint the vulnerable services
• Dangling services with DNS resolution failure that often have CNAME records that target unresolvable DNS records and return an NXDOMAIN error
• Dangling services that target an unallocated IP address, such as elastic IP addresses on public cloud infrastructures

 

Conclusion

Taking control of an organization’s attack surface requires a commitment to DNS infrastructure management. Although DNS records may seem like early cloud adoption relics, DNS management is more relevant than ever, thanks to increasingly complex modern architectures and rapid evolution of cloud services.

Attackers that exploit DNS vulnerabilities can build an attack chain to compromise user sessions, exfiltrate sensitive data or impersonate legacy services. To avoid this, organizations should turn to an approach to cloud security that’s proactive and includes adoption of a well-thought-out DNS provisioning and management process.

 

---

About the Author

Rémy Marot joined Tenable in 2020 as a Senior Research Engineer on the Web Application Scanning Content team. Over the past decade, he led the IT managed services team of a web hosting provider and was responsible for designing and building innovative security services in a Research & Development team. He also contributed to open source security software, helping organizations increase their security posture.