Live data from Hacker News

NPM debug and chalk packages compromised

aikido.dev

361–370 of 796 posts

Re: NPM debug and chalk packages compromised

#361

Earlier quoted context omitted.

> You can pretend like this is unique to JS ecosystem, but xz was compromised for 3 years. Okay, but you're not suggesting that a compression algorithm is the same scale as "is-arrayish". I don't think everyone should need to reimplement LZMA but installing a library to determine if a value is an array is bordering on satire.

FWIW, is-arrayish is primarily an internal dependency. The author (Qix) depends on it for the packages that actually get used, liked color and error-ex. But it's all one author.

They should ban Qix.

Re: NPM debug and chalk packages compromised

#362

Earlier quoted context omitted.

No, I have never, ever responded to an explicit ask to reset the most important security feature of my accounts, without me initiating it, and I use a password manager (lol) so, no, I will never, ever encounter this problem. Because I care about my data, safety, and integrity, and my users'. There's literally no reason ever why I would or will do a 2FA reset. It does happen, yes, it's not terrifying.

The wording was similar to how GitHub started requiring 2FA. It wasn't "there is the 2FA change that initiate" it was more of starting September 10 we will starting to request 2fa

Edit: I get it, it was a pw+top phishing/proxy attack.

Wouldn't have happened if they used passkeys or a password manager. Things that get dunked on here regularly. Hm.

Re: NPM debug and chalk packages compromised

#364
post #56

Earlier quoted context omitted.

How is it terrifying? They clicked through a 2FA reset email, a process that I have never, and will never need to go through, and seemingly one that they didn't even initiate.

How many developers are there like him? If not him, they'll target someone else. And while you or I will never do such a thing under normal circumstances, that's a pretty simple mistake to make if you are stressed, sleep deprived or sick. We are supposed to have automatic safeguards against such simple mistakes. (We used to design stuff with the assumption that if a human mistake is possible, someone will eventually…

[deleted]

Re: NPM debug and chalk packages compromised

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

I hate that kind of email when sent out legitimately. Google does this crap all the time pretty much conditioning their customers to click those links. And if you're really lucky it's from some subdomain they never bothered advertising as legit. Great of you to own up to it.

I’ve started ignoring these types of emails and wait to do any sort of credentials reset until I get an alert when I log in (or try to) for just this reason.

Re: NPM debug and chalk packages compromised

#366
post #68
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…

Just want to agree with everyone who is thanking you for owning up (and so quickly). Got phished once while drunk in college (a long time ago), could have been anyone. NPM being slowish to get back to you is a bit surprising, though. Seems like that would only make attacks more lucrative.

[dead]

Re: NPM debug and chalk packages compromised

#368

I've come to the conclusion that avoiding the npm registry is a great benefit. The alternative is to import packages directly from the (git) repository. Apart from being a major vector for supply-chain attacks like this one, it is also true that there is little or no coupling between the source of a project and its published code. The 'npm publish' step takes pushes local contents into the registry, meaning that a ma…

As a C developer, having being told for a decade that minimising dependencies and vendoring stuff straight from release is obsolete and regressive, and now seeing people have the novel realisation that it's not, is so so surreal. Although I'll still be told that using single-header libraries and avoiding the C standard library are regressive and obsolete, so gotta wait 10 more years I guess.

NPM dev gets hacked, packages compromised, it's detected within couple of hours.

XZ got hacked, it reached development versions of major distributions undetected, right inside an _ssh_, and it only got detected due to someone luckily noticing and investigated slow ssh connections.

Still some C devs will think it's a great time to come out and boast about their practices and tooling. :shrug:

Re: NPM debug and chalk packages compromised

#369
post #119

Earlier quoted context omitted.

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

I'm thinking on what all the anti-passkey folks have to say right now. Or the "password managers aren't necessary" crowd.

Re: NPM debug and chalk packages compromised

#370
post #61

I have nothing to do with this but still I am getting second hand embarrassment. Here is an example, is-arrayish package, 73.8 MILLION downloads per week. The code? 3 lines to check if an object can be used like an array. I am sorry, but this is not due to not having a good standard library, this is just bad programming. Just pure laziness. At this point just blacklist every package starting with is-.

You don’t get it. People don’t add “is-arrayish” directly as a dependency. It goes like this:

1) N tiny dubious modules like that are created by maintainers (like Qix)

2) The maintainer then creates 1 super useful non-tiny module that imports those N dubious modules.

3) Normal devs add that super useful module as a dependency… and ofc, they end up with countless dubious transitive dependencies

Why maintainers do that? I don’t think it’s ignorance or laziness or lack of knowledge about good software engineering. It’s because either ego (“I’m the maintainer of N packages with millions of downloads” sounds better than “I’m the maintainer of 1 package “), or because they get more donations or because they are actually planning to drop malware some time soon.

Post reply on HN