Dangling DNS Records on surf-test.xwf.internet.org (Amazon EC2)!

The "surf-test.xwf.internet.org" subdomain was pointing to a AWS EC2 hostname that the Internet.org team had removed, making it susceptible to hijacking.

Summarizing the vulnerability

When I was looking for Dangling DNS records across the assets of multiple targets in December 2020, I came across a sub-domain of Internet.org; i.e. surf-test.xwf.internet.org, which was pointing to Amazon EC2.

The target sub-domain, surf-test.xwf.internet.org was pointed to an Amazon EC2 instance hostname (ec2-54-169-74-233.ap-southeast-1.compute.am..) 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 have been persistent in this case:

Either the Internet.org team from Facebook released this IP address from their list of allocated elastic IP addresses in their AWS account;
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;
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 had tried creating an EC2 instance and the instance was to be assigned with this IP address, then the target sub-domain would have been under the control of that user. Therefore, the target sub-domain as mentioned earlier had Dangling DNS records, and hence it was susceptible to hijacking.

Since the IP address was no longer associated with the EC2 instance for which the target sub-domain was meant to be pointed to and was then in the pool of available IP addresses in AWS, whenever this IP address would have been assigned to anyone's EC2 instance in the ap-southeast-1 region, then that person would have had 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.

To mitigate this issue, one simple step that could be taken would be to change or remove the CNAME records for the target sub-domain.

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 (possibly) dangling.

Further Notes

Please note that this isn't a sub-domain takeover vulnerability even though there is a possibility for sub-domain takeover (or hijacking)!

Vulnerability Discovery

I have included my script, which I used in discovering this vulnerability below.

## Subdomain Enumeration
    echo "Checking with Assetfinder!";
    assetfinder -subs-only internet.org >> ~/results/internet.org/subs/assetfinder.txt;
    echo "Checking with Subfinder!";
    subfinder -d internet.org -recursive -silent -all -t 500 -o ~/results/internet.org/subs/subfinder.txt;
    echo "Checking with Sublist3r!";
    sublist3r -d internet.org -n -t 500 -o ~/results/internet.org/subs/sublist3r.txt;
    echo "Checking with Amass!";
    amass enum -passive -norecursive -noalts -d internet.org -o ~/results/internet.org/subs/amass.txt;

## Subdomain Concatenation
    cat ~/results/internet.org/subs/*.txt > ~/results/internet.org/subs.txt;

## Subdomain Enumeration Cleanup
    rm -rf ~/results/internet.org/subs;

## Subdomain Enumeration Results
    sort -u ~/results/internet.org/subs.txt -o ~/results/internet.org/subs.txt

## Amazon EC2 Checker
while IFS= read -r domain; do
    if dig +short $domain | grep ec2; then echo $domain | tee -a ~/results/internet.org/ec2.txt; fi;
done < ~/results/internet.org/subs.txt

The script performs sub-domain enumeration over the Internet.org domain using assetfinder, subfinder, sublist3r and amass, and then checks for sub-domains which are further pointing to Amazon EC2 hostnames, and stores all of the results in a text file.

I didn't perform any form of manual work in discovering this vulnerability, and my workflow was fully automated with the help of Bash scripting using different tools.

After retrieving the results as mentioned earlier, you can simply perform a Nmap scan for all ports across the sub-domains with Amazon EC2 hostnames, and if no ports are up, you can try reporting the vulnerability to the vendor (i.e. in this case, it's Facebook.).

Here's a sample Nmap command that you can use: nmap -sV -p- -O <hostname or IP>

In the script that I have provided, I have only included the part of the script, which helped me in finding this vulnerability, which means I have removed the hostnames checking abilities for AWS Elastic Beanstalk and Amazon S3.

Responsible Disclosure Timeline

Reported: Saturday, December 19, 2020 at 11:35 PM
Automated Response: Saturday, December 19, 2020 at 11:35 PM
First Response from the Team (successful reproduction): Tuesday, December 22, 2020 at 8:55 PM
My Response back to the Team: Tuesday, December 22, 2020 at 9:18 PM
Triaged (the team sent it to the appropriate product team): Wednesday, December 23, 2020 at 3:44 AM
My Response back to the Team: Wednesday, December 23, 2020 at 4:19 AM
Response from the Team (requesting to try taking over): Wednesday, January 6, 2021 at 1:13 AM
My Response back to the Team (explaining about random IP address allocation for Amazon EC2 instances from the AWS' pool of IP addresses): Wednesday, January 6, 2021 at 9:14 AM
My Response back to the Team: Wednesday, January 27, 2021 at 10:36 PM
Response from the Team: Thursday, February 11, 2021 at 4:45 AM
My Response back to the Team: Thursday, February 11, 2021 at 4:55 AM
Patched Response: Monday, March 1, 2021 at 8:00 PM
My Patched Confirmation: Wednesday, March 3, 2021 at 12:54 AM
Rewarded $500: Tuesday, March 9, 2021 at 8:49 PM
My Response: Wednesday, March 10, 2021 at 11:49 AM

Check out the Facebook Whitehat Thanks page of 2020: facebook.com/whitehat/thanks!

Read what Binit writes @ WHOISpublish!