Looks like OP is one of the contributors to LavaMoat
mohsen1 · 58m 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 · 45m ago
I think malware check should be opt-on for package authors, but provide some kind of 'verified' badge to the package.
naugtur · 33m 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 · 23m ago
“within hours” is at least one hour too late, and most likely multiple hours.
naugtur · 39s 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_ · 35m ago
i can guarantee you npm will externalize the cost of false-positive malware scans to package authors.
nodesocket · 28m ago
Or at a minimum support yubikey for 2fa.
worthless-trash · 12m ago
Original author could be evil. 2fa does nothing.
clbrmbr · 35m ago
How much money have the attackers stolen so far? Has someone done an analysis of the blockchains for the destination addresses?
naugtur · 34m ago
click through to the article, it has a link to a view that lists the laughable profit
clbrmbr · 31m 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.
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 · 21m ago
It was discovered pretty quickly, i don’t think most “big” projects update their packages within minutes of publication.
p2detar · 33m 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 · 48m ago
You're using HMR in your app's production bundle? How?
naugtur · 27m 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 · 33m 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 · 29m 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 · 22m 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 · 23m ago
Re: updates: I was just thinking of waiting a few weeks on the updates to allow compromised packages to be discovered.
vel0city · 23m ago
The package-lock.json includes a hash of the package, not just a version number which should be immutable.
whilenot-dev · 19m 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.
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.