It was possible to claim the api.techprep.fb.com subdomain by registering the techprep-backend service on AWS Elastic Beanstalk.
Some of the text presented here is an excerpt from my original vulnerability report to Facebook, so the sentences being in present tense represent the time when I reported this to Facebook.
Summarizing the vulnerability
fb.com is in scope of the Facebook's Bug Bounty Program.
api.techprep.fb.com was pointed to techprep-backend.us-east-1.elasticbeanstalk.. via CNAME records. This Elastic Beanstalk URL in the us-east-1 region of AWS appeared to be removed by Facebook, and anyone having an AWS account with privileges to create Elastic Beanstalk instances in the North Virginia region could create one instance with techprep-backend.us-east-1.elasticbeanstalk.. as the URL. Therefore, there were dangling CNAME records at api.techprep.fb.com.
As a result of dangling CNAME records, if techprep-backend.us-east-1.elasticbeanstalk.. (which has been removed now) was claimed by an AWS user, he/she would have gained full control over api.techprep.fb.com as well.
To mitigate this issue, one simple step that could be taken would be to change or remove the CNAME records from the target sub-domain.
- Perform DNS lookup on api.techprep.fb.com, and you will find out that it is pointed to techprep-backend.us-east-1.elasticbeanstalk.. through CNAME records.
- Scan for all of the open ports, and also check whether techprep-backend.us-east-1.elasticbeanstalk.. resolves or not. You will find out that it doesn't resolve.
Reference for Step 2:
nmap -sV -O techprep-backend.us-east-1.elasticbeanstalk.com -Pn
Starting Nmap 7.91SVN ( https://nmap.org/ ) at 2020-12-20 00:08 +0545 Failed to resolve "techprep-backend.us-east-1.elasticbeanstalk.com". WARNING: No targets were specified, so 0 hosts scanned. Nmap done: 0 IP addresses (0 hosts up) scanned in 20.34 seconds
This shows that there are dangling DNS Records at this sub-domain.
This is a Dangling DNS Records issue. Previously, Facebook had done the following things:
- Pointing api.techprep.fb.com to the respective Elastic Beanstalk URL; i.e. techprep-backend.us-east-1.elasticbeanstalk.., and
- Creating an Elastic Beanstalk instance named "techprep-backend" in the US-East-1 region!
But during the time of reporting this vulnerability, Facebook appeared to have reverted the #2 point; i.e. deleting the Elastic Beanstalk instance.
Therefore, an attacker could create an Elastic Beanstalk instance in the same AWS Region with the same name, and hence claim the instance URL, and along with that, host his/her contents there, which means the same contents would appear in the FB.com's vulnerable sub-domain; i.e. api.techprep.fb.com.
To resolve this issue, Facebook needed to do one of the following:
- Change the CNAME records of api.techprep.fb.com to the Elastic Beanstalk instance URL that they currently own,
- Delete the CNAME records,
- Re-claim the respective Elastic Beanstalk instance URL before anyone else does in the US-East-1 region!
This Dangling DNS vulnerability could have been escalated to a Sub-domain Takeover vulnerability by registering a techprep-backend Elastic Beanstalk instance in the us-east-1 region in Amazon AWS.
Finding the vulnerability
I didn't do any form of manual work in finding this vulnerability, and my workflow was fully automated with Bash scripting.
I have shortened my actual script, and only included the part which helped me in finding this vulnerability in the following script. The part for Nmap scan is provided above in reproduction steps.
## Subdomain Enumeration echo "Checking with Assetfinder!"; assetfinder -subs-only fb.com >> ~/results/fb.com/subs/assetfinder.txt; echo "Checking with Subfinder!"; subfinder -d fb.com -recursive -silent -all -t 500 -o ~/results/fb.com/subs/subfinder.txt; echo "Checking with Sublist3r!"; sublist3r -d fb.com -n -t 500 -o ~/results/fb.com/subs/sublist3r.txt; echo "Checking with Amass!"; amass enum -passive -norecursive -noalts -d fb.com -o ~/results/fb.com/subs/amass.txt; ## Subdomain Concatenation cat ~/results/fb.com/subs/*.txt > ~/results/fb.com/subs.txt; ## Subdomain Enumeration Cleanup rm -rf ~/results/fb.com/subs; ## Subdomain Enumeration Results sort -u ~/results/fb.com/subs.txt -o ~/results/fb.com/subs.txt ## Elastic Beanstalk Checker while IFS= read -r domain; do if dig +short $domain | grep elasticbeanstalk; then echo $domain | tee -a ~/results/fb.com/elasticbeanstalk.txt; fi; done < ~/results/fb.com/subs.txt
Responsible Disclosure Timeline
- Report Submitted: Sunday, December 20, 2020 at 12:11 AM
- First Response from the team: Tuesday, December 22, 2020 at 2:07 AM
- My Response back to the team: Tuesday, December 22, 2020 at 2:28 AM
- Triaged (the team sent it to the appropriate product team): Monday, January 11, 2021 at 10:28 PM
- My Response: Monday, January 11, 2021 at 10:29 PM
- Patched Response: Tuesday, January 12, 2021 at 9:05 PM
- My Patch Confirmation: Tuesday, January 12, 2021 at 9:29 PM
- My Response: Thursday, January 21, 2021 at 10:18 PM
- My Response: Sunday, February 14, 2021 at 8:33 AM
- Rewarded $500: Tuesday, February 16, 2021 at 9:43 PM
- My Response: Tuesday, February 16, 2021 at 10:36 PM
One thing that they had said while rewarding the bounty amount is, "The payout amount reflects the fact that fb.com domain is predominantly used for microsites and static content."
Check out the Facebook Whitehat Thanks page of 2020: facebook.com/whitehat/thanks!