For the people who say we are on the cloud and it is implicitly secure :P
AWS NS Takeover
From 101 to Detection and Exploitation!
I hope you would have heard of a conventional subdomain takeover because of a dangling CNAME entry. Recently while going through these amazing blogs( Taking Over 120K Domains via a DNS Vulnerability in AWS, Google Cloud, Rackspace and Digital Ocean and Subdomain Takeover: Going beyond CNAME) I got to know about this cool, non-conventional domain takeover which allows an adversary to have complete control over a vulnerable domain.
Before we go ahead and get our hands dirty you need to have a fair understanding of the following concepts:
Usually while setting up a domain, we avail domain registration services from the registrar and provide the authoritative nameservers which stores and provides the respective DNS resource records. The security issue is regarding the misconfiguration while setting up authoritative nameservers for a domain.
To query the nameserver(s) corresponding to a domain we can simply use any DNS client such as dig, host, etc. to fetch the NS resource records. As shown below ns1.google.com, ns2.google.com, ns3.google.com and ns4.google.com are the authoritative nameservers for google.com.
In the scenario where AWS Route53 service is used, we would get the nameservers belonging to AWS as shown below.
Whenever we use AWS Route 53 service for managing DNS, usually AWS allocates four nameservers from its pool of nameservers which becomes authoritative nameservers for that domain and are responsible for returning the corresponding resource records.
The misconfiguration occurs when we are using AWS Route53 service for managing the DNS and the associated nameservers do not have the corresponding zone files. This could occur in the scenario where the administrator while deleting domain deletes the hosted zones from AWS Route 53 but forgets to remove the dangling pointer at the domain registrar.
In such cases, we usually get the SERVFAIL error message during DNS lookups as shown below.
Since AWS uses a common pool of nameservers to assign an authoritative nameserver for a domain and there is no explicit check performed by AWS to check if the domain belongs to you before creating the zone files for it, we can exploit this misconfiguration by creating zones indefinitely until it matches one of the target nameservers. Once that is done, we can create the record sets to take over the domain.
I have created NSBrute utility that automates the exploitation part and allows you to take over the domain for generating valid POCs.
For using NSBrute you would be needing programmatic access to AWS account and using your AWS access key and secret key you can perform NS takeover on the vulnerable domain as shown below.
The script would be indefinitely creating the zones for the vulnerable domains in your AWS account until it finds a zone with a common nameserver.
Once the script creates a zone with a common nameserver you can log in to your AWS account to create the resource records for the domain to have the complete control over the domain.
The vulnerability has a very simple fix, you just need to remove the dangling nameserver entries corresponding to your domain.