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

151–160 of 162 posts

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

#151

Post by erik_seaberg »

stevehawk wrote: post #111
fimbulvetr wrote: post #103

Earlier quoted context omitted.

For such an important bucket, they should have a. adopted the resource into a Cloudformation stack & a1. Enabled drift detection. b. Use an AWS config rule to monitor (appropriate) s3 buckets for any public access.

1. Drift detection is a relatively new feature. 2. CloudFormation was so basic for so long that most AWS professionals don't use it. They use Terraform or a similar, non AWS product.

CloudFormation didn't support importing existing resources until last November. For years you had to let it recreate everything you need, if you hadn't used it from day one. That's a big part of what kept us on Terraform.

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

#152

Post by jlgaddis »

natpalmer1776 wrote: post #59

I was curious about the URL that they indicated was non-malicious and so looked it up on google. I found this any.run report: Report: https://any.run/report/e8c581d52ca3527b61c7ddd9aba5dfeaf9440... Original URL: h t t p s : / / gold.platinumus.top/track/awswrite?q=dmn

Nice find. That certainly indicates the exact opposite of "non-malicious".

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

#153

Post by heavenlyblue »

ryanlol wrote: post #142
heavenlyblue wrote: post #136

Earlier quoted context omitted.

If someone drove drunk and drove into a pedestrian who survives after a month in ER does this diminish the severity of drinking or not?

An incident where the pedestrian isn’t killed is almost certainly less severe than one where the pedestrian is killed.

I just don’t see how that diminishes the action of crime though.

A failed drug dealer (who got caught), by your definition, should get less time because they never managed to sell the drugs they were transporting over the border and got caught :)

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

#154

Post by heavenlyblue »

ryanlol wrote: post #142
heavenlyblue wrote: post #136

Earlier quoted context omitted.

If someone drove drunk and drove into a pedestrian who survives after a month in ER does this diminish the severity of drinking or not?

An incident where the pedestrian isn’t killed is almost certainly less severe than one where the pedestrian is killed.

Maybe only in America (but American law system is heavily biased towards people who have enough money to navigate it) - where deals and various legalese are a usual concept.

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

#155

Post by soco »

politelemon wrote: post #99
kirillzubovsky wrote: post #61

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

I'm not seeing any UX problems here. They configured an S3 access policy incorrectly while troubleshooting, 5 years ago. FTFA: > During our incident review, we identified that this path was not initially configured with public write access when it was added in 2015. We implemented a change 5 months later while troubleshooting a problem with one of our build systems and the permissions on that path were not properly r…

This is exactly one of the things Terraform would catch and correct in a snap. I rather think Twilio was so confident before they had everything understood and smooth running that they didn't need other tools like Terraform. Infrastructure as code emerged as a thing EXACTLY because cloud's hundreds of consoles and checkboxes and whatnot, although each one simple and logical, spinned out of our mind's capacity to hold.

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

#156

Post by ryanlol »

heavenlyblue wrote: post #153
ryanlol wrote: post #142

Earlier quoted context omitted.

An incident where the pedestrian isn’t killed is almost certainly less severe than one where the pedestrian is killed.

I just don’t see how that diminishes the action of crime though. A failed drug dealer (who got caught), by your definition, should get less time because they never managed to sell the drugs they were transporting over the border and got caught :)

But why are we talking about the justice system here?

The impact of these actions matters far more to the victims than whatever consequence the perpetrator may face.

If your website was affected by this hack, surely you’d care about how your customers were impacted.

Lots of people here keep repeating the claim that this was magecart, that’s just not true.

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

#157

Post by sterkekoffie »

untog wrote: post #98
sterkekoffie wrote: post #47

Earlier quoted context omitted.

>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.

> the only-case scenario is that all the sites you have pulling from that CDN break until you recompute the hash Until you recompute the hash and communicate that new hash to them and they implement it on their site. It’s not nothing from an implementation point of view.

I'm not sure who "you" and "they" are in this scenario so I apologize if this isn't what you're getting at: the failure -> fallback -> threat evaluation-> remediation process can be entirely automated except the evaluation part. I'm not a web developer so I don't know the incidence rate of using unstable builds in production and having to patch stable builds, so maybe having to manually evaluate threats in this way /would/ be annoying, but the actual devops seems pretty trivial.

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

#158

Post by kyboren »

disiplus wrote: post #130
u801e wrote: post #92

Earlier quoted context omitted.

> PSTN-based 2FA in 2020 is not a vote of confidence in the security team's competence. A lot of companies go with email and/or PSTN based 2FA for customer convenience and to get them to use 2FA for their accounts. I try to avoid using 2FA for accounts that only offer PSTN or email based 2FA because it's less secure than my randomly generated long password. It would be nice if more services offered 2FA based on clien…

i would not say it's less secure. Even if somebody overtakes one of my machine and gets to my lastpass vault or steals my clipboard having my smartphone with me and a SMS or PSTN based 2FA is better then not having it at all.

If implemented properly, it's totally possible that security is not reduced for that user. However there are at least three problems with it:

1) When not implemented properly, it is treated as an alternative authentication mechanism, not an additional required mechanism. My ultra strong password is useless if it's enough to steal my phone number and convince customer support that the attacker simply forgot the password.

2) It gives a false sense of security. I already have 2FA enabled! What do you mean I should be using TOTP/FIDO2/TLS client certificates?!

3) It reinforces an unfortunately widespread security anti-pattern, which reduces security for Web users in aggregate. So what if it's not a great idea? Everyone is doing it! Or put another way, MD5 password hashing is better than storing passwords in plain text. But please, please, please do not use MD5 password hashing! There are much better ways to accomplish that goal without introducing more flaws.

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

#159

Post by codeduck »

donor20 wrote: post #90

One thing I wish AWS would do. Allow admins to "down feature" the account. Ie, simple mode. Basically, allow admins to toggle OFF S3 ACL's and even S3 Bucket Policies - zero those out. Then let users use IAM policies for access which may be a more familiar / more used mental model.

A better approach is simply not to grant normal users modify access to IAM, VPC, or anything else potentially destructive, and force them to make all changes via a ci/cd pipeline with ops/sre oversight and review.

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

#160

Post by earthboundkid »

rumanator wrote: post #139
earthboundkid wrote: post #132

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

>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.

No (see sister comments) and your incorrect answer is part of why AWS needs to reform S3.
Post reply on HN