In the previous part of this series, we set up our free-tier account and then configured AWS CLI. In this article, we will discuss S3 buckets and the security concepts associated with them.
What is Amazon S3? Amazon Simple Storage Service (Amazon S3) is storage for the Internet. You can use Amazon S3 to store and retrieve any amount of data at any time, from anywhere on the web. You can accomplish these tasks using the simple and intuitive web interface of the AWS management console.
It is also possible to interact with S3 buckets and objects using AWS CLI as well as the Amazon S3 application programming interface (API) as a developer.
This section shows two different scenarios with S3 misconfigurations. We will explore both of these scenarios in turn: public bucket-public object, and private bucket-public object.
Public Bucket – Public Object
The AWS management console has a simple and easy-to-use interface to interact with S3 buckets.
Log into your AWS management console and navigate to Services | Storage | S3. It looks as shown below.
As you can see, there are no buckets available yet in S3. Let’s create a new bucket by clicking the + Create bucket button.
Enter a unique bucket name as shown in the preceding figure. This name must be unique across all the existing buckets in Amazon S3. In this example, labbucket123 was chosen to be the bucket name and is available.
Click Next, and you should see that all the properties (such as logging and encryption) are disabled by default. We’re not changing them now, so let’s click Next again and choose the permissions as shown below.
Finally click Next, review all the settings and click Create bucket.
Let’s simulate that we want to store some sensitive files in this bucket. We can do it by uploading an object into the bucket as shown below.
Once again, let’s choose permissions for this object as shown below.
Leave everything else to default and click Upload to upload the object to our bucket. It looks as shown below.
Now we have a vulnerable setup available on AWS. It is never recommended to expose sensitive data in S3 to the public without enforcing proper ACLs. However, this type of misconfiguration is commonly seen in various cases.
Finding Public S3 Buckets
Finding public S3 buckets is easy with automated tools and a wordlist that contains a list of bucket names.
Bucket Finder is a tool we can use to achieve this. This tool can be downloaded here.
This tool requires a wordlist, and it will check each word to see if that bucket name exists in Amazon’s S3. Here is the wordlist I have created for demo purposes:
Run the following command to get usage instructions.
Now, run the following command to start finding the S3 buckets available in the wordlist.
As you can see, the region is specified as the U.S. Bucket Finder found a bucket as expected. Now we can simply access the URL labbucket123.s3.amazonaws.com and we should be able to see the list of objects available.
As you can see in the above figure, the bucket has an object (data.txt) publicly accessible. Let’s access the URL and see if we can access its content.
That works! Another way to see the list of objects in a bucket is to use awscli, as shown below.
Now let’s see if we can write attacker-controlled objects to the target bucket. First, let’s create a new file named attacker.txt.
We can use awscli to upload an object:
Ethical Hacking Training – Resources (InfoSec)
The above figure shows that we are interacting with the S3 service and moving the attacker.txt file to labbucket123 bucket with the public-read ACL.
If we access the bucket once again, we should see the new object available in the bucket. Accessing the new object looks like this:
Private Bucket – Public Objects
Let’s create another bucket with the following permissions.
This new bucket is named labbucket122. The following figure shows that the newly-created bucket is not public.
Now, let’s create a new object in the labbucket122 bucket with the following settings.
Now, let’s run Bucket Finder by updating the wordlist with the new bucket name labbucket122.
As we can see in the above output, the new private bucket is found to be available, but access is denied. Accessing this bucket returns the following error.
However, if we access the object directly it will be accessible, since the object is made public even though the bucket is private.
This shows that we should properly understand the ACLs of buckets and objects and be extremely careful while exposing sensitive data in S3 buckets.
Note: AWS had a permission for S3 buckets which allowed any authenticated user to access the S3 buckets if they were configured to allow this. Many users were using this option and exposing their buckets to the public, assuming that only the owner could see those buckets. This option created a lot of confusion and appears to have been removed from the AWS S3 service now.
In this article, we discussed how S3 buckets can be publicly exposed and how an adversary can use automated tools to identify publicly-available buckets. We also used AWS CLI to upload new objects to misconfigured S3 buckets.