Sahil OjhaElastic Beanstalk is a service on Amazon Web Services (AWS) that lets users deploy and scale web applications and services. It is very friendly when it comes to web application deployment.
Users just need to upload their code, and Elastic Beanstalk handles the deployment automatically. They only need to point the CNAME of that service to their DNS records. A CNAME, or Canonical Name, is nothing but an alias of a subdomain. You can think of it as a nickname for a subdomain.
An Elastic Beanstalk takeover is an interesting one, and also rare to find these days on the internet. The idea started on a normal day, when @Smaran Chand was talking about Elastic Beanstalk takeover on AWS. We were a group of three people, Smaran Chand, Niraj Khatiwada, and me, in our research and development team. We decided to check whether we could find any subdomain, either on bug bounty programs or on the internet itself, to play around with the subdomain takeover of Elastic Beanstalk.
This vulnerability arises when a developer uses the Elastic Beanstalk service to host an application and then simply deletes that service when it is no longer in use, thinking the job is done, but forgets to remove the CNAME record pointing to Elastic Beanstalk from their DNS records.
Finding a vulnerable subdomain
Luckily, I found one subdomain of a target vulnerable to this subdomain takeover. Let's see how anyone following these steps can take over vulnerable subdomains pointing to the Elastic Beanstalk service. This takeover was possible with just a tweak in the subdomain enumeration methodology. I had enumerated all the possible subdomains or targets on the internet that had the suffix elasticbeanstalk in the subdomain name.
Then I simply used the dig utility to find the CNAME pointing to this subdomain manually. As shown in the figure below, it was pointing to KXXXXX-eproduction.ap-northeast-1.elasticbeanstalk.com. It is very necessary to find out the zone in which the Elastic Beanstalk is deployed, because using the right zone is required to successfully take over the NX subdomain.
After finding the CNAME record, I browsed the CNAME in the browser to confirm whether it was NX or not.
Claiming the domain
After this, I navigated to the AWS console, changed my profile region to the same ap northeast, and claimed a domain for the Elastic Beanstalk service with the suffix of the vulnerable CNAME record.
The vulnerable domain name was available, and I started deploying a sample application on the Node.js platform. The deployment took only a few seconds, and the sample application was successfully deployed on the claimed domain name.
As shown in the figure below, a sample application is now deployed on the domain of another organization. This can be used to harvest user credentials, deface the website, redirect the traffic of this website somewhere else, and much more, depending on your creativity level.
After this, I ethically reported this vulnerability to the organization and got appreciation for finding an issue in their asset.
Hope you liked reading it, and won't miss a subdomain takeover like this in the future.
Peace out!
Sahil