Live data from Hacker News

NPM debug and chalk packages compromised

aikido.dev

381–390 of 796 posts

Re: NPM debug and chalk packages compromised

#381

Scoket was all over this - https://socket.dev/blog/npm-author-qix-compromised-in-major-...

Nathan, do you work for Socket? I think you should at least disclose that when sharing posts here.

I've never heard of Socket before this thread. They could be taking advantage of this news and promoting the company, as it's mentioned quite a few times in this thread. Or it's just a good service that I should probably be using.

Re: NPM debug and chalk packages compromised

#382

Here we are again. 12 days ago ( https://news.ycombinator.com/item?id=45039764 ) I commented how a similar compromise of Nx was totally preventable. Again, this is not the failure of a single person. This is a failure of the software industry . Supply chain attacks have gigantic impacts. Yet these are all solved problems. Somebody has to just implement the standard security measures that prevents these compromises. W…

People focus on attacking windows because there are more windows users. What if I told you the world now has a lot more people involved in programming with JavaScript and Python?

You’re right, this will only get a lot worse.

Re: NPM debug and chalk packages compromised

#383
post #85

Earlier quoted context omitted.

Meanwhile in Python: 134 million weekly downloads, seemingly slowly trending upward over time, for https://pypistats.org/packages/six which provides third-party compatibility for a version of Python that dropped support over five years ago.

Most of these downloads, I would bet, are from CI

Oh, I don't doubt it at all. But that doesn't make it any less depressing to me. Nor does it matter to Fastly's bandwidth burden.

Re: NPM debug and chalk packages compromised

#384

Earlier quoted context omitted.

Not the parent, but the default `npm install` / `yarn install` builds will ignore the lock file unless everything can be satisfied, if you want the lock file to be respected you must use `npm ci` / `yarn install --frozen-lockfile`. In my experience, it's common for CI pipelines to be misconfigured in this way, and for Node developers to misunderstand what the lock file is for.

Not a web guy, but that seems a bonkers default. I would have naively assumed a lockfile would be used unless explicitly ignored.

Welcome to the web side. Everything’s bonkers. Hard-earned software engineering truths get tossed out, because hey, wtf, I’ll just do some stuff and yippee. Feels like everyone’s stuck at year three of software engineering, and every three years the people get swapped out.

Re: NPM debug and chalk packages compromised

#385

Earlier quoted context omitted.

NPM is owned by GitHub and therefore Microsoft, who is too busy putting in Copilot into apps that have 0 reason to have any form of generative AI in them

Good god. Not everything has to be about your opinion on AI.

Actually, they could probably use AI to see if each update to a package looks malicious or obfuscated.

Re: NPM debug and chalk packages compromised

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

Atlassian and MS are terrible for making email notifications that are really hard to distinguish from phishing emails. Using hard to identify undocumented random domains in long redirect chains, obfuscating links etc etc.

Re: NPM debug and chalk packages compromised

#387
post #245

Earlier quoted context omitted.

Real registries do[1], npm is just amateur-hour which is why its usage is typically forbidden in enterprise contexts. [1] https://www.debian.org/doc/manuals/securing-debian-manual/de...

In all fairness—npm belongs to GitHub, which belongs to Microsoft. Amateur-hour is both not a valid excuse anymore, and also a boring explanation. GitHub is going to great lengths to enable SLSA attestations for secure tool chains; there must be systemic issues in the JS ecosystem that make an implementation of proper attestations infeasible right now, everything else wouldn't really make sense. So if we're discussin…

Yeah Microsoft would have bought or taken over npm just to train on all the data against peoples wills, not to actually improve or put any effort into making it better

Re: NPM debug and chalk packages compromised

#388
post #253

Earlier quoted context omitted.

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?

OP entered their credentials and TOTP code, which the attacker proxied to the real npmjs.com FWIW npmjs does support FIDO2 including hard tokens like Yubikey. They do not force re-auth when issuing an access token with publish rights, which is probably how the attackers compromised the packages. iirc GitHub does force re-auth when you request an access token.

> They do not force re-auth when issuing an access token with publish rights, which is probably how the attackers compromised the packages

I'm surprised by this. Yeah, GitHub definitely forces you to re-auth when accessing certain settings.

Re: NPM debug and chalk packages compromised

#389

Earlier quoted context omitted.

This is the answer IMO. The number of targets and noise would be a lot less if JS had a decent stdlib or if we had access to a better language in the browser. I have no hope of this ever happening and am abandoning the web as a platform for interactive applications in my own projects. I’d rather build native applications using SDL3 or anything else.

But this can't be the whole story. In the Java world, it's pretty common to import a couple huge libraries full of utility functions, but those are each one import , that you can track and version and pay attention to. Apache Commons helper libraries don't import sub libraries for every little thing, they collect a large toolbox into a single library/jar. Why instead do people in the javascript ecosystem insist on se…

I didn't used to be. It's just become less trendy to import a big giant Lodash, Underscore, Sugar, or even jQuery.

Re: NPM debug and chalk packages compromised

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

We should be displaying hashes in a color scheme determined by the hash (foreground/background colors for each character determined by a hash of the hash, salted by that character's index, adjusted to ensure sufficient contrast). That way it's much harder to make one hash look like another.

Not sure why you're being downvoted, OpenSSH implemented randomart which gives you a little ascii "picture" of your key to make it easier for humans to validate. I have no idea if your scheme for producing keyart would work but it sounds like it would make a color "barcode".
Post reply on HN