If you are a mature organization, you might manage an external IP block of 65,000 IP addresses (equivalent to a /16 network). In contrast, very large organizations like Apple may handle an astonishing 16.7 million IP addresses or more (about a /8 network). However, this isn’t the case for many of us. IP addresses are fixed assets and can be costly, so most modern organizations do not have a large number of directly assigned IP addresses for every service they expose to the internet.
Instead, it’s common to configure exposure through the Domain Name System (DNS). It’s not uncommon for an organization to have over 100,000 DNS records. While changes to firewall rules are often tightly regulated through Information Security Management System (ISMS) processes, modifications to DNS records are usually made with much less oversight. For instance, development teams might update DNS records directly using infrastructure as code via Terraform or similar It’s important to manage your DNS carefully, as numerous risks can arise from inadequate control.
Even if you believe you have full control over your DNS, there are still many risks that can crop up along the path from the DNS Root to the actual software lookup.
DNS levels
A basic DNS lookup involves several key components that work together to complete the final query:
- Root Servers: There are 13 root servers worldwide, which serve as the authoritative source for DNS information. (Fun fact: the majority of these servers are located in NATO countries.)
- Top-Level Domain (TLD): These manage the different domain extensions, such as .com, .io, and others.
- Registrars: This is where you go to purchase your domain name.
- DNS Providers: Often associated with hosting services, content delivery networks (CDNs), or registrars, these providers facilitate DNS management.
- Zones: This refers to the configuration settings for the domain you have purchased.
- Your software sends DNS queries: This is the implementation of DNS that enables communication between machines that wish to connect with each other.
DNS can break at many levels – and it can be hard to detect
DNS was originally built for a different time, when only a small number of computers were connected over a network built on trust. The same applies to many other protocols still in use today, including SMTP and BGP.
Since its original implementation, there have been several enhancements, such as DNSSEC, which help improve technical security. DNSSEC adds cryptographic signatures to existing DNS records to ensure their authenticity.
However, DNS management often remains a manual process, leading to issues that can arise from simple typos. Compounding the problem is the fact that many types of DNS-related vulnerabilities cannot be detected from within the network or tested in a staging environment.
DNS lookup
Establishing communication begins with a DNS lookup. While information may be cached locally, if not, the following steps will be involved.
- Step 1: Check your local DNS cache/stub-resolver. If the information is present, proceed to Step 9. If not, continue to Step 2.
- Step 2: The resolver queries the root server for information about the Top-Level Domain (TLD).
- Step 3: Retrieve information about the TLD and then proceed to Step 4.
- Step 4: The resolver requests information from the TLD server about the specific domain.
- Step 5: Obtain information about the domain and move on to Step 6.
- Step 6: The resolver queries the domain for information regarding detectify.com.
- Step 7: Retrieve information about detectify.com and then proceed to Step 8.
- Step 8: The DNS resolver responds with the record information related to the domain.
- Step 9: Connect to the server that operates the application for detectify.com.
- Step 10: Enjoy state-of-the-art security testing!
DNS issues at each level
Root
- Implications:
- At the root server level, the security implications for applications are limited – the 13 root servers have very few publicly reported security incidents.
- However, the query process listed above can be vulnerable to hijacking through Border Gateway Protocol (BGP) manipulation, with several countries attempting to control information access in this way.
- Real-world example: Facebook once published incorrect BGP information that resulted in them effectively locking themselves out of their own service.
- Actions: While these issues may seem less relevant for organizations other than major tech giants like Facebook, Google, or Microsoft, it’s crucial for those operating critical infrastructure to consider how access to that infrastructure could be manipulated or disrupted, as evidenced by the Facebook incident.
Top-level domains (TLDs)
Registrars
- Implications: When it comes to managing registrars for your app, there are significant security implications, particularly since some top-level domains (TLDs) have only one registrar while .com has thousands. It’s essential to evaluate your trust and relationships with your registrar, as issues can arise from domains expiring or not being renewed, misspellings in domain names, or employees registering rogue domains.
- A real-world example is the Swedish Transport Administration, which faced downtime for not paying an invoice to their registrar.
- Actions:
- To mitigate risks, it is crucial to monitor expiration dates for domains diligently and ensure that payment information remains current.
- Implement a strict process for managing domains to avoid potential threats and disruptions.
DNS providers
- Implications: DNS providers play a crucial role in the security of applications, and misspelled name server (NS) pointers can have significant implications.
- Real-world example: For instance, Mastercard had a misspelled pointer to an Akamai domain for years.
- Actions: Considering the potential risks associated with misconfigured DNS settings, automation could be a valuable tool in preventing these types of errors and protecting applications.
Zones and subdomains
- Implications: Understanding the implications of zones and subdomains is critical for the security of your application.
- Misspelled zones and expired underlying cloud resources (potentially leading to subdomain takeovers) pose a significant risk.
- Email security mechanisms like MX, DKIM, DMARC, and SPF are controlled within zone information, proving the importance of proper zone management.
- Actions:
- Given that a compromised zone can lead to the unauthorized issuance of certificates, It’s highly advisable to implement automated controls for larger zones due to the rapid changes in both DNS and cloud resource statuses.
- Adopt a four-eyes principle for changes to help ensure that all configurations going live are thoroughly evaluated and accurate, reducing potential vulnerabilities.
- Keep an eye on SSL transparency logs for certificate issues related to domains you own, even if they are not directly issued to you.
Software DNS Queries
- Implications: It is not only the configuration of your own domains that matters. In most cases, a modern application loads a significant amount of external resources. The security of this process is then dependent on the domain from which the resource is being loaded. This significantly increases the practical attack surface of your applications.
- Actions: Monitor the status domains for the underlying resources. Leverage SRI features to validate what is being loaded
Let’s recap
Many components within the DNS chain can break and are difficult to detect. When dealing with more than a few hundred DNS entries, automation becomes a need. The severity of DNS-related vulnerabilities can vary significantly, ranging from merely informational to highly critical. Traditional vulnerability management systems often overlook these types of misconfiguration vulnerabilities.
Subdomain takeovers are highly contextual; if you cannot compromise other systems or directly access user data (such as cookies) through your takeover, they are typically not considered severe. However, if you control one out of many Name Server (NS) delegations for the root (apex) zone, the situation is arguably worse than the most severe form of SQL injection. Over time, this could give you access to all traffic destined for the vulnerable domain, including its subdomains.
Automation is crucial for managing these risks as your attack surface expands. Learn how Detectify can help. Start a 2-week free trial or talk to our experts.
If you are a Detectify customer already, don’t miss the What’s New page for the latest product updates, improvements, and new vulnerability tests.
