Most active commenters
  • goku12(5)
  • dboreham(3)
  • junon(3)
  • (3)

←back to thread

NPM debug and chalk packages compromised

(www.aikido.dev)
1369 points universesquid | 23 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 #
dboreham ◴[08 Sep 25 15:56 UTC] No.45169877[source]▶
Sorry to be dumb, but can you expand a bit on "2FA reset email..." so the rest of us know what not to do?
replies(2): >>45169963 #>>45170666 #
junon ◴[08 Sep 25 16:03 UTC] No.45169963[source]▶
Ignore anything coming from npm you didn't expect. Don't click links, go to the website directly and address it there. That's what I should have done, and didn't because I was in a rush.

Don't do security things when you're not fully awake, too. Lesson learned.

The email was a "2FA update" email telling me it's been 12 months since I updated 2FA. That should have been a red flag but I've seen similarly dumb things coming from well-intentioned sites before. Since npm has historically been in contact about new security enhancements, this didn't smell particularly unbelievable to my nose.

The email went to the npm-specific inbox, which is another way I can verify them. That address can be queried publicly but I don't generally count on spammers to find that one but instead look at git addresses etc

The domain name was `npmjs dot help` which obviously should have caught my eye, and would have if I was a bit more awake.

The actual in-email link matched what I'd expect on npm's actual site, too.

I'm still trying to work out exactly how they got access. They didn't technically get a real 2FA code from the actual, I don't believe. EDIT: Yeah they did, nevermind. Was a TOTP proxy attack, or whatever you'd call it.

Will post a post-mortem when everything is said and done.

replies(5): >>45170150 #>>45170205 #>>45170263 #>>45170777 #>>45183746 #
1. dboreham ◴[08 Sep 25 16:17 UTC] No.45170150[source]▶
I see (I think): they tricked you into entering a TOTP code into their site, which they then proxied to the real names, thereby authenticating as your account. Is that correct?
replies(2): >>45170181 #>>45170226 #
2. junon ◴[08 Sep 25 16:19 UTC] No.45170181[source]▶
Seems so, yes.
3. sugarpimpdorsey ◴[08 Sep 25 16:23 UTC] No.45170226[source]▶
It only proves that TOTP is useless against phishing.
replies(4): >>45170375 #>>45170694 #>>45171362 #>>45205312 #
4. goku12 ◴[08 Sep 25 16:33 UTC] No.45170375[source]▶
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.
replies(4): >>45170685 #>>45170763 #>>45171121 #>>45171778 #
5. ◴[08 Sep 25 16:55 UTC] No.45170685{3}[source]▶
6. dboreham ◴[08 Sep 25 16:56 UTC] No.45170694[source]▶
Yes. This attack would not have worked if FIDO2 (or the software emulation Passkey) had been used.
7. quotemstr ◴[08 Sep 25 17:02 UTC] No.45170763{3}[source]▶
Because the tech industry egregore is a middling LLM that gets it context window compacted every generation.
8. tpxl ◴[08 Sep 25 17:28 UTC] No.45171121{3}[source]▶
Works this way for my government and my bank. I was given a cert matching my real name and the login just asks for my cert and pulls me through (with additional 2FA for the bank). Pretty amazing if you ask me.
replies(1): >>45171505 #
9. ksdnjweusdnkl21 ◴[08 Sep 25 17:44 UTC] No.45171362[source]▶
TOTP isnt designed to be against phishing. Its against weak, leaked or cracked passwords.
replies(2): >>45171692 #>>45171950 #
10. goku12 ◴[08 Sep 25 17:53 UTC] No.45171505{4}[source]▶
Which government is this, if I may ask?
replies(1): >>45175207 #
11. ◴[08 Sep 25 18:06 UTC] No.45171692{3}[source]▶
12. mschuster91 ◴[08 Sep 25 18:12 UTC] No.45171778{3}[source]▶
the UI for client side certificates was shit for years. no one particularly cared. passkeys however are... pretty reasonable.
replies(4): >>45171942 #>>45172714 #>>45172783 #>>45172891 #
13. goku12 ◴[08 Sep 25 18:27 UTC] No.45171942{4}[source]▶
> 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.

14. Scoundreller ◴[08 Sep 25 18:27 UTC] No.45171950{3}[source]▶
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…

15. ◴[08 Sep 25 19:23 UTC] No.45172714{4}[source]▶
16. chuckadams ◴[08 Sep 25 19:29 UTC] No.45172783{4}[source]▶
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.
replies(1): >>45178241 #
17. xorcist ◴[08 Sep 25 19:38 UTC] No.45172891{4}[source]▶
That's just it. If any of the browser vendors put 1% of the work they spent on renewing their visual identity, remodeling their home page, or inventing yet another menu system into slightly easier to use client certificates (and smart cards) this would have been a solved problem two decades ago. All the pieces are in place, every browser has supported this since the birth of SSL, it's just the user interface bits that are missing.

It's nothing short of amazing that nobody worked on this. It's not as if there isn't a need. Everyone with high security requirements (defense, banks etc.) already do this, but this clumsy plugins and (semi-)proprietary software. Instead we get the nth iteration of settings redesigns.

replies(1): >>45178259 #
18. SahAssar ◴[08 Sep 25 22:57 UTC] No.45175207{5}[source]▶
I'm going to guess estonia which has had this since mid 2000's IIRC.
replies(1): >>45178466 #
19. goku12 ◴[09 Sep 25 06:35 UTC] No.45178241{5}[source]▶
And what about the browser? How does it know which client cert (I assume the key is also there) to use for a site? Does it prompt you before proceeding with authentication?
replies(1): >>45181466 #
20. goku12 ◴[09 Sep 25 06:37 UTC] No.45178259{5}[source]▶
Bingo! Exactly my point. Thanks!
21. jve ◴[09 Sep 25 07:00 UTC] No.45178466{6}[source]▶
Latvia has it too. We have ID cards which is a smartcard, we use that to set up some authentication app that allows us to authenticate within online services and can even do remotely transactions like selling the house (well that is the extreme case and one needs to connect to teams meeting and show your face and have high quality video/connection and show your id card, along with digital auth). But anyways, it is used all around the place, many many sites support that auth, the banks support it and even remote auth scenarios are possible. Just today was calling mobile operator support and they had to verify me - so after saying my ID, an auth request pops up from app that asks to verify identity to mobile operator (app shows who is asking for auth).

Authentications are separated and if some signature must be placed or money to be sent, you must use other access code and the app shows the intention of what are you authorizing. If it is money being sent, you see where and how much you want to sent before you approve this request on the app.

But the app is all tied to digital identity from the id card in the first place - to set up these strong authentication guarantees in the first place you use your ID card. Some time ago we had to use computer with smartcard reader to set it up, nowdays I dunno whether it is NFC or something, but the mobile phone can read the ID card.

22. chuckadams ◴[09 Sep 25 13:10 UTC] No.45181466{6}[source]▶
The domains the cert gets presented to is also configured in Keychain, and Safari uses it. Looks like Firefox has its own thing, buried several layers deep in settings. No idea about chrome. It's definitely a process you'd want to script in an installer, nothing you'd want to subject the end user to. So yeah, still pretty crap UX overall.
23. patrakov ◴[10 Sep 25 23:03 UTC] No.45205312[source]▶
No. It only proves that TOTP, as implemented by mobile apps, is useless against phishing.

The extension from https://authenticator.cc, with smart domain match enabled, would have caught this by showing all other TOTP codes besides the one intended by NPM.

On a Mac, Keychain would also have caught this by not autofilling: https://support.apple.com/en-ph/guide/passwords/mchl873a6e72...