Amazon tries to ruin infosec world's fastest-growing cottage industry (finding data-spaffing S3 storage buckets)

Amazon Web Services is taking steps to halt the epidemic of data leaks caused by the S3 cloud buckets it hosts from being accidentally left wide open to the internet by customers. Thus, if you are among the growing bunch of infosec researchers on the hunt for misconfigured public-facing S3 silos packed with slurpable private …

[Steve_Jobs1974]

Is it that hard sir

I mean come on. It not that hard to keep your bucket private. They put big yellow warning signs all over public buckets.

[elDog]

Re: Is it that hard sir

And since we are all inured to yellow warning signs once we've seen a few of them. You need to make the admin/user work harder to turn on public access. Sort of a moving whack-a-mole that takes 5-10 quick mouse clicks to succeed. (Of course Amazon will be analyzing your mousey actions to see if you are you and if you are cognizant and not playing.)

[Anonymous Coward]

Re: Is it that hard sir

"It not that hard to keep your bucket private."

Sure, but it's not that easy for Amazon to make it even simpler, given that the only thing they really charge for on S3 is the extraction of data. Ingest is free and ongoing storage is as good as free. Bulk downloads? Well, who cares if they're legitimate or not...

[John Smith 19]

You call them "policies" I call they default settings.

So WTF was the default setting not always "Private" to begin with?

[Michael Hoffmann]

Re: You call them "policies" I call they default settings.

It *is* default!

However, if you are delegating control over a bucket within an account, you end up with some herp-derp for whom "IAM 101" might as well have been in Minoan Linear A who, after 2 failed attempts at secure access, just sets public on their bucket.

This is a ... I believe in the UK the favourite term is now "backstop"?

[Anonymous Coward]

Uncheckable "THIS SHALL BE PRIVATE" checkmark

There should be a "this is, and always shall be, PRIVATE" checkmark.

The wrinkle is that while it's checkable by normal peons, it's not uncheckable unless you're a high level admin (or someone else that knows the difference between public and private, or at least their ass is on the line about it)

At Uncle Larry's House of Big Orange Databases and Used Cars, that's the behavior of "[x] this is a security bug" or "[x] this contains health or other sensitive data" and other important tidbits.

[Rainer]

Our ticketing system

can store BLOBs in S3 buckets. But their support made it clear that the bucket has to be completely public.

We actually have a private S3-implementation on-site, but it has to be public-public.

Their support said, it wasn't a big deal because the actual URL of the bucket was "not public".

We store the BLOBs on the local filesystem now.

[James R Grinter]

About bloody time!

I think it isn’t truly appreciated just how easy it is for an authorised piece of software to upload an object - with an “everyone can read it” ACL - and completely undo any attempts to keep the bucket secure.

(Yes, you could craft a policy that blocked anything with open access from being created, but you couldn’t block everything already there.)