Most active commenters
  • lelanthran(6)
  • rollcat(3)

←back to thread

NPM debug and chalk packages compromised

(www.aikido.dev)
1369 points universesquid | 15 comments | 08 Sep 25 15:37 UTC | HN request time: 0.001s | source | bottom
Show context
junon ◴[08 Sep 25 15:49 UTC] No.45169794[source]▶
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-convert@3.1.1

- color-name@2.0.1

- is-arrayish@0.3.3

- slice-ansi@7.1.1

- color@5.0.1

- color-string@2.1.1

- simple-swizzle@0.2.3

- supports-hyperlinks@4.1.1

- has-ansi@6.0.1

- chalk-template@1.1.1

- backslash@0.2.1

It looks and feels a bit like a targeted attack.

Will try to keep this comment updated as long as I can before the edit expires.

---

Chalk has been published over. The others remain compromised (8 Sep 17:50 CEST).

NPM has yet to get back to me. My NPM account is entirely unreachable; forgot password system does not work. I have no recourse right now but to wait.

Email came from support at npmjs dot help.

Looked legitimate at first glance. Not making excuses, just had a long week and a panicky morning and was just trying to knock something off my list of to-dos. Made the mistake of clicking the link instead of going directly to the site like I normally would (since I was mobile).

Just NPM is affected. Updates to be posted to the `/debug-js` link above.

Again, I'm so sorry.

replies(39): >>45169833 #>>45169877 #>>45169899 #>>45169922 #>>45170115 #>>45170202 #>>45170608 #>>45170631 #>>45170738 #>>45170943 #>>45171084 #>>45171127 #>>45171420 #>>45171444 #>>45171619 #>>45171648 #>>45171666 #>>45171859 #>>45172334 #>>45172346 #>>45172355 #>>45172660 #>>45172846 #>>45174599 #>>45174607 #>>45175160 #>>45175246 #>>45176250 #>>45176355 #>>45176505 #>>45177184 #>>45177316 #>>45178543 #>>45178719 #>>45182153 #>>45183937 #>>45194407 #>>45194912 #>>45229781 #
nodesocket ◴[08 Sep 25 15:58 UTC] No.45169899[source]▶
What did the phishing email say that made you click and login?
replies(1): >>45170070 #
junon ◴[08 Sep 25 16:12 UTC] No.45170070[source]▶
That it had been more than 12 months since last updating them. Npm has done outreach before about doing security changes/enhancements in the past so this didn't really catch me.

Screenshot here: https://imgur.com/a/q8s235k

replies(7): >>45170187 #>>45170240 #>>45170308 #>>45170321 #>>45170333 #>>45170335 #>>45171291 #
rollcat ◴[08 Sep 25 16:31 UTC] No.45170335[source]▶
@everyone in the industry, everywhere:

Urgency is poison.

Please, please put a foot in the door whenever you see anyone trying to push this kind of sh*t on your users. Make one month's advance notice the golden standard.

I see this pattern in scam mail (including physical) all the time: stamp an unreasonably short notice and expect the mark to panic. This scam works - and this is why legit companies that try this "in good faith" should be shamed for doing it.

Actual alerts: just notify. Take immediate, preventive, but non-destructive action, and help the user figure out how to right it - on their own terms.

replies(1): >>45171125 #
notmyjob ◴[08 Sep 25 17:28 UTC] No.45171125[source]▶
Agree, but this example wasn’t even that aggressive in its urgency and op said they were merely ticking things off the todo, not feeling alarmed by the urgency. The problem is email as it’s used currently. The solution is to not use email.
replies(3): >>45171417 #>>45172700 #>>45173543 #
1. lelanthran ◴[08 Sep 25 20:30 UTC] No.45173543[source]▶
> The problem is email as it’s used currently. The solution is to not use email.

No. The problem is unsigned package repositories.

The solution is to tie a package to an identity using a certificate. Quickest way I can think off would be requiring packages to be linked to a domain so that the repository can always check incoming changes to packages using the incoming signature against the domain certificate.

replies(4): >>45174057 #>>45175941 #>>45180210 #>>45181866 #
2. cluckindan ◴[08 Sep 25 21:11 UTC] No.45174057[source]▶
And one pwned domain later, we are back in square one.
replies(1): >>45177524 #
3. dabockster ◴[09 Sep 25 00:29 UTC] No.45175941[source]▶
That wouldn't work against a really sophisticated attacker. Especially for something that's clearly being maintained for free by one overworked person in their spare time (yet again).

You'd need some kind of offline verification method as well for these widely used infrastructure libraries.

