---------------------------------------------------------------------------------------------------- $$\ $$\ $$$$$$\ $$\ $$\ $$ | $$ | $$$ __$$\ $$$$ | $$ | $$$$$$\ $$$$$$\ $$$$$$\ $$$$$$$\ $$$$$$$ | $$$$$$\ $$$$\ $$ |\_$$ | $$$$$$$ | $$ __$$\\_$$ _| \____$$\ $$ __$$\ $$ __$$ |$$ __$$\ $$\$$\$$ | $$ | $$ __$$ | $$ | \__| $$ | $$$$$$$ |$$ | $$ |$$ / $$ |$$ | \__|$$ \$$$$ | $$ | $$ / $$ | $$ | $$ |$$\ $$ __$$ |$$ | $$ |$$ | $$ |$$ | $$ |\$$$ | $$ | $$ | $$ | $$ | \$$$$ |\$$$$$$$ |$$ | $$ |\$$$$$$$ |$$ | \$$$$$$ /$$$$$$\\$$$$$$$ | \__| \____/ \_______|\__| \__| \_______|\__| \______/ \______|\_______| ---------------------------------------------------------------------------------------------------- by: andr01d

Amazon's AWS is an extremely popular cloud hosting service due to the ease of deployment and the different tiers of accounts you can operate. Along with hosting your typical web servers and other operating systems, Amazon offers S3 buckets. S3 buckets operate much like a cloud file server, with its own set of capabilities. While one can use these buckets to share files across an organization, it is common to host web pages on a bucket. AWS also allows you to create DNS records which point to Amazon's s3 domain, meaning you can use an s3 bucket to host a full-scale web application and serve it to the public.

The Setup

In order to replicate this attack, we need to understand how one would become vulnerable to the attack. Let's say I create a subdomain for my website 'rtandr01d.net'. Initially, I create a CNAME DNS record to point to Amazon's s3 bucket domain, plugging in the name of the s3 bucket I want to create.

We can verify the existance of our DNS records by using the 'host' command which shows the domain pointing to the s3 domain.

Next create my bucket and sync whatever files I would like to share. In this case, lets assume I am creating a simple webpage that I will later migrate to a more permanent domain and bucket. Once I am ready to migrate the files, I sync my files across the two different buckets using the awscli.

aws s3 sync s3://beta.rtandr01d.net s3://prod.rtandr01d.net

Now that I have moved all my files to the production bucket, I delete the original bucket 'beta'.

aws s3 rb s3://beta.rtandr01d.net --force

The Attack

Now that my bucket is deleted and my files have been synced to the production bucket, I am done, right? The first steps in any good attack path is enumeration. One of these first steps is subdomain enumeration, where we attempt to find existing subdomains attached to our target domain which have either interesting web applications or information we may use down the line in our attacks. While running our subdomain enumeration, we notice one that sticks out: beta.rtandr01d.net. This subdomain does not wildcard like the rest of the subdomains, so we take a look at what this could be. Initially, we runa 'host' command (like when we were verifying the setup of our DNS records) and find the subdomain points to the Amazon s3 domain. To verify this, we can browse to 'oursubdomain.s3.amazonaws.com' and we see that the bucket does not exist!

If this subdomain is pointing at s3, but there is no bucket that exists, maybe we can register a bucket using the same name and take over the subdomain? To try this, we can create the bucket using the 'awscli' included in most linux package managers. Note, however, you need at least a free-tier AWS account in order to create an s3 bucket. We begin by creating the bucket:

aws s3api create-bucket --bucket beta.rtandr01d.net

You should get the message: "Location": "/beta.rtandr01d.net"

Next we want to create a policy which allows everyone to see and read our files. Below I have included the basic example policy to allow all to read the files anonymously. Note: Replace "todays-date" with your current date in the "YYY-MM-DD" format, and replace "DOC-EXAMPLE-BUCKET" with the name of the bucket you just created.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "PublicRead", "Effect": "Allow", "Principal": "*", "Action": [ "s3:GetObject", "s3:GetObjectVersion" ], "Resource": [ "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*" ] } ] }

Put this in a file called s3policy.json and update the bucket's policy with awscli:

aws s3api put-bucket-policy --bucket beta.rtandr01d.net --policy file://s3policy.json

Now we own the bucket and it is open to the public. We need to upload files and tell the bucket to treat it as a webpage. Create a directory, in my case 'static', and create an html page called 'index.html' You can put whatever you want in this file. Start by syncing the directory to the bucket:

aws s3 sync ./static s3://beta.rtandr01d.net

Then tell the bucket to treat index.html as the root page:

aws s3 website s3://beta.rtandr01d.net --index-document index.html --error-document index.html

Note: I have had a few instances where in order to make the site host the index.html page as the root page, I must go to the "Block public access" section of my bucket's settings, edit the settings and confirm all are de-selected, even if it already shows the blocking of permissions as 'off' Now, we have our site all set up! We can browse to our site and...

The Conclusion

Now we have our subdomain and can host whatever we want here. There are a few uses to attackers a subdomain could provide: 1. Use the subdomain for an advanced Phishing attack as the domain would be instantly recognizable to employees 2. Defacing by publishing false or obscene information and spreading a link to the site claiming it is the original site 3. Potential web c2 framework with bots reporting via HTTP requests to upload/download information from bucket

How could we have prevented this attack?

The main cause for the success of this attack is a DNS record which still pointed to a non-existant Amazon s3 bucket. When you are done with a subdomain (you have migrated to a more permanent place), be sure to clear any redudant or unused subdomain entries.