[dead]
Post Mortem: axios NPM supply chain compromise
41–50 of 165 posts
Re: Post Mortem: axios NPM supply chain compromise
#42Incredible 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.
That's the reality of modern war. Many countries are likely planting malware on a wide scale. You can't even really prove where an attack originated from, so uninvolved countries would also be smart to take advantage of the current conflict. Like if you primarily wrote German, you would translate your malware to Chinese, Farsi, English, or Hebrew, and take other steps to make it appear to come from one of those warri…
You can write code in Chinese and Farsi?
Re: Post Mortem: axios NPM supply chain compromise
#43Earlier quoted context omitted.
That's the reality of modern war. Many countries are likely planting malware on a wide scale. You can't even really prove where an attack originated from, so uninvolved countries would also be smart to take advantage of the current conflict. Like if you primarily wrote German, you would translate your malware to Chinese, Farsi, English, or Hebrew, and take other steps to make it appear to come from one of those warri…
You can write code in Chinese and Farsi?
You can deliberately put comments and descriptions using those language.
Re: Post Mortem: axios NPM supply chain compromise
#44[dead]
Re: Post Mortem: axios NPM supply chain compromise
#45Earlier quoted context omitted.
> Lack of end-user programmability is a feature, not a bug. I would argue that the problem is network accessibility, not programmability.
When designing a system for secure attestation, end-user programmability is not a feature. It would not be an advantage for your front door lock to be infinitely reprogrammable. It’s just a liability.
I mean, I guess attestation might have some value, but it feels like moving the goalposts. Under the threat model of a remote attacker who can compromise a normal networked computer, I can't think of an attack that would succeed with a programmable TOTP code generator that would fail if that code generator was not reprogrammable. Can you?
> It would not be an advantage for your front door lock to be infinitely reprogrammable. It’s just a liability.
Er, most door locks are infinitely reprogrammable, because being able to rekey them without having to replace the whole unit is a huge advantage and the liability/disadvantage is minimal (falling under "It rather involved being on the other side of this airtight hatchway" in an unusually almost-literal sense where you have to be inside the house in order to rekey the lock, at which point you could also do anything else).
Re: Post Mortem: axios NPM supply chain compromise
#46[dead]
Re: Post Mortem: axios NPM supply chain compromise
#47Earlier quoted context omitted.
When designing a system for secure attestation, end-user programmability is not a feature. It would not be an advantage for your front door lock to be infinitely reprogrammable. It’s just a liability.
I mean, I guess attestation might have some value, but it feels like moving the goalposts. Under the threat model of a remote attacker who can compromise a normal networked computer, I can't think of an attack that would succeed with a programmable TOTP code generator that would fail if that code generator was not reprogrammable. Can you? > It would not be an advantage for your front door lock to be infinitely reprog…
Sorry, attestation is the goalpost. The community wants certainty that the package was published by a human with authority, and not just by someone who had access to an authority’s private keys. That is what distinguishes attestation from authentication or authorization.
Re: Post Mortem: axios NPM supply chain compromise
#48Earlier 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?
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…
If you're paid then sure. Otherwise... It depends.
Re: Post Mortem: axios NPM supply chain compromise
#49Seems 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 can be pushed to NPM. Each high profile repo would have certain laptops that can upload for that repo. Set up the laptop with a minimal version of Linux with just the command line tools to upload to NPM, not even a browser or desktop environment. Give those laptops to maintainers of high profile repos for free to use for updates.
Then at update time, the maintainer just transfers the code from their dev machine to the secure laptop via USB drive or CD and pushes to NPM from the special laptop.
Re: Post Mortem: axios NPM supply chain compromise
#50Earlier quoted context omitted.
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…
What you sign or don't sign in your Git repo doesn't matter because NPM doesn't publish from a Git repo. Signing commits is still useful for your contributors and downstream forks but it won't have any effect on the users who use your package via NPM.
I think NPM is fully to blame here. Packages that exceed a certain level of popularity should require signing/strong 2FA. They should implement more schemes that publishers can optionally enable, like requiring mandatory sign-off from more than 1 maintainer before the package is available to download.
Then on the package page it should say: "[Warning] Weak publishing protection" or "[Checkmark] This package requires sign-off from accountA and accountB to publish".