Dangling DNS in cloud infrastructures

Dangling DNS entries are nothing new. Forgotten, outdated or incorrect DNS records can lead to subdomains being taken over and used in phishing campaigns, for example, to steal employee secrets. Due to dynamic IP addresses of rapidly changing resources from various cloud providers, the risk of forgetting or not updating DNS entries has increased significantly. The following is an example of how dangling DNS entries are created, what a possible attack scenario could look like and how you can protect yourself against it.

Dangling DNS

Dangling DNS describes a security vulnerability caused by outdated DNS entries. Specifically, one speaks of Dangling DNS entries if, for example, subdomain configurations point to IP addresses that are no longer in the possession of the administrators. These outdated entries are often caused by short-lived resources or dynamic IP addresses in the cloud environment. A lack of monitoring also ensures that these dangerous configurations are not detected.

Why is this especially true for cloud infrastructures?

Quickly changing resources and elastic IP addresses ensure rapid changes. Addresses can be registered and released again quickly and automatically. It is therefore conceivable, for example, that IP addresses are registered and released again until the desired address has been assigned. Amazon AWS also allows desired IPs to be reserved from the address pool of the respective region, provided they are available.

The attack scenario

In this theoretical example scenario, a Dangling DNS entry is identified by an attacker.

dangle.insecure-coorp.com

The A-record entry points to an IP address from the AWS address pool.

~ > dangle.insecure-coorp.com

Server: 10.0.0.2
Address: 10.0.0.2#53

Non-authoritative answer:
Name: dangle.insecure-coorp.com
Address: 52.28.242.149

In this fictitious example, the stored IP address is not assigned, comes from the AWS address pool and can therefore be specifically reserved by the attacker using aws-cli. This functionality is not available in the web portal and can only be used with aws-cli.

aws ec2 allocate-address --domain vpc --region <region> --address <WISH-IP>

What is still missing to be able to use the transferred subdomain is a valid certificate. Let's Encrypt offers various ways to prove that a domain is under the control of the administrators. The following are the most common challenge types:

• By DNS record (DNS Challenge)
• By providing an HTTP resource (HTTP Challenge)

The first variant cannot be used by attackers as they do not have control over the DNS entries. With the DNS challenge, a DNS entry must be stored that was specified by Let's Encrpyt and is regularly validated.

The second variant works, however, as only a web server needs to be set up under the newly registered IP address in order to deliver the specific Let's Encrypt challenge-response resource. Let's Encrypt specifies which resource must be offered at which position. With this variant, there is therefore no need to have access to the domain. After successful validation, the attacker has a valid server certificate for the subdomain taken over.

Automation

At this year's Def Con 32, the topic was presented by Matt Pawloski. During his analysis, he developed the Pay Dirt tool to automatically search for Dangling DNS records in Amazon AWS and Digital Ocean. The tool iterates over the reserved IP address ranges of the cloud providers and checks the DNS entries. If a Dangling DNS entry is found, the tool automatically attempts to register the IP address found (in the case of AWS). As Digital Ocean does not support the registration of a desired IP, only the incorrect entry is output in this case.

Countermeasures

A suitable countermeasure is good monitoring. DNS entries should be automatically checked for changes on a regular basis. A notification should be sent automatically to the administrators in the event of a change. The certificates used should also be monitored. For example, if a Let's Encrypt certificate is detected in an environment in which Let's Encrypt is not normally used, the administrators should also be notified. Either monitoring solutions already in use or small tools such as certspotter can be used to monitor certificates

To avoid this situation from the outset, cloud resources should be managed reliably (automatically) and carefully. If cloud resources are deleted, the associated DNS entries must always be removed.

Sources

• certspotter
• Pay Dirt
• Let's Encrypt