Unwanted public S3 buckets are a continuous threat. They have been (and still are) causing havoc all over the web. There are several tools out there to help your company with finding public S3 buckets. They are almost all standalone scripts or lambda functions that query the AWS APIs via some sort of SDK (Python, Node.js, etc.).
But when centralized security is implemented, as we have done so at Auth0, this task can be performed using a data lake or any sort of system/service where logs are aggregated, analysed, and acted upon. In that regard, the first source for your AWS events is CloudTrail.
Digging around the Internet we didn’t find enough resources that explained to us the different ways an S3 bucket can be made public and how to detect it in raw CloudTrail logs, so we started playing around, running tests and building queries to find that out. This blog post will guide you through our process, our findings, and our solutions.
Bitdefender compiled a list of the 10 worst Amazon S3 breaches.
Before getting into the technical details, let’s have an overview of the context in which those tests were running, which technologies were involved, and how we linked them all together.
We’ve tested the creation of buckets in two ways: via the AWS command line interface (
aws CLI) and the web console. We’ve also tested policy changes, both access control lists (ACLs) and individual permissions.
We wanted to cover all the possible ways that a user, malicious or not, could use to create a public S3 bucket: by mistake, for data exfiltration, or for command and control (yes, you can use it even for that, my dear pentester friends).
“Data exfiltration, also called data extrusion, is the unauthorized transfer of data from a computer.” (TechTarget)
As a Security Information and Event Management (SIEM) solution we’re working with Sumo Logic. We send all logs to it and we’ve designed the CloudTrail logs coming from every AWS account to be collected in a centralized S3 bucket that is “drained” by the Sumo Logic collector and organized in the source category named
“We wanted to cover all the possible ways that a user, malicious or not, could use to create a public S3 bucket. Learn more on how to do it.”
The S3 Bucket Permission Model
Let’s have a quick overview of the type of permissions an S3 bucket can have and how they can be used to make one public.
For a complete and detailed explanation, we highly recommend reading the official AWS documentation.
The easiest way to setup a bucket public is to use the canned policy
public-read on the bucket. By default, both via the web console and the command-line interface (CLI), the buckets are created with an ACL
Canned ACLs provide an easy and quick way to set up global permissions in one shot. However, one can apply specific policies to grant or deny access to specific entities.
, and are definitely self-explanatory and apply to every object on the bucket (and the bucket itself). The Adjacent Channel Protection (ACP) part of the other permissions are related to the ACLs: with those permissions granted, an user can read and/or write the ACL (but not the objects).
Those policies go together with the entity to which they are attached. More specifically, the Grantee. A Grantee is an object who holds three or four basic pieces of information (depending on the type): the type of the grantee (
Group), the XML XSI schema and the ID (in case of a type CanonicalUser) or the URI (in case of a type Group). CanonicalUser types also carry a
DisplayName property, not present in the Group ones.
As a security best practice, you should watch out for
Policies are a tricky way to allow/disallow actions on the bucket’s object. Even if the bucket is created with a canned ACL that sets it to private, by adding a very basic policy we can make the whole bucket public. The policy to do that is as simple as:
AWS is able to recognize the effect of such policy and will show the “Public” tag on the bucket. While detecting the above policy is doable, detecting these kind of scenarios is a tricky task. Evaluating the impact that a policy could have on the bucket and its objects is something that cannot be done on a SIEM, but it requires external tools to simulate the policy, analyze the results, and evaluate the risks.
As Rich Mogull points out on his article on how S3 buckets become public, the way permissions are evaluated is bucket policies first and then bucket ACLs (both canned and extended). Of course, an explicit deny always takes precedence, regardless of where it is stated.
“For S3 buckets, the way permissions are evaluated is bucket policies first and then bucket ACLs. Learn more how this affects your security in the cloud.”
S3 objects do inherit parent bucket’s permissions, but they can also have their own ACL that can bypass such permissions. You can make single objects public while the bucket ACL states it’s private, although to access that object one must know the full path to it. While this is a security concern that you should address, it’s out of the scope of this article.
We were interested in knowing how many ways those policies can be applied and how they show up in Cloudtrail, so we ran several tests with different parameters to experiment and build up our Sumo Logic detection query.
Detecting Bucket ACLs: The Command Line Way
First shot was to alert on something we were familiar with: canned ACLs. The easiest way to create a public bucket with such policies is via the command line.
We used the following CLI command to create a bucket with a public-read policy:
We specified in the first row the “CreateBucket” event action to speed up the filtering process. We then parsed some of the fields to be able to apply some logic. You can notice the
requestParameters.x-amz-acl which is named
acl and the following
where acl matches "*public*". In this way we are not only detecting the
public-read ACL, but also the
Note that, since the username is the assumed role, the real user who assumed that role is not exposed, making attribution a little bit harder (depending on how your team structures IAM roles and users).
Detecting Bucket ACLs: The Web Console Way
Funny enough, you cannot create a bucket with a canned ACL straight from the web console wizard. To apply a canned ACL, first you have to create the bucket and after that you have to manually set the “Everyone” permission on it. By enabling the following properties, you can get:
From this event data, there are a few items that call for our immediate attention:
requestParameters field is where all the magic happens: a new field appear as
AccessControlPolicy.AccessControlList.Grant (reported as JSON syntax here). Grant keeps a list of all the
Grantee, i.e. entities who have access to the bucket. There are several entities that we can find on the aforementioned links above. We will focus only on the following:
That grantee is clearly something we don’t want, regardless of the permission associated to it.
We can then add it to the new Sumo Logic query, paying attention to adding the new event type (PutBucketAcl) and the new headers we found:
More Ways to Detect a Public Bucket Using the CLI
We have seen how to detect public S3 buckets created with a canned ACL (via the command line) and created with “Everyone” permissions via the web console.
There is another way we can make an S3 bucket public: by specifying the Grant ACP permissions via the command line.
The concept is the same as clicking on the Everyone group on the web console, something we already discussed on the previous section. Via the command line, however, AWS adds new headers that are not present in the web console activity, thus we risk to lose events if we don’t add them to our query.
Starting off our last Sumo Logic query, we can easily integrate this new information:
In this article we’ve learned how to detect public S3 buckets with AWS CloudTrail. We identified the different ways AWS uses to communicate the creation of an S3 bucket and the implications of relaxed permissions. Depending on the interface used (web console or CLI), AWS adds different headers, which makes detection a little bit tricky. I encourage you to use this information to identify your public S3 buckets and determine what truly needs to remain public and what should be immediately made private.
If you do so, I recommend that you dig into remediation via security orchestration: make private a public S3 bucket while notifying the user and your security team. Would you be interested in a follow-up blog post that teaches you how to easily perform this remediation step? Let me know in the comments below, please.
The Auth0 Identity Platform, a product unit within Okta, takes a modern approach to identity and enables organizations to provide secure access to any application, for any user. Auth0 is a highly customizable platform that is as simple as development teams want, and as flexible as they need. Safeguarding billions of login transactions each month, Auth0 delivers convenience, privacy, and security so customers can focus on innovation. For more information, visithttps://gordigecr.it.