Hardenize has joined Red Sift! Find out more in our blog post.


Welcome to the Hardenize blog. This is where we will document our journey as we make the Internet a more secure place and have some fun and excitement along the way.

26 Jan

New: Subdomain Takeover Prevention and Dangling DNS Detection

by Ivan Ristić

Last time, we announced the addition of comprehensive DNS inspection to Hardenize. Building on that foundation of being able to reason about DNS configuration, today we continue our deep dive into DNS with automatic detection of a range of dangling DNS issues, helping organizations keep their DNS configuration clean and prevent domain and subdomain takeover attacks. In this blog post we discuss what aspects of DNS lead to dangling DNS issues, enumerate a number of practical problems, and show how we address them in Hardenize.

Dangling DNS and (Sub)Domain Takeover

The Domain Name System (DNS) is the address book for the Internet. It bridges the gap between domain names, which are easier for humans to handle and remember, with IP addresses and other behind-the-scenes elements that are necessary for the Internet to function. In essence, DNS is a higher abstraction layer that simplifies how we think about and consume network resources.

Like any other tool, DNS can be misconfigured. When that happens, things may or may not stop working. Often, because DNS infrastructure is usually built with redundancy in mind, a misconfiguration creates apparently intermittent but difficult to diagnose issues, or leads to performance problems, such as slower name resolution.

There is a special class of configuration problems that stems from the fact that DNS is configured separately from the networking layer. For example, to create a new service one would typically obtain and configure a server, then, in a separate step, make changes to the DNS configuration to point the desired name to the server's IP address. This duality creates an opportunity for the configuration to get out of sync, leading to dangling DNS configuration weakness. A generic name for a successful exploitation of dangling DNS issues could be DNS asset takeover, although in practice people most often talk about more specific exploits, which we cover below.

Dangling DNS configuration can be exploited by a malicious third party who is able to take control of the resources (names or IP addresses) that are delegated from a given DNS name. In some cases they can take only a subdomain, in others the entire domain name. Takeovers are commonly carried out to exploit any residual trust left in the domain names, to attack related infrastructure, or to claim bounties.

The most widely understood problem of this type is subdomain takeover. For example, a new subdomain may be created to run some service and delegated to a third party via a CNAME alias. Some time later, the service is cancelled, with the DNS configuration mistakenly left in place. An enterprising individual, who may be actively monitoring the company's systems, can detect this dangling DNS issue and re-create the third-party service to take control of the DNS name. This type of problem frequently happens with cloud storage buckets that are used as web sites. All of a sudden, someone is serving content from a name that doesn't belong to them.

Takeover opportunities are sometimes created because of configuration mistakes, for example typos. It's also possible that a domain name expires while still being referenced in the DNS. In this case, the attacker only needs to register the domain name in order to take control of the delegated resource.

The most dangerous type of takeover is nameserver takeover, in which an attacker establishes control of the domain's nameserver, which gives them full control of the entire namespace.

Some types of DNS misconfiguration can lead to incorrect authorization and even information leakage. Take SPF records, for example, which control which systems are allowed to send email on behalf of a domain name. Or, DMARC and TLS-RPT reporting, which controls where diagnostic information (which may contain sensitive data) is sent.

Dangling DNS Configuration

