Elastic Beanstalk is a service on Amazon Web Services (AWS) that allows user to deploy and scale web application and services. This service is very user friendly when it comes to web application deployment. User just need to upload their code and elastic beanstalk will automatically handle the deployment and you just need to point out the CNAME of that service to your DNS records. CNAME (Canonical Name) is nothing but just an alias of a subdomain. You can think it as a nickname of a subdomain also.
Elastic Beanstalk takeover is an interesting one and also rare to find these days on internet. So, the idea to takeover elastic beanstalk started with a normal day when @Smaran Chand was talking elastic beanstalk takeover on AWS. We were group of 3 people (Smaran Chand, me and Niraj Khatiwada) in our Research and development team. We decided to check if we could find any subdomain on either bug bounty programs or on internet itself to just play around with the subdomain takeover of elastic beanstalk.
This vulnerability arises when a developer use the elastic beanstalk service to host the application and then simply delete that service when it is no longer in use and thinks that it’s done but they forget to remove CNAME record pointing to elastic beanstalk from their DNS records.
Luckily, I found one subdomain of a target vulnerable to this subdomain takeover. Let’s see how anyone following these steps can takeover vulnerable subdomains pointing to 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 internet that had suffix elastic beanstalk in the subdomain name.
Fig: Browsing vulnerable subdomain
Then, I simply used dig utility tool to find out the CNAME pointing to this sub domain 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 takeover the NX subdomain.
Fig: Digging CNAME record for vulnerable subdomain
After finding the CNAME record, I browsed the CNAME in browser to confirm if it is also NX or not.
Fig: Browsing vulnerable CNAME record to confirm takeover
After this, I navigated to AWS console and changed my profile region to same ap-northeast and claimed a domain for elastic beanstalk service with the suffix of vulnerable CNAME record.
Fig: Claiming vulnerable CNAME record
The vulnerable domain name was available and i started deploying a sample application in node.js platform.
Fig: Deploying sample application on that vulnerable subdomain
The deployment took only few seconds and the sample application was successfully deployed on the claimed domain name.
Fig: Deployment Successful
As shown in the figure below, a sample application is deployed on domain of other organization. This can be used to harvest user credentials, deface the website, and redirect traffic of this website to somewhere else and many more depending upon the creativity level.
Fig: Successful Takeover of subdomain pointed at elastic beanstalk service
After this, I ethically reported this vulnerability to the organization and got appreciation for finding issue in their organization asset.
Hope you liked reading it and won’t miss subdomain takeover like this in future.
Peace Out !!
