Live data from Hacker News

NPM debug and chalk packages compromised

aikido.dev

251–260 of 796 posts

Re: NPM debug and chalk packages compromised

#251

After all these incidents, I still can't understand why package registries don't require cryptographic signatures on every package. It introduces a bit more friction (developers downloading CI artifacts and manually signing and uploading them), but it prevents most security incidents. Of course, this can fail if it's automated by some CI/CD system, as those are apparently easily compromised.

Mmm. But how does the package registry know which signing keys to trust from you? You can't just log in and upload a signing key because that means that anyone who stole your 2FA will log in and upload their own signing key, and then sign their payload with that . I guess having some cool down period after some strange profile activity (e.g. you've suddenly logged from China instead of Germany) before you're allowed…

Supporting Passkeys would improve things; not allowing releases for a grace period after adding new signing keys and sending notifications about this to all known means of contact would improve them some more. Ultimately, there will always be ways; this is as much a people problem as it is a technical one.

Re: NPM debug and chalk packages compromised

#252
post #119

Earlier quoted context omitted.

Did they also phish the login password after clicking the link or did they already have it?

They phished username, password (unique to npm), and a TOTP code. They even gave me a new TOTP code to install (lol) and it worked. Showed up in authy fine. Whoever made this put a ton of effort into it.

Damn, that's an impressively well-done attack. Curious, do you use a password manager? If so, did it not autofilling feel like a red flag to you?

I've always wondered if I ever get phished if I'll notice bc of that or if I'll just go "ugh 1password isn't working, guess i'll paste my password in manually" and end up pwned

Re: NPM debug and chalk packages compromised

#253
post #202

Earlier quoted context omitted.

How did simply opening this email in something like Gmail or a desktop client result in it being able to compromise NPM packages under your control? I'm just curious - and as a word of warning to others so we can learn. I may be missing some details, I've read most of the comments on the page.

I clicked the link like a genius :)

I don't understand. The link could've come from anywhere (for example from a HN comment). How does just clicking on it give your package credentials to someone else? Is NPM also at fault here? I'd naively think that this shouldn't be possible.

For example, GitHub asks for 2FA when I change certain repo settings (or when deleting a repo etc.) even when I'm logged in. Maybe NPM needs to do the same?

Re: NPM debug and chalk packages compromised

#254
Tips to protect yourself from supply-chain attacks in the JavaScript ecosystem:

- Don't update dependencies unless necessary

- Don't use `npm` to install NPM packages, use Deno with appropriate sandboxing flags

- Sign up for https://socket.dev and/or https://www.aikido.dev

- Work inside a VM

Re: NPM debug and chalk packages compromised

#255

Earlier quoted context omitted.

Lack of a good batteries-included stdlib. You're either importing a ton of little dependencies (which then depend on other small libraries) or you end up writing a ton of really basic functionality yourself.

But why can’t we have a good library instead of those mini thingies?

Because "look at how many open source packages I maintain!"

At a time small JS libraries were desired, and good library marketing approach, but nowadays simple sites ship megabytes of without a care.

In particular this developer is symptomatic of the problem of the NPM ecosystem and I've used him multiple times as an example of what not to do.

Re: NPM debug and chalk packages compromised

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

> the UI for client side certificates was shit for years. no one particularly cared.

That's exactly what I mean! Who would use it if the UI/UX is terrible? Many Gemini (protocol) browsers like Lagrange have such pleasant UIs for it, though somewhat minimal. With sufficient push, you could have used mutual TLS from even hardware tokens.

Re: NPM debug and chalk packages compromised

#258

Earlier quoted context omitted.

It only proves that TOTP is useless against phishing.

TOTP isnt designed to be against phishing. Its against weak, leaked or cracked passwords.

Lots of junk TOTP apps in app stores.

Once heard of a user putting in a helpdesk ticket asking why they had to pay for the TOTP app. Then I realize their TOTP seed is probably out in the open now.

I’m sure we can imagine how else this could go badly…

Re: NPM debug and chalk packages compromised

#259
post #82

Earlier quoted context omitted.

To be fair, this is not a problem with the web itself, but with the Node ecosystem. It's perfectly possible to build web apps without relying on npm at all, or by being very selective and conservative about the packages you choose as your direct and transitive dependencies. If not by reviewing every line of code, then certainly by vendoring them. Yes, this is more inconvenient and labor intensive, but the alternative…

I'm often surprised at the number of JS experts who struggle with the basics of the browser API. Instead of reasoning through the problem, many will reach for a framework or library.

Especially with the MDN, an amazing resource.

Re: NPM debug and chalk packages compromised

#260
post #253
post #202

Earlier quoted context omitted.

I clicked the link like a genius :)

I don't understand. The link could've come from anywhere (for example from a HN comment). How does just clicking on it give your package credentials to someone else? Is NPM also at fault here? I'd naively think that this shouldn't be possible. For example, GitHub asks for 2FA when I change certain repo settings (or when deleting a repo etc.) even when I'm logged in. Maybe NPM needs to do the same?

As OC mentioned elsewhere, it was a targeted TOTP proxy attack.
Post reply on HN