Is there a Twilio page that's confirming this?
Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK
131–140 of 162 posts
Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK
#132I love AWS as any other developer, but this is their fault. They've invested all their resources into building out the infrastructure, and have spent very little if any time on building the UX around it. You have to be fairly technical, never mind painstakingly detailed-oriented, in order to manage their services, a big chunk of which is hidden behind black screens and various control nobs. Amazon's logic is probably…
Amazon probably can't change S3 for backwards compatibility reasons (there was an outcry about just changing some legacy URLs last year), but they definitely can and should make an "S4" which would be an S3 compatible storage layer with sane defaults.
Essentially, people only ever want one of two things:
- A private FTP bucket
- A public static asset website (with built-in CDN and HTTPS!)
Thing people never want:
- A public upload bucket
Seriously, no one wants that in any circumstance, ever. It's a huge liability. I literally cannot imagine anyone wanting anything even similar to it. But many, many companies have accidentally made one with S3.
While they're at it, S4 should also actually use IAM and all that other "modern" stuff that S3 doesn't have because it's so ancient.
Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK
#133I love AWS as any other developer, but this is their fault. They've invested all their resources into building out the infrastructure, and have spent very little if any time on building the UX around it. You have to be fairly technical, never mind painstakingly detailed-oriented, in order to manage their services, a big chunk of which is hidden behind black screens and various control nobs. Amazon's logic is probably…
Amazon probably can't change S3 for backwards compatibility reasons (there was an outcry about just changing some legacy URLs last year), but they definitely can and should make an "S4" which would be an S3 compatible storage layer with sane defaults. Essentially, people only ever want one of two things: - A private FTP bucket - A public static asset website (with built-in CDN and HTTPS!) Thing people never want: - A…
What's the fourth S stand for?
Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK
#134Having 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 ab…
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.
Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK
#135Earlier quoted context omitted.
Thanks for posting this. I'm really impressed with the transparency Twilio showed in actually admitting to having such a silly, silly bucket policy. Not impressed that it was there in the first place; but that should go without saying. This incident report should really put to bed all of the "It's AWS's fault for making things so complex" complaints. (To be clear, it won't... but it should.) Even a cursory look at th…
Really not impressed with the obligatory "really impressed with transparency" pat-on-the-back under every incident report for a big corp screw-up that provides any details at all. And stating to the press the clearly malicious payload is "non-malicious" (assuming TFA didn't lie about Twilio's statement)? That's ridiculous.
When talking about screw-ups on AWS, public incident reports try to obfuscate and spin the Hell out of issues that boil down to "really, really stupid configuration issue".
They owned it. That is more than can be said about other large incident reports that I've seen regarding AWS.
Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK
#136Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK
#137Earlier quoted context omitted.
> Without subresource integrity they can push up a fix and propagate it to all clients immediately. In reality, no you cannot. You have multiple layers of cache between the S3 bucket and rendering, unless you disable caching entirely at a massive increased cost. Some of these caches are poorly behaving (e.g. intermediary caching). The correct way of doing this ALREADY is to increment the version number in the URL (e.…
You do not have absolute certainty that every old cached version of a file you have published has been purged by every third party cache, no. But the vast, _vast_ majority do get purged very quickly. I've done this myself when in a bind many times and it's worked fine (and I've been able to verify that via error logging). > There's a reason why "sdk-latest.js" is largely dead concept from a bygone era Is it, though?…
> it's what Google Maps does.
Nope. Google Maps loads an uncachable JS file that itself points to version specific sub-files that are cache breaking.
> It's what the Facebook SDK does.
Nope, they have versions in the fbAsyncInit configuration.
> We already know it's what Twilio does.
Indeed, and if you want to copy a company that almost had a massive security problem then go right ahead.
Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK
#138Earlier quoted context omitted.
Amazon probably can't change S3 for backwards compatibility reasons (there was an outcry about just changing some legacy URLs last year), but they definitely can and should make an "S4" which would be an S3 compatible storage layer with sane defaults. Essentially, people only ever want one of two things: - A private FTP bucket - A public static asset website (with built-in CDN and HTTPS!) Thing people never want: - A…
What's the fourth S stand for?
Super Simple Storage Service ;)
Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK
#139I love AWS as any other developer, but this is their fault. They've invested all their resources into building out the infrastructure, and have spent very little if any time on building the UX around it. You have to be fairly technical, never mind painstakingly detailed-oriented, in order to manage their services, a big chunk of which is hidden behind black screens and various control nobs. Amazon's logic is probably…
Amazon probably can't change S3 for backwards compatibility reasons (there was an outcry about just changing some legacy URLs last year), but they definitely can and should make an "S4" which would be an S3 compatible storage layer with sane defaults. Essentially, people only ever want one of two things: - A private FTP bucket - A public static asset website (with built-in CDN and HTTPS!) Thing people never want: - A…
>Thing people never want:
>
>- A public upload bucket
Thus is outright wrong. Public upload s3 buckets are AWS's go-to basic technique to handle file uploads. AWS's API Gateway has a max file limit, and AWS advises developers to leverage S3 and lambda triggers to implement that usecases.
Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK
#140Earlier quoted context omitted.
Amazon probably can't change S3 for backwards compatibility reasons (there was an outcry about just changing some legacy URLs last year), but they definitely can and should make an "S4" which would be an S3 compatible storage layer with sane defaults. Essentially, people only ever want one of two things: - A private FTP bucket - A public static asset website (with built-in CDN and HTTPS!) Thing people never want: - A…
What's the fourth S stand for?
> What's the fourth S stand for?
Second Simple Storage Service.