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

NPM debug and chalk packages compromised

aikido.dev

Post reply on HN
Print view View original

491–500 of 796 posts

Re: NPM debug and chalk packages compromised

#491

Post by jiggawatts »

parliament32 wrote: post #267
9dev wrote: post #245

Earlier quoted context omitted.

In all fairness—npm belongs to GitHub, which belongs to Microsoft. Amateur-hour is both not a valid excuse anymore, and also a boring explanation. GitHub is going to great lengths to enable SLSA attestations for secure tool chains; there must be systemic issues in the JS ecosystem that make an implementation of proper attestations infeasible right now, everything else wouldn't really make sense. So if we're discussin…

The NPM team has repeatedly commented that it's "too hard", effectively, and would discourage new developers from publishing packages. See: https://github.com/npm/npm/pull/4016#issuecomment-76316744 https://news.ycombinator.com/item?id=38645969 https://github.com/npm/cli/commit/5a3b345d6d5d175ea9ec967364...

> discourage new developers from publishing packages

Good.

Re: NPM debug and chalk packages compromised

#492

Post by andix »

I've posted this idea already last time with the nx incident: we need some mechanism for package managers to ignore new packages for a defined time. Skip all packages that were published less than 24 hours ago.

Most of those attacks are detected and fixed quickly, because a lot of people check newly published packages. Also the owners and contributors notice it quickly. But a lot of consumers of the package just install the newest release. With some grace period those attacks would be less critical.

Re: NPM debug and chalk packages compromised

#493

Post by const_cast »

paxys wrote: post #422

Yeah I know "everyone can be pwned" etc. but at this point if you are not using a password manager and still entering passwords on random websites whose domains don't match the official one then you have no business doing anything of value on the internet.

This is true, but I've also run into legitimate password fields on different domains. Multiple times. The absolute worst offender is mobile app vs browser.

Why does the mobile app use a completely different domain? Who designed this thing?

Re: NPM debug and chalk packages compromised

#494

Post by xrd »

webdev1234568 wrote: post #430
xrd wrote: post #286

It wouldn't be a perfect solution, but I wonder why browsers don't indicate the registration date for a domain in the URL bar somehow? I bet junon would have seen that and gotten suspicious.

that's a good one not perfect for sure, hackers would just start buying domains earlier but still...

Yeah, but there is a takedown process when a spam site is detected (the server provider can shut off access, etc), so it is a game that is somewhat winnable.

Re: NPM debug and chalk packages compromised

#495

Post by andix »

PokestarFan wrote: post #174
cddotdotslash wrote: post #154

NPM deserves some blame here, IMO. Countless third party intel feeds and security startups can apparently detect this malicious activity, yet NPM, the single source of truth for these packages, with access to literally every data event and security signal, can't seem to stop falling victim to this type of attack? It's practically willful ignorance at this point.

NPM is owned by GitHub and therefore Microsoft, who is too busy putting in Copilot into apps that have 0 reason to have any form of generative AI in them

Is it really owned and run by Microsoft? I thought they only provide infrastructure, servers and funding.

Re: NPM debug and chalk packages compromised

#496

Post by johanyc »

aftbit wrote: post #451
junon wrote: post #9

Hi, yep I got pwned. Sorry everyone, very embarrassing. More info: - https://github.com/chalk/chalk/issues/656 - https://github.com/debug-js/debug/issues/1005#issuecomment-3... Affected packages (at least the ones I know of): - ansi-styles@6.2.2 - debug@4.4.2 (appears to have been yanked as of 8 Sep 18:09 CEST) - chalk@5.6.1 - supports-color@10.2.1 - strip-ansi@7.1.1 - ansi-regex@6.2.1 - wrap-ansi@9.0.1 - color-conve…

Didn't your password manager notice that npmjs dot help was not a legit domain and avoid auto-filling there?

https://news.ycombinator.com/item?id=45175125

Re: NPM debug and chalk packages compromised

#497

Post by hsbauauvhabzb »

fn-mote wrote: post #469
hsbauauvhabzb wrote: post #394

Earlier quoted context omitted.

[flagged]

You could at least offer some kind of substantive criticism of the tool (“socket”).

Do I need any? Automated tools cannot prevent malicious code being injected. While they can make attempts to evaluate common heuristics and will catch low hanging malware, they are not fool proof against highly targeted attacks.

Either way, the parent post is clearly ambulance chasing rather than having a productive conversation, which should really be about whether or not automatically downloading and executing huge hierarchal trees of code is absolutely fucking crazy, rather than a blatant attempt to make money off an ongoing problem without actually solving anything.

Re: NPM debug and chalk packages compromised

#498

Post by 33a »

Yoric wrote: post #412
33a wrote: post #246

Earlier quoted context omitted.

We also caught this right away at Socket, https://socket.dev/blog/npm-author-qix-compromised-in-major-... While it sucks that this happened, the good thing is that the ecosystem mobilized quickly. I think these sorts of incidents really show why package scanning is essential for securing open source package repositories.

So how do you detect these attacks?

We use a mix of static analysis and AI. Flagged packages are escalated to a human review team. If we catch a malicious package, we notify our users, block installation and report them to the upstream package registries. Suspected malicious packages that have not yet been reviewed by a human are blocked for our users, but we don't try to get them removed until after they have been triaged by a human.

In this incident, we detected the packages quickly, reported them, and they were taken down shortly after. Given how high profile the attack was we also published an analysis soon after, as did others in the ecosystem.

We try to be transparent with how Socket work. We've published the details of our systems in several papers, and I've also given a few talks on how our malware scanner works at various conferences:

* https://arxiv.org/html/2403.12196v2

* https://www.youtube.com/watch?v=cxJPiMwoIyY

Re: NPM debug and chalk packages compromised

#499

Post by 33a »

hsbauauvhabzb wrote: post #497
fn-mote wrote: post #469

Earlier quoted context omitted.

You could at least offer some kind of substantive criticism of the tool (“socket”).

Do I need any? Automated tools cannot prevent malicious code being injected. While they can make attempts to evaluate common heuristics and will catch low hanging malware, they are not fool proof against highly targeted attacks. Either way, the parent post is clearly ambulance chasing rather than having a productive conversation, which should really be about whether or not automatically downloading and executing huge…

When we find malware on any registry (npm, rubygems, pypi or otherwise), we immediately report it to the upstream registry and try to get it taken down. This helps reduce the blast radius from incidents like this and mitigates the damage done to the entire ecosystem.

You can call it ambulance chasing, but I think this is a good thing for the whole software ecosystem if people aren't accidentally bundling cryptostealers in their web apps.

And regarding not copying massive trees of untrusted dependencies: I am actually all for this! It's better to have fewer dependencies, but this is also not how software works today. Given the imperfect world we have, I think it's better to at least try to do something to detect and block malware than just complain about npm.

Re: NPM debug and chalk packages compromised

#500

Post by dabockster »

fn-mote wrote: post #466
dmitrygr wrote: post #404

Earlier quoted context omitted.

> don't we consider things like `brew` to be sufficiently low-risk, Like ... npm?

Nah… Everybody knows npm is a gaping security issue waiting to happen. Repeatedly. It’s convenient, so it’s popular. Many people also don’t vendor their own dependencies, which would slow down the spread at the price of not being instantly up to date.

> Many people also don’t vendor their own dependencies, which would slow down the spread at the price of not being instantly up to date.

npm sold it really hard that you could rely on them and not have to vendor dependencies yourself. If I suggested that a decade ago in Seattle, I would have gotten booed out of the room.

Post reply on HN