My Mom is Sick and Tired of Your Weak S3 Bucket Policies

Cloud security has headlined so many stories over the past year that the term “leaky S3 bucket” even rolls off the tongue of my mother with ease and accuracy. Indeed, S3 bucket issues have become almost shorthand for the vulnerabilities that IT infrastructures face in the cloud, but they highlight just one problem among an almost infinite number of potential issues.

And, to be sure, open S3 bucket policies that enable anyone to GET the data stored inside is only one part of the problem. Then again, the buckets themselves are not at issue. There are so many other factors that contribute to penetrable storage and workload resources, and cloud users must recognize the need for smart and effective policies, as well as continuous awareness of cloud events that could, in an instant, radically alter the threat vector of an organization’s cloud environment.

Configurations are where so many vulnerabilities get started. Servers, buckets, virtual machines, applications, and other resources change configurations and settings in order to meet business needs and adapt to the integration with other data sources. It’s part of the dynamic nature of the cloud, but it’s also like a constant and continuous game of hide-and-go-seek. And frankly, mom isn’t having any of it.

There are other S3 bucket misconfigurations that can make data and cloud resources vulnerable to malicious activities which should be addressed to keep your organization’s data secure today and every day.

1. What’s in Your Bucket?

AWS enables you (by default) to configure your S3 buckets so that the data inside can be viewed by the world. Even worse, you can also set the Access Control List (ACL) permissions so that anyone could edit the ACL giving them the power to grant themselves access to your whole cloud. Sure, it’s easier to just set a Global policy than selectively define exactly who and what systems really need to view and edit, but that leaves you open to the huge risk that could damage your business and your reputation.

2. Fix Your Bucket List 

What kind of information could possibly be gained by letting anyone see the names of your S3 buckets? That’s the question that must be considered when you decide how to set the S3 bucket Global List permissions. Seems pretty harmless until you realize that you have buckets named for each of your customers, or buckets with the labels “Resumes 2018” or “Vendor W9” or “Acquisition Research.” Don’t make it any easier for the bad guy to find your data treasures by allowing them to see the names of all your buckets. It may seem harmless but it’s like putting a treasure map in front of a pirate… of course, they are going to go looking.

3. Here Today, Gone Tomorrow 

There are two configurations that allow your S3 bucket to be wiped out by anyone with access (if you really care so little about this information, why store it in the first place?). The first, and worst, is a Global DELETE permission which allows anyone to delete an entire S3 bucket. Poof! Data is gone. The second configuration allows the data to be deleted without Multi-Factor Authentication (MFA). Seems pretty innocuous, until you realize that if a bad guy got access to an entitled user’s account, they could delete the files in just a couple of clicks. If you’ve gone so far as to enable strong access permissions on your ACL lists, go that extra step and enable MFA for delete, too. Clicking a button on your phone every time you want to delete something may seem like a drag, but it may save you countless headaches down the line.

4. Open for the GETting 

We’ve discussed global list, view, edit, and delete permissions, now here comes their nasty cousin GET. This is the setting that allows anyone or anything to go into the file and get any or all of the data contained inside. Since the data will still be accessible by you and entitled systems, you may not even realize that someone bad has gone in and accessed the data. But, with GET open to anyone, your data could be sitting in someone else’s hands just waiting for the right moment (like when the season of your biggest hit show is about to start) to send you a ransom note. Set rigorous access controls and ensure that the GET setting is only usable by those required to have it on a regular basis.

5. PUTting Things in Their Proper Place 

Some feel that global PUT permissions are not all that bad, but it’s an incorrect presumption. Here’s a scenario: a competitor guessing your namespace loads some of their corporate secrets into your S3 bucket and then notifies authorities, setting you up for an espionage charge. If that sounds too much like a Grisham novel, consider this instead: A hacker guesses at your namespace and drops malware into your bucket with the hopes that you eventually open it up and unleash its viral badness into your cloud environment. Those Global PUT permissions are seemingly less harmless, aren’t they? You can fix this by clearly defining who and what systems have PUT permissions to S3.

6. Not Keeping Tabs on S3 

If everything is in order and secure, why do I really need to pay attention to store logs or old versions of documents? Well, just because everything is in order when you look, doesn’t mean that was always the case. Without logging turned on, how will you know that someone accessed your account, changed settings to allow them access to your S3 bucket, took your data, and then set the permissions back to the original setting? And, without versioning, would you know what the data looked like before a malicious insider went in and changed all your research test results to make you look a fool later? Turn logging on so you know what happened when you weren’t looking. Turn versioning on for anything important. You’ll be thankful later.


Given the number of high profile S3 bucket breaches, and that AWS defaults to permissions on S3 buckets being closed upon creation, misconfiguration is a big problem. Even when you think you’ve been judicious and gone through your precautionary checklist, like other elements of your environment change or require S3 configuration changes, you need to continuously give attention the state of your buckets.

No one, including my mom, wants to hear about another bucket disaster, but the nature of the beast means it’s inevitable that this will continue to be an issue for security teams. Taking care in your configuration approach and using the right tools for awareness and insight will keep you aware of issues and where they reside within your cloud environment.