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

11–20 of 165 posts

Re: Post Mortem: axios NPM supply chain compromise

#11

Post by dcrazy »

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.

It’s far from a complete solution, but to mitigate this specific avenue of supply chain compromise, couldn’t Github/npm issue single-purpose physical hardware tokens and allow projects (or even mandate, for the most popular ones) maintainers use these hardware tokens as a form of 2FA?

Re: Post Mortem: axios NPM supply chain compromise

#12

Post by fortuitous-frog »

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.

Re: Post Mortem: axios NPM supply chain compromise

#13

Post by yjftsjthsd-h »

dcrazy wrote: post #11
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.

It’s far from a complete solution, but to mitigate this specific avenue of supply chain compromise, couldn’t Github/npm issue single-purpose physical hardware tokens and allow projects (or even mandate, for the most popular ones) maintainers use these hardware tokens as a form of 2FA?

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

Re: Post Mortem: axios NPM supply chain compromise

#14

Post by robshippr »

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.

Re: Post Mortem: axios NPM supply chain compromise

#15

Post by dcrazy »

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

Earlier quoted context omitted.

It’s far from a complete solution, but to mitigate this specific avenue of supply chain compromise, couldn’t Github/npm issue single-purpose physical hardware tokens and allow projects (or even mandate, for the most popular ones) maintainers use these hardware tokens as a form of 2FA?

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.

Re: Post Mortem: axios NPM supply chain compromise

#16

Post by sheept »

akersten wrote: post #7

Any good payload analysis been published yet? Really curious if this was just a one and done info stealer or if it potentially could have clawed its way deeper into affected systems.

This article[0] investigated the payload. It's a RAT, so it's capable of executing whatever shell commands it receives, instead of just stealing credentials.

[0]: https://safedep.io/axios-npm-supply-chain-compromise/

Re: Post Mortem: axios NPM supply chain compromise

#17

Post by clawfund »

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.

[flagged]

Re: Post Mortem: axios NPM supply chain compromise

#18

Post by lrvick »

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.

Normalized negligence is still negligence.

Re: Post Mortem: axios NPM supply chain compromise

#19

Post by 4ndrewl »

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?
Post reply on HN