Next year will mark the 40th anniversary of the creation of the Domain Name System (DNS) by Paul Mockapetris, a pioneer of the IT industry whose forays into early distributed systems and email delivery applications led to the groundbreaking naming exchange that permeates today’s internet.
Subsequent developments, which mainly entailed a hierarchical structure (also known as a domain name space), name servers, and resolvers, will forever decentralize the provisioning landscape that surrounds the various specifications attributed to domain names, as well as their corresponding one-to-one mapping to internet protocol (IP) addresses. Over time, DNS would evolve into its own discipline, sometimes rifling through many of its so-called design flaws to attenuate a flurry of growing security vulnerabilities threatening its very existence—some (occasionally) brimming to the point of causing massive disruption to essential web services across the globe.
Subdomain takeover, a discrete but opportune technique that weeps from an undisciplined approach to authoritative DNS hygiene, is yet another example of the kind of misuse that the technology can be subjected to by miscreants and similar actors. To cope with these conditions, different mitigations have been put in place throughout the years, but the attack vector remains unequivocally popular due to its relative simplicity.
What are subdomain takeovers?
There are significant risks associated with the loss of domain identity attributed to subdomain takeovers. And these typically occur whenever a subdomain (e.g., mail.google.com) is mapped to a service that has either been removed, mis-configured, or that has expired. According to Microsoft, dangling DNS records—the umbrella term that applies to such inconsistencies in DNS record-keeping—can predominantly serve as a common ground for front-end-based attacks such as phishing campaigns, cookie harvesting or stealing, clickjacking, and a host of additional XSS, CSRF, and cross-origin vulnerabilities. The attack’s general cadence would look as follows:
A cloud instance is provisioned and given a fully-qualified domain name (FQDN)—for example, cool-web-app-dev.azurewebsites.net; in DNS parlance, this is known as a canonical name. To route your visitors using a user-friendly alias instead, your DNS zone is updated by assigning a CNAME record (e.g., mysupercoolapp.mydomain.com) to the resource’s FQDN as specified in the previous step.
After some time, the cloud resource is set to be decommissioned as it is no longer needed. This leaves an important gap in the DNS record; essentially a subdomain pointing to a non-existing host. In one fell swoop, a threat actor scanning for orphaned assets like these is presented with a unique opportunity: the chance to re-provision an endpoint under his or her control, using the same canonical name as the original, so that all future visitors to mysupercoolapp.mydomain.com are redirected to the attacker’s content.
Consequently, a subdomain takeover lends itself to the creation of a phishing site that may include some sort of login mechanism or page—by doing so in combination with techniques such as spear phishing, for example, attackers can lure unsuspecting visitors and begin gathering credentials and other sensitive data in the process. By the same token, attackers can also establish an SSL presence that illuminates the path to further operations and tactics while boasting legitimacy.
From an end-user’s perspective, this sort of domain spoofing is utterly transparent, as browsers tend to inherently trust the underlying DNS resolvers by design. To informed cyber practitioners, the writing on the wall clearly spells further mischief; that is, the apex domain’s reputation is now effectively compromised by the mere existence of a doppelganger site that mimics the look and functionality of a legitimate, pre-existing one.
How Attack Surface Intelligence helps prevent subdomain takeovers
What does this all mean for organizations? Simply put, as the cloud footprint contracts and expands, DNS records that aren’t closely monitored (or even forgotten) can easily become gateways for attackers looking to circumvent stricter controls and gain a foothold in the environment.
So, is it game over? Not even close.
Although the mitigations surrounding dangling DNS records are certainly low-ceremony in nature, the idea is to always get to a sanitation point before bad actors can inflict any damage. As mentioned, however, the constant monitoring of highly dynamic web resources in the form of DNS records can be a daunting task. The general consensus is that regular checks must be conducted to ensure that the entire DNS inventory remains under close scrutiny by all incumbents.
But while subdomain lookup tools, and similar approaches, have generated some sort of positive outcome in the recent past, the reality is that they lack important features such as the ability to seamlessly locate rogue infrastructure or to elicit a clear and complete view of any underpinning third-party aggregates and vendor spaces; not to mention the amount of manual effort that’s required to correlate all these different data points in real time.
Enter Attack Surface Intelligence
Attack Surface Intelligence, or ASI, represents a new paradigm in which the entire public-facing digital ecosystem is brought into clear view through a continuous monitoring effort that seeks to eliminate traditional visibility gaps with the support of contextualized risk assessments and threat intelligence.
ASI gives you the most accurate representation of domain (and subdomain) health you can possibly imagine so that you can detect any misconfigured DNS records under a single roster:
As shown above, from this interface you can see all the newly observed subdomains added under Assets belonging to your organization. Furthermore, you can expand its view and see details about each one of them, as shown in the following screenshot:
These misconfigurations would normally show in the form of missing A or CNAME records (or both), expired domains, and recently decommissioned resources or apps, hopefully prompting an immediate mitigation response that would solve the disassociation.
Detecting popular subdomain takeover vulnerabilities
But what if ASI could detect popular cloud misconfigurations that may lead to subdomain takeover attacks?
AWS, Heroku, Wix, Shopify, and Microsoft Azure are just a few examples of popular cloud providers that are still affected by bugs that can open the path to successful subdomain takeover attacks on any organization.
Our Risk Rules module is the perfect ally when it comes to detecting such vulnerable services, as you can see from the following screenshot:
Let’s see some other examples of cloud misconfigurations we cover when it comes to preventing these kinds of attacks - this is not a comprehensive list of all the takeovers we detect. In fact, did you know that ASI is able to detect up to 60+ different types of account and subdomain takeovers across multiple platforms and providers?
|Microsoft Azure Takeover Detection||This critical vulnerability allows an attacker to take ownership of a domain name through remote code execution.|
|ElasticBeanTalk Subdomain Takeover Detection||ElasticBeanTalk subdomain takeover detected. A subdomain takeover occurs when an attacker gains control over a subdomain of a target domain. Typically, this happens when the subdomain has a canonical name (CNAME) in the Domain Name System (DNS), but no host is providing content for it.|
|Tumblr Takeover Detection||This vulnerability allows a remote attacker to take over a hostname pointed towards Tumblr by a CNAME DNS record.|
|Wix Takeover Detection||This subdomain takeover would only work on an edge case when the account was deleted. You will need a premium account (~ US$7) to test the takeover.|
|Herokuapp Subdomain Takeover||If a particular CNAME DNS record is pointed towards an unclaimed Heroku instance, it enables an attacker to take over the hostname in question.|
Again, prior to ASI, thickets of both hardware and software vulnerabilities besieged security teams with a logistic burden that was difficult to contend with; in essence, actionable security suffered from the lack of a cohesive alchemy between perimeter defenses and any relevant threat indicators. In a nutshell, ASI adds this unique dynamic perspective to the problem of looking at the attack surface from an external vantage point, mapping any significant exposures as they arise while keeping an ever-watchful ‘eye’ on the proverbial blind spots.
Understanding the subtle interplay between your provisioning strategy and the potential for subdomain takeovers that lurk in the alleyways of your DNS inventory will go a long way in preventing this type of attack. However, we all know that this can get extremely challenging when we consider the scaling complexities associated with cloud adoption and the difficulties in keeping a 24/7 accurate representation of all your assets under one roof.
The question remains whether or not your organization considers attack vectors like these a real problem—sadly, many still don’t. But the truth is that if we extend the lessons from previous cases, you’ll find that not only do they present an existential threat to your company’s brand and reputation, but there are obvious implications to be had from a loss of customer data. So the race is on.