Remix.run Logo
Zopieux 3 hours ago

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

hatmanstack 3 hours ago | parent | next [-]

jasonsaayman and voxpelli had useful write ups from the "head on a swivel" perspective of what to watch out for. Jason mentioned "the meeting said something on my system was out of date." they were using Microsoft meeting and that's how they got RCE. Would love more color on that.

lrvick an hour ago | parent | prev [-]

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.

fortuitous-frog an hour ago | parent | next [-]

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.

lrvick 23 minutes ago | parent [-]

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.

TheTaytay an hour ago | parent | prev [-]

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.

lrvick 9 minutes ago | parent [-]

To prevent supply chain attacks you need multi party cryptographic attestation at every layer, which is pretty straight forward, but you are correct, NPM and GitHub controls absolutely will not save you. Microsoft insists their centralized approach can work, but we have plenty of evidence it does not.

Operate under the assumption all accounts will be taken over because centralized corporate auth systems are fundamentally vulnerable.

This is how you actually fix it:

1. Every commit must be signed by a maintainer key listed in the MAINTAINERS file or similar

2. Every review/merge must be signed by a -second- maintainer key

3. Every artifact must be build deterministically and be signed by multiple maintainers.

4. Have only one online npm publish key maintained in a deterministic and remotely attestable enclave that validates multiple valid maintainer signatures

5. Automatically sound the alarm if an NPM release is pushed any other way, and automatically revoke it.