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

41–50 of 162 posts

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

#41

Post by erichurkman »

untog wrote: post #26
pquerna wrote: post #15

Earlier quoted context omitted.

Yes! Subresource Integrity is the exact counter-measure to this kind of attack: https://developer.mozilla.org/en-US/docs/Web/Security/Subres... However, on Twilio's documentation site, they do not include the integrity attribute in their examples: https://www.twilio.com/docs/taskrouter/js-sdk/workspace/task...

It's difficult. I like the idea of subresource integrity a lot, but a counter example: Twilio discovers a bug in their JS SDK. Without subresource integrity they can push up a fix and propagate it to all clients immediately. With subresource integrity they would need every client to update their web site to change the integrity attribute. If it was a serious bug then that could be a huge issue. Even putting the secur…

What about an alternate for these 'platform script includes' like Twilio and Stripe:
in which clients compute the integrity and asynchronously ping a lightweight payload of the integrity to the third party? You would then seed your report service with a list of known hashes and set up alerting for when new hashes were observed.

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

#42

Post by vangelis »

SV_BubbleTime wrote: post #37
wjossey wrote: post #21

Earlier quoted context omitted.

This is the correct design pattern as of 2020. Roles + STS, and always be stingy when granting a role any permissions, both at the resource or API level. But, as others have said, the documentation at times is poor at best, and it can be easy to make mistakes. Some preventives every ops team can take are: 1. Never make manual permission changes in the console. Everything is done via SCM’d code. 2. All permission chan…

> Never make manual permission changes in the console. Everything is done via SCM’d code. The first time I heard “infrastructure as code” I thought it was some dumb new buzz words, but no, it’s good advice. Your cloud formation, serverless, terraform whatever should be stored in GIT a stack replace is how changes should be made. I consider the console as read-only.

I occasionally spin up things in the AWS console so I can describe them through the CLI and then delete them. IaC is great until you have no idea what the code should be.

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

#43

Post by TheSpiciestDev »

ljoshua wrote: post #38
TheSpiciestDev wrote: post #34

Earlier quoted context omitted.

"In local news, stranger off the street walks through residence's open door and moves around furniture."

Well, even in such a world, that would still be considered trespassing.

For sure, and I believe Twilio did not intend to "have their door open" and that whoever modified their code knew that they were "trespassing" similarly.

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

#44

Post by txcwpalpha »

somehnguy wrote: post #36
ed25519FUUU wrote: post #8

Earlier quoted context omitted.

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 sin…

It is absolutely a pain. I'm using S3 for the first time on a project right now and literally every time I have to do anything in AWS I end up confused and scared that I'm leaving a wide open security vulnerability. The documentation is complete insanity to anyone just trying to accomplish what should be an extremely common use case in a reasonable amount of time. Before using AWS I was in the 'what morons!' camp whe…

The problem with S3 is the exact same problem with everything else in AWS. In their quest to be compatible and attractive to every single possible niche use case of the world's largest companies, they completely forgot the lone developer who just wants to upload a couple files.

You'll even see this in their sales pitches. AWS will spend so much time talking about the most advanced use cases and how they are possible, but if you ask them a simple question about how to run a single bucket that doesn't also involve using all of their ML tools and global accelerator and cloudfront, they'll be blindsided. It's almost as if they consider the common use cases to be "too simple/obvious" and therefor they never bothered to create any documentation or put any thought into it.

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

#45

Post by TheSpiciestDev »

erichurkman wrote: post #41
untog wrote: post #26

Earlier quoted context omitted.

It's difficult. I like the idea of subresource integrity a lot, but a counter example: Twilio discovers a bug in their JS SDK. Without subresource integrity they can push up a fix and propagate it to all clients immediately. With subresource integrity they would need every client to update their web site to change the integrity attribute. If it was a serious bug then that could be a huge issue. Even putting the secur…

What about an alternate for these 'platform script includes' like Twilio and Stripe: in which clients compute the integrity and asynchronously ping a lightweight payload of the integrity to the third party? You would then seed your report service with a list of known hashes and set up alerting for when new hashes were observed.

Script tags (added programmatically) should support such errors via "onerror" functions. Though, I don't know if integrity errors could truly be determined. If they can then you can do whatever you want with such an error.

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

#46

Post by pantulis »

txcwpalpha wrote: post #44
somehnguy wrote: post #36

Earlier quoted context omitted.

It is absolutely a pain. I'm using S3 for the first time on a project right now and literally every time I have to do anything in AWS I end up confused and scared that I'm leaving a wide open security vulnerability. The documentation is complete insanity to anyone just trying to accomplish what should be an extremely common use case in a reasonable amount of time. Before using AWS I was in the 'what morons!' camp whe…

The problem with S3 is the exact same problem with everything else in AWS. In their quest to be compatible and attractive to every single possible niche use case of the world's largest companies, they completely forgot the lone developer who just wants to upload a couple files. You'll even see this in their sales pitches. AWS will spend so much time talking about the most advanced use cases and how they are possible,…

Your point is good, but one could suppose Twilio is not a "lone developer".

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

#47

Post by sterkekoffie »

untog wrote: post #26
pquerna wrote: post #15

Earlier quoted context omitted.

Yes! Subresource Integrity is the exact counter-measure to this kind of attack: https://developer.mozilla.org/en-US/docs/Web/Security/Subres... However, on Twilio's documentation site, they do not include the integrity attribute in their examples: https://www.twilio.com/docs/taskrouter/js-sdk/workspace/task...

It's difficult. I like the idea of subresource integrity a lot, but a counter example: Twilio discovers a bug in their JS SDK. Without subresource integrity they can push up a fix and propagate it to all clients immediately. With subresource integrity they would need every client to update their web site to change the integrity attribute. If it was a serious bug then that could be a huge issue. Even putting the secur…

>If it was a serious bug then that could be a huge issue.

Regardless of the severity of the bug, the only-case scenario is that all the sites you have pulling from that CDN break until you recompute the hash. How annoying this is scales directly to how frequently your libraries have to release vital security bugfixes.

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

#49

Post by merb »

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…

actually aws changed the default lately and added more options to really see what you configured. in the past, there was no indicator if s3 is private only oder public

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

#50

Post by tyingq »

Doesn't sound so non-malicious to me:

"Specifically, the modification added code to the end of the TaskRouter.js v1.20 SDK that made an HTTP GET request to hxxps://gold.platinumus.top/track/awswrite?q=dmn and followed the URL returned in the HTML by that request."

Post reply on HN