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

391–400 of 498 posts

Re: We all dodged a bullet

#391

Post by h1fra »

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…

You are lying to yourself. In this attack, nothing was executed by npm; it "just" replaced some global functions. A Go package can't do that, but you can definitely execute malware at runtime anyway. It can also expose new imports that will be imported by mistake when using an IDE.

Re: We all dodged a bullet

#392

Post by junon »

ruuda wrote: post #182
empathy_m wrote: post #64

How much money did the attackers make?

I'm not sure whether the compromised packages were the source of Kiln's API compromise, but it's plausible. It lead to theft of $41M worth of SOL. https://cointelegraph.com/news/swissborg-hacked-41m-sol-api-...

These were different. The vulnerable packages wouldn't have caused an API exploit vector except in the most bizarre of edge cases I suppose.

Re: We all dodged a bullet

#393

Post by nedt »

We haven't been saved by procrastination. We literally were saying "oh that's a new version, we are always behind anyway". Of course everything was still checked, but actually having the latest version on packages is almost never needed and we rather update when we have to (because version is old) instead of when there is a new version. Nothing new is that awesome.

Re: We all dodged a bullet

#394

Post by junon »

lrvick wrote: post #280

Daily reminder that no one can easily impersonate you if you sign your commits and make it easy to discover and verify your authentic key with keyoxide or similar.

This wasn't a repository takeover. I do sign my commits.

Re: We all dodged a bullet

#395

Post by junon »

kiitos wrote: post #270
zaphar wrote: post #41

Earlier quoted context omitted.

I go through those trainings several times a year. That email is as close to perfect for a phishing email as I've ever seen.

the link in the email went to an obviously invalid domain, hovering the mouse cursor over the link in the email would have made this immediately clear, so even clicking that link should have never happened in the first place. red flag 1 but, ok, you click the link, you get a new tab, and you're asked to fill in your auth credentials. but why? you should already be logged in to that service in your default browser, no…

> the link in the email went to an obviously invalid domain, hovering the mouse cursor over the link in the email would have made this immediately clear, so even clicking that link should have never happened in the first place. red flag 1

The link went to the same domain as the From address. The URL scheme was 1:1 identical to the real npm's.

> but, ok, you click the link, you get a new tab, and you're asked to fill in your auth credentials. but why? you should already be logged in to that service in your default browser, no? red flag 2

Why wouldn't I be? I don't stay logged into npm at all.

Re: We all dodged a bullet

#396

Post by strogonoff »

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…

Before we all conclude that supply chain attacks only happen on NPM, last time I used VS Code I discovered that it auto-installed, with no apparent opt-out, Python typing stubs for any package (e.g., Django in my case) from whatever third-party, unofficial PyPI accounts it saw fit. (Yes, this is why it was the last time I used VS Code.)

The obscurity of languages other than JavaScript will only work as a security measure for so long.

Re: We all dodged a bullet

#397

Post by jFriedensreich »

That post fails to address the main issue, its not that we don't have time to vet dependencies, its that nodejs s security and default package model is absurd and how we use it even more. Even most deno posts i see use “allow all” for laziness which i assume will be copy pasted by everyone because its a major pain of UX to get to the right minimal permissions. The only programming model i am aware if that makes it painful enough to use a dependency, encourages hard pinning and vetted dependency distribution and forces explicit minimal capability based permission setup is cloudflares workerd. You can even set it up to have workers (without changing their code) run fully isolated from network and only communicate via a policy evaluator for ingress and egress. It is apache licensed so it is beyond me why this is not the default for use-cases it fits.

Re: We all dodged a bullet

#398

Post by herewulf »

lynnharry wrote: post #388
oezi wrote: post #361

Earlier quoted context omitted.

The key thing needed is a standard library which includes 100000 of these tiny one function libraries (has-ansi, color-name).

I checked has-ansi. What's the reason that this library would exist and be popular? Most of the work is done by the library it imports, ansi-regex and then it just return ansi-regex.test(string), yet it has 5% of the weekly downloads of ansi-regex. ansi-regex also has fewer than 10 lines of code. I don't know anything about the npm ecosystem, what's the benefit of importing these libraries compared to including these…

The benefit is getting your secrets stolen and pointing the blame at someone else? Yeah...

Re: We all dodged a bullet

#399

Post by komali2 »

giveita wrote: post #374
ameliaquining wrote: post #133

Earlier quoted context omitted.

If a dev doesn't happen to run npm install during the period between when the compromised package gets published and when npm yanks it (which for something this high-profile is generally measured in hours, not days), then they aren't going to be impacted. So an attacker's patience won't be rewarded with many valid credentials.

Dev, or their IDE, agent, etc.

Their build chain, CI environment, server...

Re: We all dodged a bullet

#400

Post by mb2100 »

jFriedensreich wrote: post #397

That post fails to address the main issue, its not that we don't have time to vet dependencies, its that nodejs s security and default package model is absurd and how we use it even more. Even most deno posts i see use “allow all” for laziness which i assume will be copy pasted by everyone because its a major pain of UX to get to the right minimal permissions. The only programming model i am aware if that makes it pa…

To be fair, the advantage of Deno here is really the standard library that includes way more functionality than Node.

But in the end, we should all rely on fewer dependencies. It's certainly the philosophy I'm trying to follow with https://mastrojs.github.io – see e.g. https://jsr.io/@mastrojs/mastro/dependencies

Post reply on HN