Don’t forget that DNS is a part of your Attack Surface

If you play an active role in your organisation’s Information and Cyber security, you are likely to be familiar with the term Attack Surface Reduction (ASR). The attack surface of an organisation is essentially the totality of points in a system and network that can be targeted for exploitation. This includes hardware and software components, applications, network configurations, open ports, user accounts and their associated privileges.

A large attack surface or a surface that is not adequately accounted for, monitored and managed offers greater opportunities for bad actors to exploit vulnerabilities and gain unauthorised access. The role of ASR is therefore to shrink this area, minimise the points of entry which offers attackers less scope to target thus lowering associated risk and contributing to a stronger security posture.

Some of the more common ASR strategies include.

• Asset Management – Implementing good practice with respect to identifying and maintaining an accurate inventory of all hardware, software, network components and users in your digital estate.
• Adoption of Zero Trust – The principle of Zero Trust challenges the traditional security model, which often relies on the assumption that anything inside a network is trusted while anything outside is not. It operates on the core principle that organizations should trust nothing and verify everything, regardless of whether a user or system is inside or outside their network.
• The Principle of Least Privilege – Limiting user access to only what is necessary for them to perform their duties.
• Patch Management – Regularly updating and patching software, operating systems, and firmware to fix known vulnerabilities and reduce the attack surface.
• Network Segmentation – Dividing your network into isolated segments to minimize lateral movement for anyone attempting to gain unauthorised access.
• Application Allow-listing – Allowing only approved applications to run on your network. This can prevent unauthorized software from running and reduce the risk of malware infections.
• Security Audits and Assessments – Conducting regular security assessments, penetration testing, and vulnerability scanning will help identify and address weaknesses.

An area that is often overlooked when considering the scope of an ASR strategy is your organisation’s Domain Name System (DNS). The DNS is the backbone of the internet, responsible for translating human-readable domain names into IP addresses that computers use to locate websites and a host of other digital services.

Whilst the DNS has come a long way since its humble beginnings of being a single hosts.txt file maintained and distributed to computers on ARPANET, its evolution has been steered by performance rather than security and it wasn’t until 2005 that we saw DNSSEC introduced as a security extension which allowed zones to be signed with cryptographic keys. Even today however, almost 20 years on from its inception, we have not seen ubiquitous adoption with only 4% of .com domain[1] names have signed DNS zones.

There are many reasons why there has been such a slow take up rate in DNSSEC adoption ranging from implementation complexity, operational overhead, risks associated with mis-configured DNSSEC (e.g., service disruptions) and reliance of the chain of DNS resolution trust.

Despite these challenges, there appears to be a growing awareness and recognition of the importance and role that DNSSEC plays and despite its slow burn adoption since 2005 organisations will start to consider DNSSEC as an important cog in ASR.

Another often neglected area of DNS management which is intrinsically linked to an organisation’s attack surface is the practice of good zone file record management and specifically good practice with respect to subdomain management and having control over “dangling” subdomains.

A subdomain is a part of a larger domain and is typically used to organise and structure a website or network. For example, in my.company.com, “my” is a subdomain of company.com. A subdomain can be further divided into its own subdomains, creating a hierarchical structure.

A dangling subdomain exists in DNS records but is not associated with a specific server or IP address. This can occur when a subdomain is initially created for a specific purpose (e.g., hosting an application or service with a public cloud provider such as Azure or AWS) but not removed from the domain’s zone file when the service is deprovisioned. At this point it’s a dead-end subdomain and bad actors will often scan for their existence in order to take control of them by associating them with their own services. This allows them to host malicious content, launch phishing attacks, or exploit the reputation of the legitimate domain.

A common scenario for a subdomain takeover is outlined below.

• You provision a public cloud resource with a fully qualified domain name (FQDN) of my-application-001.cloud-provider-of-your-choice.net.
• You assign a CNAME record in your DNS zone with the subdomain my-app.mycompany.com that routes traffic to your Cloud resource.
• The cloud resource is deprovisioned as it is no longer needed.
• At this point, the CNAME record my-app.mycompany.com should be removed from your DNS zone. If the CNAME record isn’t removed, it’s advertised as an active domain but doesn’t route traffic to an active Cloud resource. This is the definition of a “dangling” DNS record.
• Using commonly available methods and tools, a bad actor discovers the dangling subdomain.
• The bad actor provisions a cloud resource with the same FQDN of the resource you previously controlled. In this example, my-application-001.cloud-provider-of-your-choice.net.
• Traffic being sent to the subdomain my-app.mycompany.com is now routed to the malicious actor’s resource where they control the content.

The risks associated with dangling domains can be mitigated through a range of tactics which include regular audits and clean up of DNS records, good governance through the creation of organisational subdomain policies and active monitoring of subdomain activity and resolution.

Attack Surface Reduction is undoubtedly a critical component in any security strategy but it’s also important that organisations fully understand the scope and size of their own surface to ensure adequate and proportional coverage. Sometimes DNS gets overlooked from this coverage and that can lead to unnecessary risk which can be addressed through implementation of good practice and housekeeping so be sure not to overlook its relevance and importance.