Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK

theregister.com

Post reply on HN
Print view View original

1–10 of 162 posts

Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK

#3

Post by fokinsean »

madmulita wrote: post #2

English is not my main language, but "broke into" doesn't implicate "breaking" something to get "into" something?

Yeah, in reality its like complaining someone "broke" into your care when you left all of your doors open.

Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK

#6

Post by k1t »

madmulita wrote: post #2

English is not my main language, but "broke into" doesn't implicate "breaking" something to get "into" something?

In the physical world (think "breaking and entering"), any amount of force (e.g. Pushing an already partially open door) counts as "breaking".

It isn't necessary to actually "break" anything.

Edit: Of course, it's still not a great metaphor because it implies there was at least some kind of barrier to entry that had to be pushed aside - but from the sounds of it, there wasn't.

Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK

#7

Post by rafaelturk »

S3 security is a pain. S3 options are tricky to master, docs are beyond confusing.

A common S3 use case is: Use a Bucket for Read-only static content, (js, html, imgs). From a dev perspective ideally it will work like a protected folder + Web Server, whereas the webserver will have read-only privileges, but reality is far more complicated.

I can understand why was easy for Twillio to have this infosec issue, since we've done it ourselves many times when using S3.

Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK

#8

Post by ed25519FUUU »

rafaelturk wrote: post #7

S3 security is a pain. S3 options are tricky to master, docs are beyond confusing. A common S3 use case is: Use a Bucket for Read-only static content, (js, html, imgs). From a dev perspective ideally it will work like a protected folder + Web Server, whereas the webserver will have read-only privileges, but reality is far more complicated. I can understand why was easy for Twillio to have this infosec issue, since we…

Is it really a pain though? Maybe because I’ve been working with it since the beginning. Bucket ACL with NO permissions, then manage all permissions on an IAM role on the account.

If it’s cross account then allow assuming to other accounts, but no reason to bother with the bucket ACL.

Leave the bucket policy blank and you’ll never have to worry about an open bucket. Better yet make a deny rule to everything but a single role, and you don’t have to worry about rogue roles exposing the bucket.

Perhaps some of the issue is that permission can be managed on both IAM and a bucket policy?

Post reply on HN