replies(1): >>45179137 #
4. lelanthran ◴[09 Sep 25 04:47 UTC] No.45177524[source]▶
> And one pwned domain later, we are back in square one.

1. It's an extra step: before you pwn the package, you need to pwn a domain.

2. When a domain is pwned, the packages it signs can be revoked with a single command.

5. lelanthran ◴[09 Sep 25 08:26 UTC] No.45179137[source]▶
> That wouldn't work against a really sophisticated attacker.

Nothing "really works" against a sophisticated hacker :-/ Doesn't mean that "defense in depth" does not apply.

> You'd need some kind of offline verification method as well for these widely used infrastructure libraries.

I don't understand why this is an issue, or even what it means: uploading a new package to the repository requires the contributor to be online anyway. The new/updated/replacement package will have to be signed. The signature must be verified by the upload script/handler. The verification can be done using the X509 certificate issued for the domain of the contributor.

1. If the contributor cannot afford the few dollars a year for a domain, they are extremely vulnerable to the supply chain attack anyway (by selling the maintenance of the package to a bad actor), and you shouldn't trust them anyway.

2. If the contributor's domain gets compromised you only have to revoke that specific certificate, and all packages signed with that certificate, in the past or in the future, would not be installable.

As I have repeatedly said in the past, NPM (and the JS tools development community in general) had no adults in the room during the design phase. Everything about JS stacks feels like it was designed by children who had never programmed in anything else before.

It's a total clown show.

replies(2): >>45181071 #>>45182425 #
6. rollcat ◴[09 Sep 25 10:46 UTC] No.45180210[source]▶
> The solution is to tie a package to an identity using a certificate.

Identity on the Internet is a lie. Nobody knows you're a dog.

The solution is to make security easy and accessible, so that the user can't be confused into doing the insecure thing.

replies(1): >>45181591 #
7. idiotsecant ◴[09 Sep 25 12:32 UTC] No.45181071{3}[source]▶
If only they would have had the benefit of you being around to do all that work with your glorious hindsight.
replies(1): >>45181107 #
8. lelanthran ◴[09 Sep 25 12:36 UTC] No.45181107{4}[source]▶
> If only they would have had the benefit of you being around to do all that work with your glorious hindsight.

They didn't need me; plenty of repositories doing signed packages existed well before npm was created.

Which is why I likened them to a bunch of kids - they didn't look around at how the existing repos were designed, they just did the first thing that popped into their head.

replies(1): >>45191920 #
9. lelanthran ◴[09 Sep 25 13:23 UTC] No.45181591[source]▶
> Identity on the Internet is a lie.

What do you think HTTPS is?

replies(2): >>45183094 #>>45196677 #
10. benchloftbrunch ◴[09 Sep 25 13:48 UTC] No.45181866[source]▶
As long as you're OK with self signed certificates or PGP keys, I'd be on board with this.

I really, really dislike the idea of using TLS certificates as we know them for this purpose, because the certificate authority system is too centralized, hierarchical, and bureaucratic, tightly coupled to the DNS.

That system is great for the centralized, hierarchical, bureaucratic enterprises who designed it in the 90s, but would be a pain in the ass for a solo developer, especially with the upcoming change to 45 day lifetimes.

replies(1): >>45182842 #
11. benchloftbrunch ◴[09 Sep 25 14:28 UTC] No.45182425{3}[source]▶
> X509 certificate

It should be a PGP or SSH key, absolutely not an X509 certificate (unless you allow self signed).

Personal identity keys should be fully autonomous and not contingent on the formal recognition of any external authority.

12. lelanthran ◴[09 Sep 25 15:00 UTC] No.45182842[source]▶
> As long as you're OK with self signed certificates or PGP keys, I'd be on board with this.

I am with PGP but more wary of self-signed certs, though even self-signed certs allow mass revocation of packages when an author's cert is compromised.

13. mdaniel ◴[09 Sep 25 15:15 UTC] No.45183094{3}[source]▶
Transport Layer Security, and has nothing to do with Identity. Take for example the perfectly valid certificate that was issued for npmjs[.]help which unquestionably does not belong to Microsoft/GitHub. Hell, even the certificate for npmjs.com is 'O=Google Trust Services' which doesn't sound like any of the business entities one would expect to own that cert
14. idiotsecant ◴[10 Sep 25 01:24 UTC] No.45191920{5}[source]▶
On the other hand, they did the actual work when nobody else did. It's so easy to take potshots, when you've never done anything consequential enough for the results to matter as much as they do for npm.
15. rollcat ◴[10 Sep 25 12:29 UTC] No.45196677{3}[source]▶
"Whoever was on the cacert list that ships with your browser" has signed "I claim to be Acme Widgets Inc. and I own microsoft.com".