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!

Image for post
Image for post

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

Image for post
Image for post

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.

Image for post
Image for post

In the scenario where AWS Route53 service is used, we would get the nameservers belonging to AWS as shown below.

Image for post
Image for post

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.

Image for post
Image for post

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.

Image for post
Image for post

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.

Image for post
Image for post

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.

Image for post
Image for post

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.

Image for post
Image for post

Remediation

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

Written by

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

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store