Hacker News Reader

Comment by social_quotient | Hacker News Reader

If this had been another s3 bucket on AWS we would be blaming amazon. Here we don’t blame jira/atlassian. Why do we do this? (Honest question)

View on HN

When you setup an S3 bucket the permissions are pretty explicit. The issue here is the UI is confusing (arguably it's wrong but I digress) and is related to a configuration that you'd have to hunt for. It's not an obvious permission that you can easily know it should be changed unless you have experience with it (whereas S3 it's listed right there when you created it and by default it's pretty private).

It didn’t used to be. When you set up a bucket with public read access, you might also decide to give other people on your team write access to the bucket. AWS conveniently provided an All Users option for this.

Except it wasn’t “All Users in your AWS account”, it literally meant ALL USERS of AWS. Disaster. This led to the same problems as this Jira issue.

AWS changed it so that’s no longer an option. Atlassian should do the same.

> we would be blaming amazon

Would we? Amazon requires you to explicitly make the bucket open. It also allows you to prevent that account-wide with IAM policies. It also allows delegating the opening to public to specific people.

And I believe you get warnings about public buckets from their advisor. (May be misremembering that one) You can easily audit that too.

So basically I don't see what else could AWS do to make this more secure. It's 100% on the user at this point.

> Would we?

By all current evidence, we'd blame Capital One, so I guess this is consistent?

Huh? It seems the exact opposite of that. The top comment here is blaming Jira[1]. But when Capital One got hacked last week due to apparently some AWS misconfiguration, it seemed no one blamed AWS (even though the hacker had previously worked at AWS)[2].

[1] https://news.ycombinator.com/item?id=20597264

[2] https://news.ycombinator.com/item?id=20560342

Reply on news.ycombinator.com