Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We all dodged a bullet

xeiaso.net

Post reply on HN
Print view View original

301–310 of 498 posts

Re: We all dodged a bullet

#301

Post by homebrewer »

kardianos wrote: post #277
anon7000 wrote: post #31

The nx supply chain attack via npm was the bullet many companies did not doge. I mean, all you needed was to have the VS Code nx plugin installed — which always checked for the latest published nx version on npm. And if you had a local session with GitHub (eg logged into your company’s account via the GH CLI), or some important creds in a .env file… that was exfiltrated. This happened even if you had pinned dependenc…

> We need some deeper changes in the ecosystem. I avoid anything to do with NPM, except for the typescript compiler, and I'm looking forward to the rewrite in Go where I can remove even that. For this reason. As a comparison, in Go, you have minimum version spec, and it takes great pains to never execute anything you download, even during compilation stage. NPM will often have different source then the github repo so…

It's already solved by pnpm, which refuses to execute any postinstall scripts except those you whitelist manually. In most projects I don't enable any and everything works fine, in the worst case I had to enable two scripts (out of two dozen or so) that download prebuilt native components, although even those aren't really necessary and it could have been solved through other means (proven by typescript-go, swc, and other projects led by competent maintainers).

None of it will help you when you're executing the binaries you built, regardless of which language they were written in.

Re: We all dodged a bullet

#302

Post by theteapot »

Article:

> This is frankly a really good phishing email ... This is a 10/10 phishing email ..

Phishing email:

> As part of our on going commitment to account security, we are requesting that all users update their Two-Factor-Authentication (2FA) credentials ...

What does that even mean? What type of 2FA needs updating? One 2FA method supported is OTP. Can't see a reason that would legitimately ever need to be updated, so doesn't really pass the sniff test that every single user would need to "update 2FA".

Re: We all dodged a bullet

#303

Post by pixl97 »

mikewarot wrote: post #28

>Saved by procrastination! Seriously, this is one of my key survival mechanisms. By the time I became system administrator for a small services company, I had learned to let other people beta test things. We ran Microsoft Office 2000 for 12 years, and saved soooo many upgrade headaches. We had a decade without the need to retrain. That, and like other have said... never clicking links in emails.

Works great for new exploited packages. Not so great for already compromised software getting hit by a worm.

Re: We all dodged a bullet

#304

Post by dghlsakjg »

MichaelZuo wrote: post #283
dghlsakjg wrote: post #264

Earlier quoted context omitted.

As the developer in charge of looking at security alerts for this code base, I already am responsible, which is why I submitted the exemption request in the first place. As it is, this alert has been active for months and no one from security has asked about the alert, just my exemption request, so clearly the actual fix (disregarding or code changes) are less important than the process and alert itself. So the solut…

So you agree with me the ops person is behaving sensibly given real life constraints? Edit: I didn’t comment on all those other points, so it seems irrelevant to the one question I asked.

Absolutely not.

Ops are the ones who imposed those constraints. You can't impose absurd constraints and then say you are acting reasonable by abiding by your own absurd constraints.

Re: We all dodged a bullet

#305

Post by jowea »

charlieyu1 wrote: post #184
quectophoton wrote: post #62

Earlier quoted context omitted.

Then you have companies like AWS, they were sending invoices from `no-reply-aws@amazon.com` but last month they changed it to `no-reply@tax-and-invoicing.us-east-1.amazonaws.com`. That looks like a phishing attempt from someone using a random EC2 instance or something, but apparently it's legit. I think . Even the "heads-up" email they sent beforehand looked like phishing, so I was waiting for the actual invoice to s…

I thought facebookmail.com was fake. No, it is actually legit

Is that for user email? I think that is semi-understandable as Facebook wouldn't want to mix their authority with that of the users, like github.com vs github.io.

Edit: nvm it seems it's not the case

Re: We all dodged a bullet

#306

Post by austin-cheney »

kardianos wrote: post #277
anon7000 wrote: post #31

