For the people who say we are on the cloud and it is implicitly secure :P

AWS NS Takeover

Shiv Sahni
Aug 12 · 4 min read

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.

Prerequisite

Before we go ahead and get our hands dirty you need to have a fair understanding of the following concepts:

  1. DNS(Domain Name Service)
  2. Fundamentals of AWS(especially Route53 service)

The Misconfiguration

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.

Remediation

The vulnerability has a very simple fix, you just need to remove the dangling nameserver entries corresponding to your domain.

Shiv Sahni

Written by

Security Engineer |Security Consultant |Infosec Trainer | Author | Lecturer | Open Source Contributor | Learner https://www.linkedin.com/in/shivsahni/

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade