On the other hand, and in terms of severity, DNS or NS takeovers are less common but create the highest impact. An NS subdomain takeover is similar in principle to other types of subdomain takeovers. And due to the major role that NS records play in internet traffic, and the possibility of attackers chaining multiple attack vectors, an NS takeover can lead to severe implications for the target organization.
For our new blog series Blast Radius, security professionals, researchers and experts deep dive into different attacks and vulnerabilities, explore how they can impact the entire internet ecosystem, and examine what they mean for organizations of all sizes, across all industries. To talk about the growing danger of DNS takeovers, we are joined by Patrik Hudák.
Patrik has been a regular on our blog, sharing about his latest research on subdomain takeovers, and has been a crucial resource for many in the bug bounty community. He began his research by studying other takeover methods and the different tools used to execute them before discovering the impact of DNS takeovers. While not that common, he has achieved many successes in bug bounty hunting with this particular vulnerability.
How companies can be affected
When a company hosts its DNS zones on a third-party DNS provider (such as AWS Route53), there is a possibility of DNS takeover (also known as NS takeover). Such a takeover happens when the DNS zone is removed from the DNS provider, but the DNS delegation link stays in play. If such an event happens, an attacker can register the same DNS zone on the same provider and host arbitrary records for such a zone. For more technical information, please refer to https://0xpatrik.com/subdomain-takeover-ns/.
Although this seems to be only a theoretical attack, there are numerous cases where this has actually occurred, even with large companies. Everybody who uses third-party DNS providers is affected if the process for the creation and removal of DNS zones is incorrect. Thus, companies of any size should audit their internal processes for such events.
There are, however, more tricky scenarios. Since DNS uses multiple nameservers for DNS zones for redundancy, sometimes only a subset of such nameservers is affected by DNS takeover.
Let’s say that domain “example.com” uses two nameservers: “dns.existingdomain.com” and “dns.nonexistingdomain.com”. The latter, as the name suggests, does not exist and thus cannot correctly serve requests for the “example.com” zone. From the usability perspective, there is no downtime. Every DNS request made for “example.com” is served by “dns.existingdomain.com” since DNS uses quiet fallback.
In this scenario, an attacker can exploit the non-existing nameserver simply by registering the domain name (if it is available) which would lead to becoming an authoritative nameserver for “example.com”. During the DNS request, the round-robin mechanism for choosing a nameserver is used—in other words, there is a 50% chance that while requesting DNS info for the “example.com” zone, it would hit the malicious nameserver. If it does, an attacker can serve arbitrary DNS results with the high TTL which would sit quietly in a cache for a long time.
Implications of DNS takeover
Firstly, DNS takeover is not that different from other types of takeover such as CNAME. One difference is that DNS takeover can cover multiple subdomains with different domain names. Since the attacker controls the DNS zone, she can create great FQDNs for phishing or other malicious activity. Let’s say that “sub.example.com” is affected by the DNS takeover. An attacker might take it further and create a new subdomain called “login.sub.example.com” on which she can host a phishing login page that looks exactly like the original.
When DNS takeover occurs, the DNS is essentially controlled by whoever recreated the zone. Such behavior is very dangerous since the browser implicitly trusts the DNS. In other words, cookies can be passed to incorrect hosts as well as the hijack of other same-origin policies. In the end, this could lead to XSS, authentication bypass, or hosting malicious files. Also, a takeover can be a chain with other high-profile attack vectors, such as data exfiltration to the domain and many more.
SSL certificates can be successfully generated as well. With the new mechanisms for domain verification, it is very easy to pass the verification challenge using either an HTTP- or DNS-based verification process. Once this passes, a valid SSL certificate is created which only enhances the appearance that the hosted content is indeed valid.
We shouldn’t stop at second-level domains. There was also a case where a researcher was able to take over an entire TLD! This means that he was able to control every domain register under this TLD (.io to be specific). This event showed that DNS takeovers happen if any link of the DNS delegation chain is vulnerable. Again, exploitation of such misconfiguration by malicious actors could result in catastrophic results.
Affected third-party DNS providers
AWS Route53 was the most targeted DNS provider for takeovers. When creating a new DNS zone, Route53 would assign four nameservers at random to the DNS zone from a pool of thousands. Such behavior was chosen to deliberately counter such takeovers. However, an attacker could easily “brute-force” the correct name server simply by creating and deleting the Route53 zones at a rapid pace. There was even an exception in paying policy, where Route53 wouldn’t bill the client if the DNS zone wasn’t alive for more than a couple of hours. This meant that the attacker could take over the Route53 domains pretty easily.
In May 2021, however, Amazon released the fix for this behavior by simply not assigning the same nameservers twice to the same DNS zone. This means that DNS takeover is mitigated on Route53. Personally, I had many successes with Route53 in my past bug bounties.
Recently a new project was created called “Can I take over DNS?” which lists DNS providers and explains whether zone recreation is possible, and if so, how. I honestly think this is a great resource for security researchers and bug bounty hunters. Any provider listed as “Vulnerable” should take time to address this issue in their own manner. While we can argue that DNS takeover is a fault of the customer itself for not taking all possible steps to mitigate the issue, the DNS provider can fully mitigate such risk, simply by implementing the measurements the way AWS Route53 did.
Impact on affected companies
DNS takeover can seriously impact a company. We’ve already talked about several implications, but these have been translated into their impact based on the context of a particular company. An attacker can also chain multiple implications to create an even more severe impact on the company.
- Light impact: This can simply be hosting arbitrary content, such as ads to generate money or some other harmless activity, or doing a “backlink farm” to improve SEO.
- Moderate impact: This can be hosting malicious content, or distributing malware using the company’s domain, which can significantly reduce the reputation of the company. Another instance can be hosting fake news that could lead to panic. If the company is publicly traded, posting catastrophic (albeit fake) news onto one of the subdomains can be seen as trustworthy, and lead to very bad consequences.
- Severe impact: This highly depends on context. One primary example is hosting a phishing login form, and using it for authentication bypass for a company’s customers and employees. Using other attack vectors can potentially result in internal network compromise.
I’ve noticed there are no in-depth posts about different types of subdomain takeovers except CNAME takeovers. The challenge is that there aren’t many known cases of successful subdomain takeover using NS records. But NS subdomain takeovers are indeed possible as seen here. And not only are they possible, but a successful DNS takeover can wreck havoc on companies’ internal networks and have a wide blast radius.