English is not my main language, but "broke into" doesn't implicate "breaking" something to get "into" something?
"break into" means "gained unauthorized entry" or more simply "got into without permission".
Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK
11–20 of 162 posts
Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK
#12Aws should start taking blame for this shit, then maybe they would start auditing their customers setups...
Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK
#13S3 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 sin…
[deleted]
Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK
#14S3 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 sin…
This looks safe, and most importantly correct setup, but looks like it will not support Twillo use case
Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK
#15would using the `integrity` attribute in the ` ` tag mitigate this attack?
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...
Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK
#16Aws should start taking blame for this shit, then maybe they would start auditing their customers setups...
* how should AWS know when its customers want the permissions they choose and when they don't?
* the cost of auditing would be spread across all customers equally, punishing competent customers and benefitting incompetent ones..
Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK
#17Aws should start taking blame for this shit, then maybe they would start auditing their customers setups...
[deleted]
Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK
#18S3 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 sin…
What you described sounds like a pain.
Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK
#19S3 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 sin…
I just started a toy project using S3, and at least to a novice user, it was a confusing, overwhelming array of options and linked pieces. It felt like being hit with a lot of advanced options all at once, with no obvious happy path for common cases.
I'm sure an expert finds it all very natural. Security is always hard and has to be done right the first time. That's a domain that's always going to deter novices, and perhaps the only way forward is to hire an expert to ensure you're doing the right thing.
Still... I've been programming for four decades and it felt a little odd to be quite so out of my depth. It's not the same as anything I've done before, but it felt like it shouldn't have been quite so bewildering.
Re: Twilio: Someone broke into our AWS S3 silo, added 'non-malicious' code to JS SDK
#20> someone was able to get into Twilio's Amazon Web Services S3 bucket, which was left unprotected and world-writable
"Someone" was able? If the bucket was unprotected and world-writable, then _everyone_ was able.
> 'non-malicious'
> And judging from the URL involved, it appears to be an attempt to install a payment-card skimmer – RiskIQ has spotted the same URL in other S3 buckets targeted by miscreants.
In what world is that non-malicious? Non-immediately-damaging _maybe_, but it seems clear that there was a malicious chain of reasoning involved. Twilio got super lucky if this is all that happened.