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

Axios compromised on NPM – Malicious versions drop remote access trojan

stepsecurity.io

Post reply on HN
Print view View original

641–650 of 894 posts

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#641

Post by password4321 »

cortesoft wrote: post #596
dt3ft wrote: post #592

Earlier quoted context omitted.

And when you actually need a super hot fix for a 0-day, you will need to revert this and keep it that way for some time to then go back to minimum age. While this works, we stillneed a permanent solution which requires a sort of vetting process, rather than blindly letting everything through.

Who will do the vetting process?

I think my vetting would settle for a repo diff against the previous version, confirming the only difference was the security fix (though that doesn't cover all the bases).

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#642

Post by staticassertion »

mladen5 wrote: post #640
staticassertion wrote: post #387

Earlier quoted context omitted.

They're not a failed experiment. No one has ever "experimented" by making a safe package manager for their new language. And it is not that insane to do so. Very basic things will get you very far: 1. Packages should carry a manifest that declares what they do at build time, just like Chrome extensions do. This manifest would then be used to configure its build environment. 2. Publishers to official registries should…

I don't understand commercial aspect of large OSS like package managers but i was wondering for years why this was missing from npm. I think typosquatting was handled by npm last year but only after some popular miss typed packages started stealing developer creds.

The people building package managers are unaware of these problems going into it and it becomes extremely disruptive to start adding these things later on since your entire ecosystem is built on the assumption that they can do these things.

It's also shockingly controversial to suggest typosquatting suggestions. I made this suggestion ages ago for cargo, demonstrated that basic distance checks would have impacted <1% of crates over all time, and people still didn't want it.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#643

Post by flerchin »

croemer wrote: post #623
flerchin wrote: post #622

Ok it's bad, but our npm projects are pinned in the package-lock.json, which I imagine most would be? So who would pull this besides security scanners?

`npm install` might be enough to pull it, unless you pin down to the patch?

I don't think that's right if it's in your package-lock it wouldn't pull it unless you npm update axios, or delete the package-lock.json and then npm install.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#645

Post by benoau »

h4ch1 wrote: post #13

I can't even imagine the scale of the impact with Axios being compromised, nearly every other project uses it for some reason instead of fetch (I never understood why). Also from the report: > Neither malicious version contains a single line of malicious code inside axios itself. Instead, both inject a fake dependency, plain-crypto-js@4.2.1, a package that is never imported anywhere in the axios source, whose only pu…

> (I never understood why).

I spent two years trying to get it out of a project that began long after Axios had become redundant but it's very hard to go back and challenge decisions like this because every business priority is aligned against this kind of work.

I expect libraries built on top of fetch will be the next to be compromised, because why would you use fetch without an arbitrary layer of syntactic sugar...

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#646

Post by [deleted] »

hk__2 wrote: post #235
fluxist wrote: post #215

A command to recursively check for the compromised axios package version: find / -path '*/node_modules/axios/package.json' -type f 2>/dev/null | while read -l f; set -l v (grep -oP '"version"\s*:\s\*"\K(1\.14\.1|0\.30\.4)' $f 2>/dev/null); if test -n "$v"; printf '\a\n\033[1;31m FOUND v%s\033[0m \033[1;33m%s\033[0m\n' $v (string replace '/package.json' '' -- $f); else; printf '\r\033[2m scanning: %s\033[K\033[0m' (st…

Or more simply: find / -type f -path '*/node_modules/axios/package.json' \ -exec grep -Pl '"version"\s*:\s*"(1\.14\.1|0\.30\.4)"' {} + 2>/dev/null Let’s not encourage people to respond to security incidents by… copy/pasting random commands they don’t understand.

[deleted]

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#647

Post by habinero »

nananana9 wrote: post #288
jonkoops wrote: post #256

Earlier quoted context omitted.

> We have libraries like SQLite, which is a single .c file that you drag into your project You are just swapping a package manager with security by obscurity by copy pasting code into your project. It is arguably a much worse way of handling supply chain security, as now there is no way to audit your dependencies. > If you get rid of transitive dependencies, you get rid of the need of a package manager This argument…

> You are just swapping a package manager with security by obscurity by copy pasting code into your project You should try writing code, and not relying on libraries for everything, it may change how you look at programming and actually ground your opinions in reality. I'm staring at company's vendor/ folder. It has ~15 libraries, all but one of which operate on trusted input (game assets). > fundamental benefits of…

> trusted input (game assets)

Gamedev is its own weird thing, and isn't a model you want to generalize to other industries. It has to optimize for things a lot of software does not, and that skews development.

Vendoring libraries is almost always a terrible idea because it immediately starts to bitrot and become a footgun.

Sometimes it's necessary, but it's not desirable, and you almost always just want to pin your dependencies instead.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#648

Post by [deleted] »

rectang wrote: post #70
vsgherzi wrote: post #63

Not to beat a dead horse but I see this again and again with dependencies. Each time I get more worried that the same will happen with rust. I understand the fat std library approach won’t work but I really still want a good solution where I can trust packages to be safe and high quality.

Hosting curated dependencies is a commercially valuable service. Eventually an economy arises where people pay vendors to vet packages.

[deleted]

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#649

Post by Leherenn »

brabel wrote: post #635
user34283 wrote: post #511

Earlier quoted context omitted.

The compromised packages were removed from the registry within hours.

Because everyone got updates immediately. If the default was 7 days, almost no one would get updates immediately but after 7 days, and now someone only finds about after 7 days. Unless there is a poor soul checking packages as they are published that can alert the registry before 7 days pass, though I imagine very few do that and hence a dedicated attacker could influence them to not look too hard.

If I remember correctly, in all the recent cases it was picked up by automated scanning tools in a few hours, not because someone updated the dependency, checked the code and found the issue.

So it looks like even if no one actually updates, the vast majority of the cases will be caught by automated tools. You just need to give them a bit of time.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#650

Post by staticassertion »

erikerikson wrote: post #499
staticassertion wrote: post #483

Earlier quoted context omitted.

Yeah, NPM should be enforcing 2FA and likely phishing resistant 2FA for some packages/ this should be a real control, issuing public audit events for email address changes, and publish events should include information how it was published (trusted publishing, manual publish, etc).

Instead they took away TOTP as a factor. Scaling security with the popularity of a repo does seem like a good idea.

TOTP seems effectively useless for npm so that seems fine to me
Post reply on HN