In this post, we will explore AWS services that can be taken over. For a deeper look at subdomain takeovers as a whole, check out our post on it. To detect them easily, check out our tool designed specifically for this purpose on GitHub.
Services are always being added to AWS so more may become available, but these are all known services vulnerable to takeover:
Elastic Beanstalk: elasticbeanstalk.com
S3 Bucket: s3.amazonaws.com
We have gone through each service, created examples, and shown how to take it over, step by step. Click on a specific service above to jump straight to it.
Elastic Beanstalk Takeover (elasticbeanstalk.com)
AWS Elastic Beanstalk (EB) is a managed service to help deploy and manage complete web application stacks with capacity provisioning, app health monitoring, and more.
When deploying an elastic beanstalk, you can optionally choose a DNS name and when you do, it could be taken over after you delete it. This name takes the form <dns-name>.<region>.elasticbeanstalk.com, for example:
gateway.eu-west-1.elasticbeanstalk.comIt's worth noting that if you don't pick the name, it will randomly generate an ID and tack it on the end of the environment name so it will have the format <env>.<id>.<region>.elasticbeanstalk.com, for example:
gateway.tcp2vzkpv3.eu-west-1.elasticbeanstalk.comIn this case, it's potentially possible to take over, a '.' is not allowed in the name so you can't register this directly but if you can register it in the same region with the DNS name tcp2vzkpv3, it wildcards all nested subdomains so it will still be possible to take over.
Finally, if the name is missing the region (e.g. gateway.elasticbeanstalk.com) then it's using the legacy format and impossible to take over.
Now that we know what is and isn't vulnerable, let's get to the good part! For this example, we created an elastic beanstalk instance on AWS with the DNS name "stratus-poc" in eu-west-1, mapped a custom domain (eb-poc.stratussecurity.com) to it and then deleted the EB instance to simulate a real-life takeover where a resource has been deleted but the DNS record remains.
The first step to taking it over is validation, we need to check it is actually vulnerable so let's manually check the domain eb-poc.stratussecurity.com points to a vulnerable beanstalk instance by using dig.
A vulnerable EB will return an NXDOMAIN status and point to elasticbeanstalk.com as shown above. The important part here is the first two parts, "stratus-poc" and "eu-west-1". To take it over, we need to go into the AWS console and navigate to the elastic beanstalk service. Once there, change the region to the one identified (eu-west-1 in this case) and create a new environment.
While creating it, the settings don't matter except the domain as shown in the screenshot below.
The rest of the steps can be stepped through and once the deployment is done, we will own the subdomain!
To validate, we can browse to eb-poc.stratussecurity.com and see our sample application is now up on the domain:
To host a more sophisticated PoC, follow the AWS docs on deploying a web app to Elastic Beanstalk.
S3 Bucket Takeover (s3.amazonaws.com)
Our second and final vulnerable AWS service is S3 Buckets. S3 buckets are a managed service to hold static files and are a very common source of subdomain takeovers due to their popularity and use of holding scalable static websites.
We will start this off just like Elastic Beanstalk by simulating a normal vulnerability by setting up an S3 bucket, pointing a CNAME record to it on s3-poc.stratussecurity.com and then deleting the bucket, exposing the vulnerability.
Unlike elastic beanstalk, a DNS lookup for S3 buckets will not return an NXDOMAIN status so we need to detect it differently. If we browse to the non-existant bucket it will return a HTTP 404 and a NoSuchBucket error as shown below, this means it is likely to be vulnerable.
Note: This looks very similar to Google Cloud Buckets which are not able to be taken over. Be sure to double check it actually points to AWS. S3 follows the format <name>.s3.<region>.amazonaws.com.
Now that we have found the vulnerability, we need to exploit it. We do not need to change the region in AWS, it will ask us during bucket creation. Below we are creating a bucket to take-over claim stratus-poc.s3.eu-west-1.amazonaws.com which is where the CNAME for http://s3-poc.stratussecurity.com is pointing.
While there, you might want to untick "Block all public access" so you can expose a PoC, the rest of the settings can be left as default.
Once the bucket is created, you have officially taken over the subdomain! Despite this the subdomain itself won't look any different yet, there are a few more steps to go through. Next, we need to upload the file for the poc to prove you have taken it over.
I will just upload a simple file called poc.txt but you can upload anything you want, on the below screen you just need to click "Add files" and hit upload:
You might think that's it, but we're not done yet! S3 tries hard to stop people from accidentally exposing files, so you need to go back to your bucket screen, click the permissions tab at the top and add the following policy to expose the contents to the internet:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::your-bucket-name/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "0.0.0.0/0"
}
}
}
]
}Once saved, you are done! We can browse to poc.txt on the subdomain to validate that everything worked properly.
