Live data from Hacker News

NPM debug and chalk packages compromised

aikido.dev

321–330 of 796 posts

Re: NPM debug and chalk packages compromised

#321
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…

> Made the mistake of clicking the link instead of going directly to the site like I normally would (since I was mobile). Does anyone know how this attack works? Is it a CSRF against npmjs.com?

Probably just a fake site.

Re: NPM debug and chalk packages compromised

#322
post #314

Earlier quoted context omitted.

0x66a9893cC07D91D95644AEDD05D03f95e1dBA8Af 0x10ed43c718714eb63d5aa57b78b54704e256024e 0x13f4ea83d0bd40e75c8222255bc855a974568dd4 0x1111111254eeb25477b68fb85ed929f73a960582 0xd9e1ce17f2641f24ae83637ab66a2cca9c378b9f Source: https://github.com/chalk/chalk/issues/656#issuecomment-32670...

Next comment: > Those are swap contract addresses, not attacker addresses. E.g. 0x66a9893cC07D91D95644AEDD05D03f95e1dBA8Af the Uniswap v4 universal router addr. > Every indication so far is that the attacker stole $0 from all of this. Which is a best-case outcome.

Oh, that makes much more sense - thanks!

Re: NPM debug and chalk packages compromised

#323
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…

> Made the mistake of clicking the link instead of going directly to the site like I normally would (since I was mobile). Does anyone know how this attack works? Is it a CSRF against npmjs.com?

That was the low-tech part of their attack, and was my fault - both for clicking on it and for my phrasing.

It wasn't a single-click attack, sorry for the confusion. I logged into their fake site with a TOTP code.

Re: NPM debug and chalk packages compromised

#324
post #52

One of the most insidious parts of this malware's payload, which isn't getting enough attention, is how it chooses the replacement wallet address. It doesn't just pick one at random from its list. It actually calculates the Levenshtein distance between the legitimate address and every address in its own list. It then selects the attacker's address that is visually most similar to the original one. This is a brilliant…

Can you attribute this technique to a specific group?

Almost certainly Lazarus

Re: NPM debug and chalk packages compromised

#325
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…

Thank you for the swift and candid response, this has to suck. :/ > The author appears to have deleted most of the compromised package before losing access to his account. At the time of writing, the package simple-swizzle is still compromised. Is this quote from TFA incorrect, since npm hasn’t yanked anything yet?

Quote is probably added recently. Not entirely correct as I have not regained access; nothing happening to the packages is of my own doing.

npm does appear to have yanked a few, slowly, but I still don't have any insight as to what they're doing exactly.

Re: NPM debug and chalk packages compromised

#326
post #273

From sindresorhus: You can run the following to check if you have the malware in your dependency tree: `rg -u --max-columns=80 _0x112fa8` Requires ripgrep: `brew install rg` https://github.com/chalk/chalk/issues/656#issuecomment-32668...

Asking people to run random install scripts just feels very out of place given the context.

I would agree if this were one of those `curl | sh` scenarios, but don't we consider things like `brew` to be sufficiently low-risk, akin to `apt`, `dnf`, and the like?

Re: NPM debug and chalk packages compromised

#327
post #99

Earlier quoted context omitted.

Every day brings me another reason to ask the question: "Why the hell did they throw away the idea of mutual TLS?". They then went onto invent mobile OTP, HOTP, TOTP, FIDO-U2F and finally came a full cycle by reinventing the same concept, but in a more complex incarnation - Passkeys.

the UI for client side certificates was shit for years. no one particularly cared. passkeys however are... pretty reasonable.

At least on a Mac, you can just double-click a cert file, it'll prompt to install in Keychain, and anything using macOS's TLS implementation will see it.

Re: NPM debug and chalk packages compromised

#328
post #309
post #260

Earlier quoted context omitted.

As OC mentioned elsewhere, it was a targeted TOTP proxy attack.

So, he clicked the link and then entered his correct TOTP? how would manually typing the url instead of clicking the link have mitigated this?

They wouldn't have manually typed the exact URL from the email, they would have just typed in npmjs.com which would ensure they ended up on the real NPM site. Or even if they did type out the exact URL from the email, it would have made them much more likely to notice that it was not the real NPM URL.

Re: NPM debug and chalk packages compromised

#329

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.

Why would NPM do anything about it? NPM has been a great source of distributing malware for like a decade now, and none of you have stopped using it. Why in the world would they NEED to stop? It apparently doesn't harm their "business"

Dozens of businesses have been built to try fixing the npm security problem. There's clearly money in it, even if MS were to charge an access fee for security features.

Re: NPM debug and chalk packages compromised

#330

Earlier quoted context omitted.

Perfect example of why habituating users to renewing credentials (typically password expiration) is a terrible practice.

is there an actual habituation? that message feels like it could work as a first-time as well

We should be immediately suspicious when we get any solicitation to "renew" something "expired" in a security domain. Swapping un-compromised secrets is essentially always more risky than leaving them be.

Regardless of whether the real NPM had done this in the past, decades of dumb password expiration policies have trained us that requests like this are to be expected rather than suspected.

Post reply on HN