WRITE Permissions Granted to Everyone on a Bucket

A few days ago, we at CloudCheckr Inc. received an email from Amazon about our AWS account. The purpose of the email was to to let us know that one of our buckets in S3 had “WRITE” and “WRITE ACP” granted to everyone (you can read the actual email below). These permissions were set intentionally because we are running and conducting tests of our own cloud auditing tool. But it got me thinking about a few security issues.
What is the danger of using “WRITE ACP” or “WRITE” on a bucket? If you’re using these permissions, an attacker has the capability to modify or delete files within your bucket(s). If there is data that should not be modified, that’s a big problem. If there is sensitive data that should not be read, that’s also a big problem. Less obvious, perhaps, is the fact that you could be leaving yourself open to a potential “economic denial-of-service attack.” This type of attack is when someone uploads massive files to your bucket(s) that could cause you to incur crippling financial costs that would damage an application or organization.
Our email from Amazon makes reference to malicious tools that we have yet to see: “some tools and scripts have emerged which scan services like Amazon S3 to identify publicly accessible buckets”. However, even without seeing these tools first hand it is clearly a bad idea to ignore any issues with the permissions on your AWS buckets. The risks are simply too great. If you receive a similar email, you should address its concerns and revoke these privileges as soon as possible.
Even only having “READ” permissions on a bucket is strongly discouraged. Several other blogs have posted comments about READ permissions such as:

“My thinking is – ‘it is ok’ because if debug info is switched off, the bucket url is not discoverable – except if malicious port scan against amazonaws.com.”

“First of all I was surprised that with out my keys that someone could “enumerate” (list?) objects in my buckets. I’m not so worried about them being public as my file names are random 40 character names. However if they list them that is different.”

Best practices dictate that you need to deal with the problem directly because there are plenty of clever hackers out there that will find a way to enumerate your files. Ignoring the security issue because you assume your files are safe by obscuring them is never a good idea.

Email from Amazon:

Dear Amazon S3 Customer,

We’ve noticed that your Amazon S3 account has a bucket with permissions that allow an anonymous requester to perform write operations, change bucket permissions, or both. With these permissions, anonymous users could potentially store, modify, or delete objects in your bucket. Amazon S3 buckets are private by default. These S3 buckets grant anonymous WRITE and/or WRITE ACP access: XXXXXXXX

Periodically we send security notifications to all of our customers with buckets allowing anonymous WRITE and/or WRITE ACP access. We typically recommend against anonymous WRITE and WRITE ACP access. Bucket public “WRITE” access: This is sometimes referred to as “put” or “upload” access. It allows anyone to add/delete/replace objects in your Amazon S3 bucket. Bucket public “WRITE ACP” access: This is sometimes referred to as “edit permissions” access. It allows anyone to modify the access control permissions on the bucket. These entities can add grants to the ACL, opening your bucket to more public access than you want. For example, a public WRITE_ACP permission on your bucket enables anyone to modify the ACL and grant permissions such as grant write permission on your bucket to others.

We know there are good reasons why you may choose to allow anonymous WRITE access. This can simplify development against S3. However, some tools and scripts have emerged which scan services like Amazon S3 to identify publicly accessible buckets. These tools could be used to identify objects in your bucket, and that information can in turn be used to access, add, delete, and/or replace your objects. Anonymous users accessing your bucket content may also produce unintended charges in your account.

We’ve included specific steps to remove anonymous access as well as further information about bucket access considerations. Use the following steps to immediately remove anonymous WRITE and WRITE ACP access to your bucket. Go to the Amazon S3 console at https://console.aws.amazon.com/s3/home. Right-click on the bucket and click Properties. In the Properties pane, click the Permissions tab. The tab shows a list of grants, one row per grant, in the bucket ACL. Each row identifies the grantee and the permissions granted. Select the row that grants permission to everyone. “Everyone” refers to the Amazon S3 All User group. Uncheck all the permissions granted to everyone (or click x to delete the row). This removes all permissions granted to public. Click Save to save the ACL.

Learn more about protecting your bucket by reading the AWS article on Amazon S3 Bucket Public Access Considerations at https://aws.amazon.com/articles/5050. This article includes alternative options if you need methods for unauthenticated end users to read and write content, as well as detailed information on configuring bucket access if you are hosting your website on Amazon S3. It also describes how you can use Bucket Policies if you would like to specify more granular access control on your bucket. Bucket Policies enable you to add or deny permissions across all or a subset of objects within a bucket. You can use wildcarding to define sets of objects within a bucket against which policy is applied, more specifically control the allowed operations, and even control access based on request properties.

For further information on managing permissions on Amazon S3, please visit the Amazon S3 Developer Guide at https://docs.amazonwebservices.com/AmazonS3/latest/dev/Welcome.html for topics on Using ACLs and Using Bucket Policies. Finally, we encourage you to monitor use of your buckets by setting up Server Access Logging. This is described in our Developer Guide under Setting Up Server Access Logging.

Sincerely,
The Amazon S3 Team

This message produced and distributed by Amazon Web Services, LLC, 410 Terry Ave. North, Seattle, WA 98109-5210.

Keep up with the Latest in Cloud

Check out our Resources Center for cloud industry news, research, webinars, and more.