This section outlines the most commonly used DNS resource records (RRs) that have potential for misconfiguration.

  • A and AAAA records are used to delegate a DNS name to one or more IP addresses. A records are used for IPv4 addresses and AAAA records for IPv6.
  • CNAME records create aliases, enabling one DNS name to delegate all its configuration to another name. They're aliases. CNAMEs are used to simplify DNS management, especially in situations where the IP addresses may change over time. CNAMEs are also commonly used to forward a name to a third-party service.
  • DMARC and TLS-RPT records are used to configure email policy, but they can also enable reporting functionality. For example, if a delivery of an email fails, the sending system may dispatch a failure report, typically via an email to a special reporting email address specified in the relevant DNS records. A takeover of the reporting mailbox could lead to leakage of sensitive information.
  • MX records point to the mail servers in charge of accepting email for a given name. Takeover of the mail servers may lead to the attacker gaining access to the domain's email.
  • NS records enumerate all nameservers considered authoritative for a DNS zone. If an entry points to a name that is not under the owner's control then the attacker can achieve full control over all queries that arrive at the rogue server.
  • SRV records were intended to decouple a DNS name (as it's visible to end users) from the services and servers that are used to deliver services associated with that name. They're similar in concept to aliases, but support granular per-service configuration.
  • SPF records are used to establish policies for email sending. A takeover of the advertised names or IP addresses could enable spammers to send email on behalf of the domain name owner.
  • SVCB records are a modern effort to extend DNS to support improved aliasing and efficient metadata distribution. Multiple features are combined in the same RR for efficiency. HTTPS records are an implementation of SVCB records for HTTP. In addition to the aliasing functionality, HTTPS records support IPv4 and IPv6 address hints that can be used to improve resolution latency.

Broken Zone Delegation

DNS is a hierarchical system. Owners control the configuration of their own zones, but, because these zones exist within global parent zones, some configuration work has to be done in the parent resolvers. Having to synchronize configuration across multiple systems creates opportunity for additional problems:

  • Parent referrals; the servers in the parent zone need to know where to forward (refer) the queries for the final zone. Ideally, the referral nameservers should match the contents of the zone's NS records. If changes are made to the nameservers but the parent zone isn't reconfigured, referrals can continue to be made to retired services.
  • Referral glue; in DNS, glue records are used to resolve recursive relationships and improve lookup efficiency. Glue records are not part of the main configuration; instead, they're configured in the parent zone. For example, a glue record for the "example.com" zone would be configured in its parent, the "com" zone. Special care must be taken to update the glue every time the IP addresses of the nameservers change. Otherwise, if an IP address is orphaned, whoever gains control of it will control the name resolution of the entire domain name.

Delegation to Third-Party Services

In recent years it has become quite common to outsource to third parties functionality that might have been implemented internally in the past. Good examples are ecommerce websites and help desk platforms.

When using one of these external solutions, users start by creating an account with the vendor, which typically means deciding on the account username. This usually leads to the creation of an account-specific subdomain, for example "hardenize.example.com". Many vendors support delegation of additional domain names as an option, which allows for a user-friendly name that doesn't have the vendor's branding, for example "support.hardenize.com". Delegation is done in one of two ways. The usual approach is to use a CNAME to forward a subdomain to the vendor. However, domain names cannot be aliased using CNAMEs; to delegate a domain name users must configure their A and AAAA records with the vendor's IP addresses. (In practice, many managed DNS providers support custom functionality that automatically configures and reconfigures domain name's records to emulate how CNAMEs would work.)

Practically speaking, that means that there are up to two additional resources to track for each service. The principal danger is that, after the account is removed, there are left websites that contain the user's brand name or even domain name. In addition to the reputation threat, these dangling domain names can have negative security implications.

This usage pattern applies both to subdomain takeover, which is the more common situation, but also to nameserver takeover if the third parties are managed DNS providers. Because these vendors offer their services to the general public, a dangling DNS configuration may be exploited by someone opening an account with the vendor to claim the dangling resource.

Dangling DNS configuration to third-party services also complicates detection as it is no longer possible to establish the presence of a problem from the DNS configuration alone. Checks have to be designed for each third party service specifically to probe for account availability.

Dealing with Dangling DNS Issues

Usually the most difficult part of dealing with dangling DNS problems is detecting them in the first place. Fortunately, this is a problem that Hardenize makes easier, chiefly because building a complete inventory of domains and subdomains is one of our core functions. Once an inventory is built, we monitor it continuously for a variety of problems, including DNS.

Recently, we built another layer of functionality to deal with DNS configuration problems that may have security implications, such as subdomain takeover and nameserver takeover. In a nutshell, we fully traverse the entire inventory and everything about your DNS configuration to find all aliases, delegations, and delegations, and we check all of them. Where DNS checks alone are not sufficient, we use further custom checks designed for the most popular third-party service providers to check for dangling accounts. The end result is continuous monitoring of all dangling DNS problems.

Once you become aware of a problem, resolving it is a matter of getting in touch with the persons who are able to make configuration changes to the affected domain names. Most dangling DNS issues are a result of broken DNS configuration; to remove the security weakness one just needs to fix the DNS, for example removing an incorrect CNAME alias.