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

31–40 of 165 posts

Re: Post Mortem: axios NPM supply chain compromise

#31

Post by yjftsjthsd-h »

dcrazy wrote: post #15
yjftsjthsd-h wrote: post #13

Earlier quoted context omitted.

What would a physical token give you that totp doesn't? Edit: wait, did the attacker intercept the totp code as it was entered? Trying to make sense of the thread

The attacker installed a RAT on the contributor’s machine, so if they had configured TOTP or saved the recovery codes anywhere on that machine, the attacker could defeat 2FA.

Oh, yes, I missed that the TOTP machine was compromised:\ Would that then imply that it would have been okay if codes came from a separate device, eg. a TOTP app on a Palm OS device with zero network connectivity? (Or maybe these days the easiest airgapped option is an old android phone that stays in airplane mode...)

Re: Post Mortem: axios NPM supply chain compromise

#32

Post by lrvick »

TheTaytay wrote: post #27
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…

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 i…

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.

Re: Post Mortem: axios NPM supply chain compromise

#33

Post by yawaramin »

lrvick wrote: post #26
ipnon wrote: post #6

Earlier quoted context omitted.

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.

If the solution is 'maintainers just need to do xyz', then it's not a solution, sorry. It's not scalable and which projects become 'successful' and which maintainers accidentally become critical parts of worldwide codebases, is almost pure chance. You will never be able to get all the maintainers you need to 'just' do xyz. Just like you will never be able to get humans to 'just' stop making mistakes. So you had better start looking for a solution that doesn't rely on humans not making mistakes.

Re: Post Mortem: axios NPM supply chain compromise

#34

Post by nurettin »

yjftsjthsd-h wrote: post #31
dcrazy wrote: post #15

Earlier quoted context omitted.

The attacker installed a RAT on the contributor’s machine, so if they had configured TOTP or saved the recovery codes anywhere on that machine, the attacker could defeat 2FA.

Oh, yes, I missed that the TOTP machine was compromised:\ Would that then imply that it would have been okay if codes came from a separate device, eg. a TOTP app on a Palm OS device with zero network connectivity? (Or maybe these days the easiest airgapped option is an old android phone that stays in airplane mode...)

Yes, unfortunately authenticator apps just generate TOTP codes based on a binary key sitting in plain sight without any encryption. Not that it would help if the encrypting/decrypting machine is pwned.

Re: Post Mortem: axios NPM supply chain compromise

#35

Post by dcrazy »

yjftsjthsd-h wrote: post #31
dcrazy wrote: post #15

Earlier quoted context omitted.

The attacker installed a RAT on the contributor’s machine, so if they had configured TOTP or saved the recovery codes anywhere on that machine, the attacker could defeat 2FA.

Oh, yes, I missed that the TOTP machine was compromised:\ Would that then imply that it would have been okay if codes came from a separate device, eg. a TOTP app on a Palm OS device with zero network connectivity? (Or maybe these days the easiest airgapped option is an old android phone that stays in airplane mode...)

The easiest approach is a provider-issued hardware dongle like a SecurID or Yubikey. Lack of end-user programmability is a feature, not a bug.

Re: Post Mortem: axios NPM supply chain compromise

#36

Post by jiggawatts »

yawaramin wrote: post #33
lrvick wrote: post #26

Earlier quoted context omitted.

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.

If the solution is 'maintainers just need to do xyz', then it's not a solution, sorry. It's not scalable and which projects become 'successful' and which maintainers accidentally become critical parts of worldwide codebases, is almost pure chance. You will never be able to get all the maintainers you need to 'just' do xyz. Just like you will never be able to get humans to 'just' stop making mistakes. So you had bette…

"Discipline doesn't scale" as become one of my favourite quotes for a reason.

Re: Post Mortem: axios NPM supply chain compromise

#37

Post by yjftsjthsd-h »

dcrazy wrote: post #35
yjftsjthsd-h wrote: post #31

Earlier quoted context omitted.

Oh, yes, I missed that the TOTP machine was compromised:\ Would that then imply that it would have been okay if codes came from a separate device, eg. a TOTP app on a Palm OS device with zero network connectivity? (Or maybe these days the easiest airgapped option is an old android phone that stays in airplane mode...)

The easiest approach is a provider-issued hardware dongle like a SecurID or Yubikey. Lack of end-user programmability is a feature, not a bug.

> Lack of end-user programmability is a feature, not a bug.

I would argue that the problem is network accessibility, not programmability.

Re: Post Mortem: axios NPM supply chain compromise

#38

Post by charcircuit »

lrvick wrote: post #32
TheTaytay wrote: post #27

Earlier quoted context omitted.

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 i…

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 fundament…

And for 5 there should be help on the NPM end to make it so that the alarms can fire before the new update is actually revealed to the public. There could be a short staging time where it could be revoked before any harm has been done. During this staging time NPM should also scan the package through a malware scanner before allowing it to go public.

Re: Post Mortem: axios NPM supply chain compromise

#39

Post by dcrazy »

yjftsjthsd-h wrote: post #37
dcrazy wrote: post #35

Earlier quoted context omitted.

The easiest approach is a provider-issued hardware dongle like a SecurID or Yubikey. Lack of end-user programmability is a feature, not a bug.

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

Post reply on HN