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

121–130 of 165 posts

Re: Post Mortem: axios NPM supply chain compromise

#121

Post by mcintyre1994 »

cromka wrote: post #118
Chyzwar wrote: post #117

NPM should fix this mess. Adding postinstall should require approval from NPM. NPM clients should not install freshly published packages. NPM packages should be scanned after publishing. High profile packages should verify upstream git hash signature. NPM install should run in sandbox and detect any attempt to install outside project directory. But npm being part of multi trillion company cannot be bothered to fix an…

> NPM clients should not install freshly published packages. That would be a beautiful example of Cobra effect: what about updates that fix vulnerabilities? You're gonna force users to wait couple days or a week before they can get malware removed?

In cases like this that isn’t an issue, NPM takes the malicious package down and you roll back to the previous version.

The problem would be new versions that fix security issues though, and because this is all open source as soon as you publish the fix everyone knows the vulnerability. You wouldn’t want everyone to stay on the insecure version with a basically public vulnerability for a week.

Re: Post Mortem: axios NPM supply chain compromise

#122

Post by mcintyre1994 »

Chyzwar wrote: post #119
cromka wrote: post #118

Earlier quoted context omitted.

> NPM clients should not install freshly published packages. That would be a beautiful example of Cobra effect: what about updates that fix vulnerabilities? You're gonna force users to wait couple days or a week before they can get malware removed?

This could be controlled by npm. Client ask for available versions anyway. If package is security fix then it can be made available instantly. But this delay gives time for security scanners and time to notify maintainers that package was published.

Then the malicious packages would always be published as a security fix.

Re: Post Mortem: axios NPM supply chain compromise

#123

Post by mcintyre1994 »

dgellow wrote: post #69
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 process to setup OIDC is way too frustrating. There is just so much friction. You need the package to first exists in the registry, meaning you have to first create an API token and push something. And only then can you enable OIDC for that specific package. After adding the repo + workflow names, you have to save. Then finally toggle the “only allow OIDC publishing”. Before each action you need to enter your 2fa…

You’re right, but a colleague recently showed me this CLI for it: https://docs.npmjs.com/cli/v11/commands/npm-trust

Still needs to be published first, but looks like it automates all the annoying UI things you mentioned.

Re: Post Mortem: axios NPM supply chain compromise

#124

Post by NewEntryHN »

hatmanstack wrote: post #10
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...

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.

He says it mimicks what is described here: https://cloud.google.com/blog/topics/threat-intelligence/unc...

Which is basically phishing:

> The meeting link itself directed to a spoofed Zoom meeting that was hosted on the threat actor's infrastructure, zoom[.]uswe05[.]us.

> Once in the "meeting," the fake video call facilitated a ruse that gave the impression to the end user that they were experiencing audio issues.

> The recovered web page provided two sets of commands to be run for "troubleshooting": one for macOS systems, and one for Windows systems. Embedded within the string of commands was a single command that initiated the infection chain.

Re: Post Mortem: axios NPM supply chain compromise

#125

Post by dkdbejwi383 »

timcobb wrote: post #98
falkensmaize wrote: post #95

The fetch api has been widely available in browsers for a decade now. And in node since 18. A competent developer could whip up a more axios-like library with fetch in a day easily. You can do all the cool things like interceptors with fetch too. Yet most developers I work with just use it reflexively. This seems like one of the biggest issues with the npm ecosystem - the complete lack of motivation to write even tri…

Fetch can't do a lot of table stakes stuff...

Such as?

Re: Post Mortem: axios NPM supply chain compromise

#126

Post by darepublic »

neya wrote: post #108
falkensmaize wrote: post #95

The fetch api has been widely available in browsers for a decade now. And in node since 18. A competent developer could whip up a more axios-like library with fetch in a day easily. You can do all the cool things like interceptors with fetch too. Yet most developers I work with just use it reflexively. This seems like one of the biggest issues with the npm ecosystem - the complete lack of motivation to write even tri…

> A competent developer could whip up a more axios-like library with fetch in a day easily. Then you would have created just an axios clone. AKA re-inventing the wheel. The issue isn't the library itself, but rather the fact that it's popular and provided a large enough attack surface. You can actually just clone the axios package and use it as is from your private repo and you would not have been affected.

You would have created a smaller axios that only does what you needed it to. Even better

Re: Post Mortem: axios NPM supply chain compromise

#127

Post by rk06 »

Hamuko wrote: post #114
hatmanstack wrote: post #10

Earlier quoted context omitted.

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.

Makes me glad that I've only ever used my iPad whenever I've had to interview through Microsoft Teams.

this is literally the lesson i take from this. always do meetings on tablets

Re: Post Mortem: axios NPM supply chain compromise

#128

Post by zarzavat »

lrvick wrote: post #86
pas wrote: post #59

Earlier quoted context omitted.

2FA was mandated by npm they had 2FA, but likely software TOTP (so it was either autofilled via 1password (or similar), or they were able to steal the seed) at this point I think publishing an npm app and asking people to scan a QR with it is the easiest way (so people don't end up with 1 actual factor)

What they need to mandate is hardware anchored passkeys/fido2/webauthn for both auth and package signing, with the -option- to sign with PGP for those that have well trusted PGP keys. They won't do this, I have talked to them plenty of times about it. But, if they did, the supply chain attacks would almost entirely stop.

Don't need to require hardware 2fa tokens. Just a mobile app would be sufficient. Publish to a staging area then require confirmation on mobile to make it go live. Maybe include a diff of changes files for good measure.

Re: Post Mortem: axios NPM supply chain compromise

#130

Post by littlestymaar »

neya wrote: post #108
falkensmaize wrote: post #95

The fetch api has been widely available in browsers for a decade now. And in node since 18. A competent developer could whip up a more axios-like library with fetch in a day easily. You can do all the cool things like interceptors with fetch too. Yet most developers I work with just use it reflexively. This seems like one of the biggest issues with the npm ecosystem - the complete lack of motivation to write even tri…

> A competent developer could whip up a more axios-like library with fetch in a day easily. Then you would have created just an axios clone. AKA re-inventing the wheel. The issue isn't the library itself, but rather the fact that it's popular and provided a large enough attack surface. You can actually just clone the axios package and use it as is from your private repo and you would not have been affected.

> AKA re-inventing the wheel.

The wheel is the native fetch API, nobody needs to reinvent it.

All you'd do in that scenario is make your own hubcap to put on top.

Post reply on HN