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

Re:Twilio: Someone broke into our AWS S3 silo, added 'non-ma... by aka1234 on Wednesday July 22, 2020 @01:56PM (#23919708)

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 that bucket policy should tell you something named "Allow Public Read" should NOT be associated with anything named 'Put'. This takes 0 AWS knowledge to figure out.

[ Parent | on HN ]

Re:Twilio: Someone broke into our AWS S3 silo, added 'non-ma... by oefrha on Wednesday July 22, 2020 @02:10PM (#23919866)

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.

[ Parent | on HN ]

Re:Twilio: Someone broke into our AWS S3 silo, added 'non-ma... by ficklepickle on Wednesday July 22, 2020 @02:34PM (#23920142)

Even if the payload was not malicious when they looked, it could change at any time. I don't see how that can be confidently labeled non-malicious.

[ Parent | on HN ]

Re:Twilio: Someone broke into our AWS S3 silo, added 'non-ma... by aka1234 on Wednesday July 22, 2020 @04:37PM (#23921300)

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.

[ Parent | on HN ]