Do It Yourself Data Breaches With S3 Buckets

Ever since 2012 I’ve watched with alacrity as the velocity and scale of data breaches grew at a pace that almost seemed a daily occurrence. Well, if I’m being fair, I wasn’t enjoying the breaches that much. But, at times my schadenfreude did get the better of me.

Recently, I’ve been losing a great deal of my amusement as I watch company after company make headlines for a data breach. There has been a common thread with many of them in the last few months of having exposed their data in an AWS S3 bucket. We have seen the likes of Verizon, Accenture and the Australian Broadcasting Corporation and many others get unwanted attention in the media when they “accidentally” exposed their data in an S3 bucket. Now, I put quotes around the word accidentally because you need to consciously enable that access to have this situation arise. This is not an endemic problem of the entire Amazon S3 ecosystem. This is problem with staff education.

Shutterstock

So, let’s take a moment to pause. You might be asking, what is an S3 bucket? Well, here is a passage directly from the AWS S3 page,

Amazon S3 is object storage built to store and retrieve any amount of data from anywhere – web sites and mobile apps, corporate applications, and data from IoT sensors or devices. It is designed to deliver 99.999999999% durability, and stores data for millions of applications used by market leaders in every industry. S3 provides comprehensive security and compliance capabilities that meet even the most stringent regulatory requirements. It gives customers flexibility in the way they manage data for cost optimization, access control, and compliance.

To be fair the “comprehensive security” only applies when you enable it. As to the access control mentioned, well that’s the root of the problem here.

To put a fine point on it, I logged into my AWS console last night and decided to create an S3 bucket using solely the default configuration options. First step is to name the bucket. This DNS name will identify it for future access. You then pick what region you would like to have the bucket in. For the purposes of this test I decided to create mine in the EU (Ireland) region for no other reason other than I could.

The next stage is to set the properties for the S3 bucket. Here you can set versioning, server access logging, tags, object-level logging and default encryption. All of which I should note are disabled by default. Switching to the third step you need to select which users will have access to the bucket. The owner ID will have read/write access for both objects and object permissions enabled by default. No other permissions are set at this point unless you add them in yourself.

OK, jumping down the options list we get to the gem. “Manage public permissions” is set to “Do not grant public read access to this bucket (Recommended)”. By default, the public access to this bucket is disabled. This is why I get frustrated when I read that an S3 bucket was “accidentally” exposed externally in a write up about a company having their data compromised in this manner. You, or whomever is creating the bucket, needs to manually select the option to grant access.

AWS S3 Screenshot

Dave Lewis (screenshot)

There is no other way to address this problem of S3 exposures than to say that this should not be happening. People need to read the screen that they are working on. If they are unable to process the steps to do something like this then they should not be creating the buckets in the first place. Clarity is an important aspect of any IT service that you are setting up that might potentially be exposed externally.

I often carry on about the requirement for security practitioners to focus on the fundamentals. The rash of data breaches related to S3 exposures is a salient point which highlights the burgeoning security debt. I’ll bet a cup of coffee (huge currency if you know me) that these buckets were not created by anyone in a security role. More often than naught it is someone in an IT function that might not understand the implications of configuring a bucket with public access.

This is not an opportunity to vilify the IT people involved. This is an chance for the security folks to place the point of the sword against their chest and lean forward. If the IT people didn’t understand the ramifications of their choices then this is a missed opportunity on the part of the security team to have educated them in advance.

AWS has a myriad of excellent options for you to use for your business. Just be sure to read the documentation and abide by the warnings. Do not create your own do it yourself data breach or we’ll see you in the news sooner than you think.