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

Post Mortem: axios NPM supply chain compromise

github.com

Post reply on HN
Print view View original

61–70 of 165 posts

Re: Post Mortem: axios NPM supply chain compromise

#61

Post by pas »

ipnon wrote: post #6
fraywing wrote: post #3

Incredible uptick in supply chain attacks over the last few weeks. I feel like npm specifically needs to up their game on SA of malicious code embedded in public projects.

NPM is designed to let you run untrusted code on your machine. It will never work. There is no game to step up. It's like asking an ostrich to start flying.

code becomes trusted by review, but these crowd sourcing efforts to do so fizzled out, so in practice we have weak proxies like number of downloads

the implicit trust we have in maintainers is easily faked as we see

Re: Post Mortem: axios NPM supply chain compromise

#62

Post by pas »

pianopatrick wrote: post #49

Seems to me the root of the problem was that the guy was using the same device for all sorts of stuff. Seems to me that one drastic tactic NPM could employ to prevent attacks like this is to use hardware security. NPM could procure and configure laptops with identity rooted in the laptop TPM instead of 2FA. Configure the NPM servers so that for certain repos only updates signed with the private key in the laptop TPM…

they can simply make an app that requires tapping a button, so people don't end up with TOTP seeds stored in their password manager on the same notebook where they run 'publish' from

Re: Post Mortem: axios NPM supply chain compromise

#65

Post by eviks »

> something on my system was out of date. i installed the missing item

Given the "extreme vigilance" of the primitive "don't install unknown something on your machine" level is unattainable, can there really be an effective project-level solutions?

Mandatory involvement of more people to hope not everyone installs random stuff, at least not at same time? (though you might not even have more people...)

Re: Post Mortem: axios NPM supply chain compromise

#66

Post by ffsm8 »

anematode wrote: post #20

Looks like a very sophisticated operation, and I feel for the maintainer who had his machine compromised. The next incarnation of this, I worry, is that the malware hibernates somehow (e.g., if (Date.now() ) to maximize the damage.

Isn't that already how it is?

I mean the compromised machine registers itself on the command server and occasionally checks for workloads.

The hacker then decides his next actions - depending on the machine they compromised they'll either try to spread (like this time) and make a broad attack or they may go more in-depth and try to exfiltrate data/spread internally if eg a build node has been compromised

Re: Post Mortem: axios NPM supply chain compromise

#67

Post by eviks »

lrvick wrote: post #18

I ask this on every supply chain security fail: Can we please mandate signing packages? Or at least commits? NPM rejected PRs to support optional signing multiple times more than a decade ago now, and this choice has not aged well. Anyone that cannot take 5 minutes to set up commit signing with a $40 usb smartcard to prevent impersonation has absolutely no business writing widely depended upon FOSS software. Normaliz…

"Anyone that cannot spend $40+ to give every FOSS maintainer a smartcard and maybe even separate machines for releases and make the more secure workflow truly 5 minutes has absolutely no business widely depending upon FOSS"

Re: Post Mortem: axios NPM supply chain compromise

#68

Post by pepve »

mcintyre1994 wrote: post #52
charcircuit wrote: post #5

Does OIDC flow block this same issue of being able to use a RAT to publish a malicious package?

Nope, the most restrictive option available is to disallow tokens and require 2FA. I think that using exclusively hardware 2FA and not having the backup codes on the compromised machine probably would have prevented this attack though.

Someone in the linked Github thread describes an attack where the attackers waited for the victim to use their Yubikey for an AWS login, giving the attackers access to AWS as well. I don't think hardware 2FA is safe against a RAT.

Re: Post Mortem: axios NPM supply chain compromise

#69

Post by dgellow »

fraywing wrote: post #3

Incredible uptick in supply chain attacks over the last few weeks. I feel like npm specifically needs to up their game on SA of malicious code embedded in public projects.

npm process to setup OIDC is way too frustrating. There is just so much friction. You need the package to first exists in the registry, meaning you have to first create an API token and push something. And only then can you enable OIDC for that specific package. After adding the repo + workflow names, you have to save. Then finally toggle the “only allow OIDC publishing”.

Before each action you need to enter your 2fa code.

I got so frustrated with npm end of last year that I wrote a whole guide covering that issue: https://npmdigest.com/guides/npm-trusted-publishing

Re: Post Mortem: axios NPM supply chain compromise

#70

Post by dgellow »

fortuitous-frog wrote: post #12
charcircuit wrote: post #5

Does OIDC flow block this same issue of being able to use a RAT to publish a malicious package?

No. axios (v1 at least; not v0) were setup to publish via OIDC, but there's no option on npmjs for package maintainers to restrict their package to *only* using OIDC. The maintainer says his machine was infected via RAT, so if he was using software-based 2FA, nothing could have prevented this.

Actually there is an option to restrict to only OIDC publishing. It is a bit hidden and relies on a different form for reasons I really cannot understand. Npm UX is just so bad.

Point 4 from https://npmdigest.com/guides/npm-trusted-publishing#ux-probl...

(I wrote that guide page for myself because I always get annoyed when dealing with npm OIDC)

Post reply on HN