Blog
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.
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.
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.
This section outlines the most commonly used DNS resource records (RRs) that have potential for misconfiguration.
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:
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.
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.