Read the proper write-up here: https://publish.whoisbinit.me/amazon-ec2-dangling-dns-records-on-surf-test-xwf-internet-org!
In this GitHub Gist, I have included my script (main.sh), which I used in discovering this vulnerability.
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 multiple text files.
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-domainss 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 file (main.sh) 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.
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:
- 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 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.
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
- Users: N/A
- Environment: N/A
- Browser: Any web browser!
- App version: N/A
- OS: I am using Debian 10 (Buster), but you can use any OS available out there.
- Description: Internet.org is an in-scope asset of Facebook's Bug Bounty Program.
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.
dig surf-test.xwf.internet.orgdig +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.
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.
- https://medium.com/@nabeelxy/dangling-dns-records-are-a-real-vulnerability-361f2a29d37f
- https://medium.com/@mohamed.elbadry/dangling-dns-aws-ec2-e2d801701e8
Thank You, and have a nice day!
Thanks,
Binit Ghimire
- 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: Yesterday at 8:49 PM
- My Response: Today at 11:49 AM
Please note that this isn't a sub-domain takeover vulnerability even though there is a possiblity for sub-domain takeover!
If you have any questions regarding the contents of this gist, please feel free to let me know through the comments!