3 Things to Know About AWS S3 Security to Stay Out of the Headlines

Unless you’ve been in heat-induced hibernation for the past couple of months (our HQ is in San Antonio, so we get it), you’re probably aware that Amazon Web Services’ Simple Storage Service (S3) has been at the center of numerous security related headlines:

Massive Amazon S3 leaks highlight user blind spots in enterprise race to the cloud
Faulty AWS S3 Configuration Exposes Personal Data of 198M U.S. Voters
Defense contractor stored intelligence data in Amazon cloud unprotected
Auto Financing Company Leaks 500K+ of Customer’s Info Online

The worst part (or best part, depending on your perspective) of every one of these stories is that none of them were caused by any flaws or exploits of the S3 service itself, rather they were all caused by user misconfiguration.

I had a boss that would always say, “It’s a good day as long as we’re not on the front page of the Washington Post.” These companies and organizations most assuredly have had some bad days, and the administrators or engineers behind the misconfigurations likely experienced what we in the IT world call a “résumé updating event”.

The common thread here is that these were all avoidable situations. As AWS puts it, “By default, S3 buckets allow only the account owner to list the bucket or write/delete objects; however, these permissions can be configured to permit public access.” So, the unfortunate truth is that somebody either made a conscious decision to apply such a configuration or mistakenly applied some settings they did not fully understand.

The three most problematic configuration settings in S3 of which you should be aware are:

  1. “Everyone” access by the access control list.
  2. “Any AWS User” or “Any Authenticated AWS User” access by the access control list.
  3. “Stealth” bucket policies.

The first may seem fairly obvious but it has potentially devastating effects, and it’s one of the simplest settings to apply — it’s a change the UI almost begs you to apply. When you create a new bucket or modify the access control list for an existing bucket, one of the first things that pops up is the option to apply permissions for “Everyone”.

By simply checking the box between “Everyone” and “List”, you are adding the ability for EVERYONE to view the contents of the bucket. “Everyone” here means literally any requestor in the universe, not “Everyone that’s allowed to use my application”, or “Everyone in my company with access to this account”, as many AWS users commonly misinterpret.

“Everyone” in this case means the entire Internet now has the ability to see inside this bucket. This doesn’t necessarily mean they can download or view individual objects, as each object has its own set of permissions, but for a nefarious actor, the reconnaissance information gained by simply having access to the metadata is invaluable, often more so than the contents of the objects or files themselves.


The second problematic configuration setting is closely related to the first, but it’s much easier to misinterpret with the same damaging consequences. Until a few weeks ago, this was also one of the default options available for selection when applying access control lists to a bucket in S3. You had the ability to apply permissions for “Any AWS User” or “Any Authenticated AWS User”, depending on the version of the console you were using.

At first glance, that sounds like a potentially decent enough protection for securing information within a bucket that’s shared throughout your entire company or AWS account. Someone accessing this information would need to actually have a valid login to be able to access this information.

This is pretty much the same thing as setting a shared folder on my corporate file share to “Users”, right? WRONG. This does not mean “Any Authenticated AWS User FROM MY COMPANY” or“Any AWS User IN MY ACCOUNT”, as many, often experienced AWS users have misunderstood.

Here again, this means literally ANY AWS USER. Still, you may be thinking, well at least this is better than “Everyone”, right? Once again, WRONG. It takes seconds to create an AWS account. Anyone with an Amazon account is already a potential AWS user (who on this planet hasn’t bought something from Amazon by now?) and just about every nefarious actor out there has an AWS account they already use for nefarious reasons.

So, for all intents and purposes, this setting is no more secure than the “Everyone” option above. AWS recognized the ambiguity in this and removed the UI setting, but it can still be set manually and may have been set prior to the UI change.

The third most problematic configuration setting within S3, and I would argue the most dangerous with the farthest-reaching consequences, is bucket policies. It also happens to be the easiest to screw up and the hardest to detect, which is why I labeled it “Stealth” bucket policies.

Bucket policies do not make themselves directly visible through the UI. They also do not show up within the permissions output via the UI nor the API. And unlike the bucket access control lists discussed above, they can apply universally to the objects within a bucket as well.

Once created, the policies sit there, virtually undetected, written in the obscure language of JSON, silently and potentially GLOBALLY granting permissions you had no idea existed. The following 123 characters is a potentially deadly sequence, rendering your entire bucket, including all objects within it, completely open to the world!


Given how problematic that configuration is, who in their right mind would actually apply it and why? Honestly, the answer is many smart people and for often legitimate reasons. Public sharing of information, temporary landing zones or using a slightly less egregious version of the policy for static website hosting are all reasons this configuration might be used.

Imagine this scenario. You run your corporate website on AWS. Years ago, your predecessor created the bucket “www.yourcompany.com”, populated it with content, enabled static web hosting and applied a very open yet appropriate bucket policy.

It may have worked well for years, but times changed and once static websites were no longer en vogue, your predecessor replaced your corporate website with a dynamic CMS, and in doing so, deleted all of the contents of the bucket and set a wildcard redirect to the new CMS. Then they left the company on good terms after successfully deploying the new website, and you came along.

