Hacker News Reader

Comment by save_ferris | Hacker News Reader

I get that it's the customer's responsibility to correctly configure their services, but what does it say about the UX of AWS services that they're so easy to misconfigure with disastrous consequences? And despite this happening across a variety of industries, Amazon doesn't seem super concerned about it either, but I could be wrong here.

There's just no excuse for this to keep happening, but the processes meant to prevent this are clearly failing.

View on HN

The new console for AWS literally has a documentation link containing example bucket policies at the top of the page for S3 buckets. Either someone was given a job they clearly had no experience in or was alarmingly inadequate at performing their job duties. It really shows the level of incompetence so many of these companies operate at with no regard for PII.

Insecure defaults are a footgun.

They're secure by default on S3. You have to go out of your way to make it public, or grant anyone else access.

It's not that so much but that novice users see two ACLs: "Public" and "API Key I use to deploy." So it's very easy to "fix" an access issue by making a bucket public, with the alternative being to give your application the keys to the kingdom. This combined with S3's most frequent use as a file server means that buckets get opened up. You have to jump through hoops and dig into Amazon's access model for anything more nuanced, and only people experienced with AWS will understand or know how to do that.

Making a bucket public should come with red flags, and there should be a simpler way for client-side code to securely access a bucket. If I save a user's uploaded files to the filesystem, I usually have to go out of my way to expose that. Even novices are less likely to put them inside the web root, so exposing such files involves jumping through hoops. Opening a bucket to the world is too easy in AWS.

Calling this situation "insecure defaults" was imprecise of me, my point was more that Amazon gives you a Big Red Button to "fix" things which has consequences like this.

It does have red-flags. When you try to set a bucket to "public" in S3 it literally tells you: "This bucket will have public access. Everyone will have access to one or all of the following: list objects, write objects, read and write permissions."

I mean, there's a difference between being a novice and being stupid.

They were times when people used to manage their servers and they had to be careful on how to use 'rm -rf' or 'dd' tools.

I find it funny how today there have to be red flags, warning signs and double confirmations everywhere. Are people less competent or are there simply lower requirements when hiring them?

Not if you use aws-cli. But I think the larger issue is that Amazon doesn't provide a low-friction, secure way for applications to access their buckets. A good way would be for each bucket to come with its own access key, or expiring tokens that you could query on the backend and use from the browser. Just spitballing of course.

Absolutely.

Windows tells you that using a password is probably a good idea for a user account. Many websites these days force you to use a combination of letters/numbers/special characters.

Why doesn't Amazon say "hey, this is publicly available, you wanna fix it?"

> Why doesn't Amazon say "hey, this is publicly available, you wanna fix it?"

They do. It's clearly warned about in the interface both at the time you make it so and with a big "PUBLIC" sticker label afterwards. What's more, I've received warning emails from AWS notifying of (intentionally) public buckets.

Public buckets for private data are a deliberate and wilful choice by lazy, reckless administrators.

I noticed this when I went into my console the other day. (Ironically, to set up a public bucket for something.) I don't think the UI was bad before but, now, you'd have to be pretty clueless to have a bucket public by accident.

You've always had to make it public deliberately. The new console UI makes setting a bucket to public a very deliberate effort.

No its that they are being pushed by companies to produce so quickly that they end up cutting corners and making obvious mistakes.

A stressed engineer waiting for the rug to be pulled out from under him is capable of just about anything.

Agreed. So it sounds like Amazon is making efforts to reduce configuration failures, but users don't necessarily take the time to properly learn the tools and configure them correctly because the risk of error doesn't seem to motivate them appropriately. What can be done to change that? Naming and shaming like this?

I'm also not a devops person, so I'm definitely not debating in my wheelhouse here. It's just crazy to keep reading about a seemingly preventable problem that has the potential to do major damage in regards to data exposure.

S3 buckets are not public by default. You have to go out of your way to enable it.

Not only is private by default, but also when you have a public bucket there's a big freaking "PUBLIC" label in the UI. Doesn't get more clear than that,

Maybe if you house sensitive information you should have a person or multiple people enforce security across your organization? Scapegoating one technology or person is not the correct attitude because it could have been anything else.

Also, amazon is improving their UX for these things already.

>Maybe if you house sensitive information you should have a person or multiple people enforce security across your organization?

They probably didn't care, and should suffer consequences as a result.

This looks like a really small company who contracted this stuff out to a WordPress shop. There's almost no tech employees or positions on job boards for them.

Both can be true.

I honestly don't know what the solution is. Making a good user experience (read: convenience) and keeping your stuff secure is always a balancing act. I can't tell you how many times I've told a manager or director not to do something because it would make our client data insecure, only to have them basically reply with, "I'm your boss, do what I say."

This guy may have known exactly what he was doing, but relented to other higher ups who told him to do something. The shitty part is now this is public, all the execs can point to the developer and say it was his fault and fire him without incurring any repercussions themselves.

Aren't S3 defaults entirely private? It's pretty obvious what you're doing when you make a bucket public.

Actually, AWS S3 console will now SCREAM at you if you leave anything public.

Now, if you don't know your S3 bucket is public that's entirely on you.

I suspect this kind of storage was not the original purpose of S3. For instance, it's a common to use S3 buckets to serve up webpage assets rather than using a dedicated CDN or your own servers.

It's becoming the underlying datastore for everything from static websites to databases (see Athena)

What makes you think it's the UX of AWS services that is leading to these issues?

The fact that it keeps happening repeatedly.

Does the same argument carry over to public FTP servers? I doubt it.

Apple has actually updated their UX recently to let you know if your s3 buckets are public or not. EDIT: The recent update made it explicitly clear that your bucket is public. Previously, you might not notice, especially if you were taking over from a previous sysadmin (or more likely a developer)

Reply on news.ycombinator.com