Looks like OP is one of the contributors to LavaMoat
mohsen1 · 1h ago
npm should take responsibility and up their game here. It’s possible to analyze the code and mark it as suspicious and delay the publish for stuff like this. It should prevent publishing code like this even if I have a gun to my head
sesm · 47m ago
I think malware check should be opt-on for package authors, but provide some kind of 'verified' badge to the package.
naugtur · 35m ago
npm is on life support by msft. But there's socket.dev that can tell you if a package is malicious within hours of it being published.
shreddit · 25m ago
“within hours” is at least one hour too late, and most likely multiple hours.
naugtur · 2m ago
Absolutely not. you get npm packages by pulling not them pushing them to you as soon as a new version exist. The likelyhood of you updating instantly is close to zero and if not, you should set your stuff up so that it is. Many ways to do that.
Even better if compared to a month or two - which is how long it often takes for a researcher to find a carefully planted malware.
Anyway, the case where reactive tools (detections, warnings) don't catch it is why LavaMoat exists. It prevents whole classes of malware from working at runtime.
The article (and repo) demonstrates that.
untitaker_ · 37m ago
i can guarantee you npm will externalize the cost of false-positive malware scans to package authors.
nodesocket · 30m ago
Or at a minimum support yubikey for 2fa.
worthless-trash · 14m ago
Original author could be evil. 2fa does nothing.
clbrmbr · 37m ago
How much money have the attackers stolen so far? Has someone done an analysis of the blockchains for the destination addresses?
naugtur · 36m ago
click through to the article, it has a link to a view that lists the laughable profit
clbrmbr · 32m ago
Huh. I read TFA in detail (and shared with my team), but I didn’t see any analysis. (?)
>Pretty low impact for an attack this big. Some of it seems to be people mocking the malware author with worthless transfers.
I believe this is the section. As far as I understand the link, it's about $500. I don't understand how you read if a donation is a worthless mockery donation.
naugtur · 19s ago
I work with people who understand this stuff :D
But if I see a transaction for thousands or millions of a coin I've never heard of with $ value of about 1 it's likely a shitcoin and I am guessing - mockery.
I'm actually shocked they have not stolen more seeing the breach impact radius? Perhaps we can thank wallets and exchanges for blacklisting the addresses and showing huge warnings like the one shown in the article.
shreddit · 23m ago
It was discovered pretty quickly, i don’t think most “big” projects update their packages within minutes of publication.
pixl97 · 1m ago
Really I'd say the key here is timing. I didn't look into what time the NPM packages were updated, but there are a few key times depending on what markets you're targeting. If it were Indian devs it would be around 2AM CST and if it's US devs it would be around 10AM CST.
This is when I see the ramp up in queuing in CI/CD builds that lasts a few hours across companies and is more likely to trigger a package getting rebuilt.
p2detar · 35m ago
I’ve been out of the loop with npm for a while, but are there still no package namespaces?
I’m intrigued but is that compartmentalization not incredibly expensive?
cluckindan · 1h ago
LavaMoat looks great on paper, but not supporting Webpack HMR is a dealbreaker.
naugtur · 50m ago
You're using HMR in your app's production bundle? How?
naugtur · 29m ago
If you mean during development - you can opt out of using lavamoat in development for your webpack bundle (I'm assuming you're not running your untested code on valuable data)
clbrmbr · 35m ago
Is it typical in the JS space to include dependencies without versioning?
Also, curious: does freezing a version really provide much protection? Shouldn’t a commit hash be used? (Attacker can change a tag.)
naugtur · 31m ago
packages published to npm are immutable. if you pin a version, you get the same exact version as long as MSFT servers are not compromised.
You are supposed to update packages, even if you use lockfiles (very common) or tools that pin your direct dependencies (renovate etc. not so common)
And when you do update, will you read the package and all of its updated dependencies?
It's a hard problem with a bunch of tradeoffs.
Can be done, with enough attention and tools. Tools include LavaMoat :)
whilenot-dev · 24m ago
> packages published to npm are immutable.
Depends how you'd refer to them... tags ("@latest", "@next" etc.) are not immutable and it's best to rely on the checksums in the lock file.
clbrmbr · 24m ago
Re: updates: I was just thinking of waiting a few weeks on the updates to allow compromised packages to be discovered.
vel0city · 25m ago
The package-lock.json includes a hash of the package, not just a version number which should be immutable.
whilenot-dev · 21m ago
To add to this: the hash in the lock file is the checksum of the published tarball, not the commit hash.
Anyway, the case where reactive tools (detections, warnings) don't catch it is why LavaMoat exists. It prevents whole classes of malware from working at runtime. The article (and repo) demonstrates that.
>Pretty low impact for an attack this big. Some of it seems to be people mocking the malware author with worthless transfers.
I believe this is the section. As far as I understand the link, it's about $500. I don't understand how you read if a donation is a worthless mockery donation.
500 USD, not bad for a month of work if the author is from a 3rd world country.
This is when I see the ramp up in queuing in CI/CD builds that lasts a few hours across companies and is more likely to trigger a package getting rebuilt.
Also, curious: does freezing a version really provide much protection? Shouldn’t a commit hash be used? (Attacker can change a tag.)
Installing from git is not recommended and has more issues than you might think https://dev.to/naugtur/a-phish-on-a-fork-no-chips-52cc
You are supposed to update packages, even if you use lockfiles (very common) or tools that pin your direct dependencies (renovate etc. not so common) And when you do update, will you read the package and all of its updated dependencies?
It's a hard problem with a bunch of tradeoffs.
Can be done, with enough attention and tools. Tools include LavaMoat :)
Depends how you'd refer to them... tags ("@latest", "@next" etc.) are not immutable and it's best to rely on the checksums in the lock file.