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

21–30 of 165 posts

Re: Post Mortem: axios NPM supply chain compromise

#21

Post by lorenzohess »

4ndrewl wrote: post #19
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…

Is the onus really on people who write code here? It really should be on those who choose to use this unsigned code, surely?

Perhaps, but if it's gotten to the point where millions of people download the unsigned code, signing should probably become required. Even reproducible builds.

Re: Post Mortem: axios NPM supply chain compromise

#22

Post by lrvick »

Zopieux wrote: post #8

Not much we didn't know (you're basically SOL since an owner was compromised), however we now have a small peek into the actual meat of the social engineering, which is the only interesting news imho: https://github.com/axios/axios/issues/10636#issuecomment-418...

An owner being compromised is absolutely survivable on a responsibly run FOSS project with proper commit/review/push signing.

This and every other recent supply chain attack was completely preventable.

So much so I am very comfortable victim blaming at this point.

This is absolutely on the Axios team.

Go setup some smartcards for signing git push/commit and publish those keys widely, and mandate signed merge commits so nothing lands on main without two maintainer sigs, and no more single points of failure.

Re: Post Mortem: axios NPM supply chain compromise

#23

Post by 4ndrewl »

lorenzohess wrote: post #21
4ndrewl wrote: post #19

Earlier quoted context omitted.

Is the onus really on people who write code here? It really should be on those who choose to use this unsigned code, surely?

Perhaps, but if it's gotten to the point where millions of people download the unsigned code, signing should probably become required. Even reproducible builds.

Required by who though? If your business etc depends upon some code, it's up to you to ensure its quality, surely? You copy some code onto your machine then it's your codebase, right?

Re: Post Mortem: axios NPM supply chain compromise

#24

Post by lrvick »

4ndrewl wrote: post #19
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…

Is the onus really on people who write code here? It really should be on those who choose to use this unsigned code, surely?

Anyone that maintains code for others to consume has a basic obligation to do the bare minimum to make sure their reputations are not hijacked by bad actors.

Just sign commits and reviews. It is so easy to stop these attacks that not doing so is like a doctor that refuses to wash their hands between patients.

If you are not going to wash your hands do not be a doctor.

If you are not going to sign your code do not be a FOSS maintainer.

Re: Post Mortem: axios NPM supply chain compromise

#25

Post by lrvick »

4ndrewl wrote: post #23
lorenzohess wrote: post #21

Earlier quoted context omitted.

Perhaps, but if it's gotten to the point where millions of people download the unsigned code, signing should probably become required. Even reproducible builds.

Required by who though? If your business etc depends upon some code, it's up to you to ensure its quality, surely? You copy some code onto your machine then it's your codebase, right?

While I think anyone unwilling to sign their code is negligent, I also feel anyone unwilling to ensure credible review of code has been done before pushing it to production is equally negligent.

Re: Post Mortem: axios NPM supply chain compromise

#26

Post by lrvick »

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.

All maintainers need to do is code signing. This is a solved problem but the NPM team has been actively rejecting optional signing support for over a decade now. Even so maintainers could sign their commits anyway, but most are too lazy to spend a few minutes to prevent themselves from being impersonated.

Re: Post Mortem: axios NPM supply chain compromise

#27

Post by TheTaytay »

lrvick wrote: post #22
Zopieux wrote: post #8

Not much we didn't know (you're basically SOL since an owner was compromised), however we now have a small peek into the actual meat of the social engineering, which is the only interesting news imho: https://github.com/axios/axios/issues/10636#issuecomment-418...

An owner being compromised is absolutely survivable on a responsibly run FOSS project with proper commit/review/push signing. This and every other recent supply chain attack was completely preventable. So much so I am very comfortable victim blaming at this point. This is absolutely on the Axios team. Go setup some smartcards for signing git push/commit and publish those keys widely, and mandate signed merge commits…

It wasn’t done through git. It was a direct npm publish from the compromised machine. If you read further down in the comments (https://github.com/axios/axios/issues/10636#issuecomment-418...), it seems difficult to pick the right npm settings to prevent this attack.

If I understand it correctly, your suggestions wouldn’t have prevented it, which is evidence that this is not as trivially fixable as you believe it is.

Re: Post Mortem: axios NPM supply chain compromise

#28

Post by fortuitous-frog »

lrvick wrote: post #22
Zopieux wrote: post #8

Not much we didn't know (you're basically SOL since an owner was compromised), however we now have a small peek into the actual meat of the social engineering, which is the only interesting news imho: https://github.com/axios/axios/issues/10636#issuecomment-418...

An owner being compromised is absolutely survivable on a responsibly run FOSS project with proper commit/review/push signing. This and every other recent supply chain attack was completely preventable. So much so I am very comfortable victim blaming at this point. This is absolutely on the Axios team. Go setup some smartcards for signing git push/commit and publish those keys widely, and mandate signed merge commits…

Did you investigate the maintainer compromise and publication path? The malicious version was never committed or pushed via git. The maintainer signs his commits, and v1 releases were using OIDC and provenance attestations. The malicious package versions were published locally using the npm cli after the maintainer's machine was compromised via a RAT; there's no way for package maintainers to disable/forbid local publication on npmjs.

It seems the Axios team was largely practicing what you're preaching. To the extent they aren't: it still wouldn't have prevented this compromise.

Re: Post Mortem: axios NPM supply chain compromise

#29

Post by GCUMstlyHarmls »

robshippr wrote: post #14

The interesting detail from this thread is that every legitimate v1 release had OIDC provenance attestations and the malicious one didn't, but nobody checks. Even simpler, if you're diffing your lockfile between deploys, a brand new dependency appearing in a patch release is a pretty obvious red flag.

To be honest, I would have assumed the tooling would do attestation verification for me. The diffing the lockfile would be on me though.

Re: Post Mortem: axios NPM supply chain compromise

#30

Post by lrvick »

fortuitous-frog wrote: post #28
lrvick wrote: post #22

Earlier quoted context omitted.

An owner being compromised is absolutely survivable on a responsibly run FOSS project with proper commit/review/push signing. This and every other recent supply chain attack was completely preventable. So much so I am very comfortable victim blaming at this point. This is absolutely on the Axios team. Go setup some smartcards for signing git push/commit and publish those keys widely, and mandate signed merge commits…

Did you investigate the maintainer compromise and publication path? The malicious version was never committed or pushed via git. The maintainer signs his commits, and v1 releases were using OIDC and provenance attestations. The malicious package versions were published locally using the npm cli after the maintainer's machine was compromised via a RAT; there's no way for package maintainers to disable/forbid local pub…

I can not find a single signed recent commit on the axios repo. It is totally yolo mode. Those "signed by github" signatures are meaningless. I stand by my comment in full.

One must sign commits -universally- and -also- sign reviews/merges (multi-party) and then -also- do multi party signing on releases. Doing only one step of basic supply chain security unfortunately buys you about as much defense as locking only a single door.

I do however certainly assign significant blame to the NPM team though for repeatedly refusing optional package signing support so packages with signing enabled can be refused at the server and client if unsigned by a quorum of pinned keys, but even aside from that if packages were signed manually then canary tools could have detected this immediately.

Post reply on HN