The nx supply chain attack via npm was the bullet many companies did not doge. I mean, all you needed was to have the VS Code nx plugin installed — which always checked for the latest published nx version on npm. And if you had a local session with GitHub (eg logged into your company’s account via the GH CLI), or some important creds in a .env file… that was exfiltrated. This happened even if you had pinned dependenc…

> We need some deeper changes in the ecosystem. I avoid anything to do with NPM, except for the typescript compiler, and I'm looking forward to the rewrite in Go where I can remove even that. For this reason. As a comparison, in Go, you have minimum version spec, and it takes great pains to never execute anything you download, even during compilation stage. NPM will often have different source then the github repo so…

I am now using the type remover in Node to run TupeScript natively. It’s great and so fast. Even still I continue to include the TypeScript compiler in my projects so that I can run TSC with the no compile option just for the type auditing.

Re: We all dodged a bullet

#307

Post by int_19h »

crazygringo wrote: post #60
Groxx wrote: post #51

Earlier quoted context omitted.

I'm rather convinced that the next major language-feature wave will be permissions for libraries. It's painfully clear that we're well past the point where it's needed. I didn't think it'll make things perfect, not by a long shot. But it can make the exploits a lot harder to pull off.

Totally agreed, and I'm surprised this idea hasn't become more mainstream yet. If a package wants to access the filesystem, shell, OS API's, sockets, etc., those should be permissions you have to explicitly grant in your code.

This exact idea has already been mainstream. Both Java and .NET used to have mechanisms like that, e.g.: https://en.wikipedia.org/wiki/Code_Access_Security

Re: We all dodged a bullet

#308

Post by jowea »

benreesman wrote: post #289

Now imagine if someone combined Jia Tan patience with swiss-cheese security like all of our editor plugins and nifty shell user land stuff and all that. Developer stuff is arguably the least scrutinized thing that routinely runs as mega root. I wish I could say that I audit every elisp, neovim, vscode plugin and every nifty modern replacement for some creaky GNU userland tool. But bat, zoxide, fzf, atuin, starship, v…

Someday, someone, hopefully, will fix xkcd 1200.

Re: We all dodged a bullet

#309

Post by jowea »

gcau wrote: post #267
Zak wrote: post #231

> If you were targeted with such a phishing attack, you'd fall for it too and it's a matter of when not if. Anyone who claims they wouldn't is wrong. I like to think I wouldn't. I don't put credentials into links from emails that I didn't trigger right then (e.g. password reset emails). That's a security skill everyone should be practicing in 2025.

"'such' a phishing attack" makes it sound like a sophisticated, indepth attack, when in reality it's a developer yet again falling for a phishing email that even Sally from finance wouldn't fall for, and although anyone can make mistakes, there is such a thing as negligent, amateur mistakes. It's astonishing to me.

I feel that most everyone has some 0.0001% chance of falling for a stupid trick. And at scale, a tiny chance means someone will fall for it.

Re: We all dodged a bullet

#310

Post by nialv7 »

com2kid wrote: post #58
sebstefan wrote: post #48

Dodged a bullet indeed I find it insane that someone would get access to a package like this, then just push a shitty crypto stealer. You're a criminal with a one-in-a-million opportunity. Wouldn't you invest an extra week pushing a more fledged out exploit? You can exfiltrate API keys, add your SSH public key to the server then exfiltrate the server's IP address so you can snoop in there manually, if you're on a dev…

> You're a criminal with a one-in-a-million opportunity. Wouldn't you invest an extra week pushing a more fledged out exploit? Because the way this was pulled off, it was going to be found out right away. It wasn't a subtle insertion, it was a complete account take over. The attacker had only hours before discovery - so the logical thing to do is a hit and run. They asked what is the most money that can be extracted…

> it was a complete account take over

is that so? from the email it looks like they MITM'd the 2FA setup process, so they will have qix's 2FA secret. they don't have to immediately start taking over qix's account and lock him out. they should have had all the time they need to come up with a more sophisticated payload.

Post reply on HN