Dangling DNS Records on Amazon EC2 By Binit Ghimire

Complete Details 

A few months back, one of my friends found a Dangling DNS Record vulnerability in a sub-domain of Internet.org, and he shared me his strategy on how he did that. So, today I decided to automate the process and look up for similar vulnerabilities across all of the in-scope domains of Facebook, and I found out one such issue in another sub-domain of Internet.org; i.e. surf-test.xwf.internet.org.

The target sub-domain, surf-test.xwf.internet.org is pointed to an Amazon EC2 instance hostname (ec2-54-169-74-233.ap-southeast-1.compute.amazonaws.com) through CNAME records, and this hostname is based on top of one of the IP addresses (i.e. 54.169.74.233) from Amazon AWS' pool of IP addresses. 

There are three reasons why the Dangling DNS Record issue could be persistent in this case: 

1 Either the Internet.org team from Facebook released this IP address from their list of allocated elastic IP addresses in their AWS account; 

2 OR, it wasn't even an elastic IP address, which means when the EC2 instance was shut down and started again, the IP address got changed (this is how EC2 IP addresses are assigned when an Elastic IP Address isn't assigned) and the team forgot to change the DNS records to the new hostname or IP address; 

3 OR, the team just allocated created the EC2 instance for certain purpose, created the CNAME records for that sub-domain pointing to the EC2 instance, and then shut down or terminated the EC2 instance later on, but forgot to change or remove the DNS records for the target sub-domain. 

In AWS, anyone's EC2 instances might be assigned any of the IP addresses from their pool of IP addresses randomly based on their AWS region selection, and in this case, if any user in the ap-southeast-1 region tries creating an EC2 instance and he/she gets assigned this IP address, then the target sub-domain will be under the control of that user. Therefore, the target sub-domain as mentioned earlier is vulnerable to Dangling DNS Record. 

Impact 

Since the IP address is no longer associated with the EC2 instance for which the target sub-domain is meant to be pointed to and is now in the pool of available IP addresses in AWS, whenever this IP address gets assigned to anyone's EC2 instance in the ap-southeast-1 region, then that person will have full rights over anything to do or host on top of the vulnerable sub-domain at Internet.org; i.e. surf-test.xwf.internet.org 

Reproduction Steps 

Step 1. Perform DNS lookup on the target sub-domain: surf-test.xwf.internet.org! You can use the "dig" command in your Linux terminal, and pass the sub-domain as the first argument, or you may even use the "+short" flag to just view the actual thing we need. 

Sample Commands:

dig surf-test.xwf.internet.org
dig +short surf-test.xwf.internet.org

Step 2. When you perform DNS lookup on the target sub-domain, the results in the "ANSWER SECTION" would appear as below:

";; ANSWER SECTION:
surf-test.xwf.internet.org. 42 IN CNAME ec2-54-169-74-233.ap-southeast-1.compute.amazonaws.com.
ec2-54-169-74-233.ap-southeast-1.compute.amazonaws.com. 142 IN A 54.169.74.233"

You can see the sub-domain is pointed to an EC2 instance hostname through CNAME records, and the hostname is further assigned to an IP address from the pool of AWS IP addresses (you can verify by performing: whois 54.169.74.233). Now, for checking whether the DNS records are dangling or not, you can perform a nmap scan like with this command:

nmap -sV -p- -O 54.169.74.233

It will show that the host seems down, which means there is no valid host running on this IP address, hence verifying that the DNS records are dangling. 

Mitigation/Remediation Actions 

To mitigate this issue, one simple step that can be taken would be to change or remove the CNAME records from the target sub-domain. Suggesting Materials or References https://medium.com/@nabeelxy/dangling-dns-records-are-a-real-vulnerability-361f2a29d37f https://medium.com/@mohamed.elbadry/dangling-dns-aws-ec2-e2d801701e8 

 Thanks, Binit Ghimire