Your first major initiative is to implement a CI/CD pipeline for updating the corporate CMS. Ok, you just need a repo to get started, so you log in to AWS and discover there is a perfectly empty and aptly named S3 bucket ready to go. You uncheck the box for static web hosting and remove the access control lists for “Everyone” to lock it down for internal use. Then you push all of your proprietary source code, configuration files and secrets into the bucket. You then set up your pipeline, and your team begins successfully rolling out several changes per day. Everything is good, or so you think.

Your company is rather well known, so you are inevitably a target for many nefarious actors. One such actor has been watching your company for years, trying to find a way in. Years ago, he tried to hack your corporate website, only to find it was just a static web hosting enabled S3 bucket with no viable attack surface. Last night after browsing to your new website, he had a thought: even though the website is no longer directly hosted on S3, there is no way that the company got rid of the bucket named after their fully qualified domain name…

 $ aws --profile crash0verride s3 ls www.yourcompany.com
PRE .config/
PRE .secrets/
2017-06-01 11:33:21      82566 main.js
2017-06-27 17:48:17       2938 blog.js
2017-07-10 00:37:47       1152 post.js
2017-06-23 11:57:07      19075 db.js

Then you wake up to 17 missed calls and your company is on the front-page of every major news outlet. “Wide-Open S3 Bucket Policy Leads to Public Disclosure of Entire Customer Database.” As it turns out, there IS such a thing as bad publicity. “I forgot about the bucket policy,” you mutter to yourself as you clear out your belongings. Don’t become a headline and don’t jeopardize your career. Make sure you understand the different ways access control lists, permissions and policies work within S3 and every service.

You can run a quick self-evaluation of your S3 buckets by executing the following AWS CLI based bash “one-liner”:

for bucket in `aws s3 ls|awk '{print $3}'`; do echo "Bucket: $bucket"; aws s3api get-bucket-acl --bucket $bucket --query Grants[?Grantee.Type==\'Group\'].[Grantee.URI,Permission] --output text;aws s3api get-bucket-policy --bucket $bucket --output text 2>/dev/null; done

It will check every bucket in your account for these three potential issues. It is important to remember that the settings themselves are not necessarily problematic. They may be there for very specific reasons. It’s also possible that you have any combination of the settings, as well as multiple permissions assigned to Everyone and All AWS Users. These two will be rather self-explanatory, the output in the format: who has the permissions and the actual permissions. A bucket with a configuration setting of “Everyone” (#1 above) having the ability to List contents of the bucket will have output similar to:

Bucket: bucket-with-everyone-list
http://acs.amazonaws.com/groups/global/AllUsers                READ

A bucket with a configuration setting of “All Authenticated Users” (#2 above) having the ability to write to a bucket will have output similar to:

Bucket: bucket-with-all-authed-users-write
http://acs.amazonaws.com/groups/global/AuthenticatedUsers WRITE

If you see AllUsers or AuthenticatedUsers with permissions you did not intend, and you are certain that nobody outside of your account should have any access to the bucket, you can restore the bucket ACL to the default “private” settings using the following AWS CLI command:

aws s3api put-bucket-acl --bucket BUCKETNAME --acl private

Be careful with this command, as it will reset ALL ACLs, including the configurations necessary for AWS log delivery, CloudFront and potentially other, legitimate AWS uses.

The self-evaluation one-liner will also directly display the “Stealth” bucket policy (#3 above) if one exists, but it will still be up to you to interpret the JSON output. The mere presence of a policy is not necessarily a problem, as it could just as easily be making your bucket MORE secure. Things to be on the lookout for are asterisks (*) within the policy representing wildcards for who can do something (the Principal), what they can do (the Action) and on what Resources. If you don’t know what you’re looking at, I highly recommend you consult a professional who is proficient in JSON and AWS to help you evaluate the logic.

Within our Fanatical Support for AWS service, we work with each and every one of our customers to ensure security is an upfront priority and that all configurations applied are appropriate and intentional. We also proactively monitor our customer environments for common missteps via our proprietary tooling, and present any findings to our customers on a regular basis. Through our tooling and human expertise, we have identified over 1,000 potentially damaging S3 configuration settings and proactively worked with our customers to remediate them, applying more appropriate and secure settings.

We want to ensure that your assets are protected, whether you are a Rackspace customer or not. Please reach out to us today so we can help: https://www.rackspace.com/managed-aws

Brad Schulteis is Director of Government Solutions. Previously, he served as Principal Architect and security specialist for Rackspace. He has over 15 years of enterprise IT expertise, across the public and private sector. He previously worked at AWS World Wide Public Sector, supporting some of their largest US federal government customers. Prior to that, he served for many years in a staff position within the Department of Defense, managing all aspects of their private cloud computing platform. Brad's work on this platform earned him a DoD Value Engineering Award, Special Act Award and Joint Meritorious Unit Award. Concurrently, he served on many government IT transformation working groups and study committees. He has a proven track record of working with complex requirements and driving change throughout large IT enterprises. Find Brad on LinkedIn.


Please enter your comment!
Please enter your name here