Hacker News Reader

Comment by whoisjuan | Hacker News Reader

Having an S3 Bucket with writing permissions to anyone is a major fuck-up. I know many people open buckets to the world at the read-level for whatever reason. I do that myself for static websites. But also writing permissions?

This requires a Bucket Policy that is written explicitly to allow this. I don't want to make assumptions because of course we don't know all the information and I personally know very little about infosec, but that sounds very strange.

Why would you do that? I assume the SDK gets uploaded from a secure environment that has the credentials to upload objects, so there's no legitimate reason to have writing permissions open to the world.

View on HN

Potentially because it was spun 10 years ago while permissions were basic/different/even harder to track, and has since fallen off the wagon?

It seems this incident has reminded Twilio to audit all their access right, which is a net positive.

Actually, imagine you were an employee who wanted to get this done, but couldn't get management approval? This is one way to fix things ... :)

I remember there are AWS settings to set at account level that override permissive bucket level policies

For such an important bucket, they should have

a. adopted the resource into a Cloudformation stack & a1. Enabled drift detection.

b. Use an AWS config rule to monitor (appropriate) s3 buckets for any public access.

1. Drift detection is a relatively new feature. 2. CloudFormation was so basic for so long that most AWS professionals don't use it. They use Terraform or a similar, non AWS product.

CloudFormation didn't support importing existing resources until last November. For years you had to let it recreate everything you need, if you hadn't used it from day one. That's a big part of what kept us on Terraform.

You're absolutely right, and I think most of us have a hard time a. learning about all of the new features and b. justifying going back and fixing up stuff to adopt the new features, but IMO for such a critical piece of infrastructure it should have been done and the engineers/architects should have been adding that sort of stuff to the backlog or requesting training or asking for resources, etc. For me, that sort of stuff is the only way I can get the green light to go back and refactor.

> because it was spun 10 years ago while permissions were basic/different/even harder to track, and has since fallen off the wagon?

That's not a AWS problem. That's a "our team failed to manage the service" problem.

This includes monitoring a publicly accessible bucket.

Yeah this is absolutely inexcusable for a public tech giant. I wonder how incompetently secured the rest of their backend is. This is terrifying, the amount of PII flowing through Twilio is insane, there really needs to be a way to bite companies that completely ignore all of these security compliance checks they say they pass...

To add another data point, consider this email Twilio sent, announcing that they are now forcing all users to use 2FA by October 12th:

> [...] a 2FA verification code sent to your phone (via a call, SMS message, or an authentication app like Authy).

PSTN-based 2FA in 2020 is not a vote of confidence in the security team's competence.

> PSTN-based 2FA in 2020 is not a vote of confidence in the security team's competence.

A lot of companies go with email and/or PSTN based 2FA for customer convenience and to get them to use 2FA for their accounts.

I try to avoid using 2FA for accounts that only offer PSTN or email based 2FA because it's less secure than my randomly generated long password. It would be nice if more services offered 2FA based on client side TLS certificates.

i would not say it's less secure. Even if somebody overtakes one of my machine and gets to my lastpass vault or steals my clipboard having my smartphone with me and a SMS or PSTN based 2FA is better then not having it at all.

If implemented properly, it's totally possible that security is not reduced for that user. However there are at least three problems with it:

1) When not implemented properly, it is treated as an alternative authentication mechanism, not an additional required mechanism. My ultra strong password is useless if it's enough to steal my phone number and convince customer support that the attacker simply forgot the password.

2) It gives a false sense of security. I already have 2FA enabled! What do you mean I should be using TOTP/FIDO2/TLS client certificates?!

3) It reinforces an unfortunately widespread security anti-pattern, which reduces security for Web users in aggregate. So what if it's not a great idea? Everyone is doing it! Or put another way, MD5 password hashing is better than storing passwords in plain text. But please, please, please do not use MD5 password hashing! There are much better ways to accomplish that goal without introducing more flaws.

even stripe offers SMS for 2FA. both PSTN and SMS are not perfect and have similar downsides.

Yes.

AWS is getting really confusing, IAM is not simple, which is bad.

But S3 is a bread-and-butter service, and the policy is such that anyone using it should understand. I mean it says there in 'almost plain English' than 'anyone' can write content.

This is a pretty major blunder, because it hints that maybe they don't have any security reviews at all.

If I, a completely non security-knowledgable person were asked to do an audit of Twilio, I would find this issue. It's way on the lower treshold of 'obvious problem'.

Twilio is not 'Medium Blog' - they provided IT plumbing and therefore it's doubly problematic.

Reply on news.ycombinator.com