Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You too can run malware from NPM (I mean without consequences)

github.com

Post reply on HN
Print view View original

21–30 of 122 posts

Re: You too can run malware from NPM (I mean without consequences)

#21

Post by clbrmbr »

naugtur wrote: post #14
clbrmbr wrote: post #10

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.)

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. 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 comm…

Re: updates: I was just thinking of waiting a few weeks on the updates to allow compromised packages to be discovered.

Re: You too can run malware from NPM (I mean without consequences)

#22

Post by whilenot-dev »

naugtur wrote: post #14
clbrmbr wrote: post #10

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.)

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. 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 comm…

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

Re: You too can run malware from NPM (I mean without consequences)

#23

Post by shreddit »

nodesocket wrote: post #17
naugtur wrote: post #8

Earlier quoted context omitted.

click through to the article, it has a link to a view that lists the laughable profit

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.

It was discovered pretty quickly, i don’t think most “big” projects update their packages within minutes of publication.

Re: You too can run malware from NPM (I mean without consequences)

#24

Post by whilenot-dev »

vel0city wrote: post #19
clbrmbr wrote: post #10

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.)

The package-lock.json includes a hash of the package, not just a version number which should be immutable.

To add to this: the hash in the lock file is the checksum of the published tarball, not the commit hash.

Re: You too can run malware from NPM (I mean without consequences)

#26

Post by worthless-trash »

nodesocket wrote: post #15
mohsen1 wrote: post #3

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

Or at a minimum support yubikey for 2fa.

Original author could be evil. 2fa does nothing.

Re: You too can run malware from NPM (I mean without consequences)

#27

Post by crtasm »

clbrmbr wrote: post #13
naugtur wrote: post #8

Earlier quoted context omitted.

click through to the article, it has a link to a view that lists the laughable profit

Huh. I read TFA in detail (and shared with my team), but I didn’t see any analysis. (?)

I think they mean the link to https://intel.arkm.com/explorer/entity/61fbc095-f19b-479d-a0...

Re: You too can run malware from NPM (I mean without consequences)

#28

Post by hiccuphippo »

clbrmbr wrote: post #13
naugtur wrote: post #8

Earlier quoted context omitted.

click through to the article, it has a link to a view that lists the laughable profit

Huh. I read TFA in detail (and shared with my team), but I didn’t see any analysis. (?)

It seems to be this: https://intel.arkm.com/explorer/entity/61fbc095-f19b-479d-a0...

500 USD, not bad for a month of work if the author is from a 3rd world country.

Re: You too can run malware from NPM (I mean without consequences)

#29

Post by wodenokoto »

clbrmbr wrote: post #13
naugtur wrote: post #8

Earlier quoted context omitted.

click through to the article, it has a link to a view that lists the laughable profit

Huh. I read TFA in detail (and shared with my team), but I didn’t see any analysis. (?)

> I won't go into this either, but you can take a look at the summary of "donations" some other friends linked to here: https://intel.arkm.com/explorer/entity/61fbc095-f19b-479d-a0...

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

Re: You too can run malware from NPM (I mean without consequences)

#30

Post by naugtur »

shreddit wrote: post #20
naugtur wrote: post #11

Earlier quoted context omitted.

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.

“within hours” is at least one hour too late, and most likely multiple hours.

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.

Post reply on HN