Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Axios compromised on NPM – Malicious versions drop remote access trojan

stepsecurity.io

Post reply on HN
Print view View original

601–610 of 894 posts

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#601

Post by pyjarrett »

troad wrote: post #411
pyjarrett wrote: post #359

Earlier quoted context omitted.

These are the big ones I use, specifically because of the standard libraries: Python (decent standard library) - It's pretty much everywhere. There's so many hidden gems in that standard library (difflib, argparse, shlex, subprocess, cmd) C#/F# (.NET) C# feels so productive because of how much is available in .NET Core, and F# gets to tag along and get it all for free too. With C# you can compile executables down to…

These are definitely some good thoughts, thanks! Do you worry at all about the future of F#? I've been told it's feeling more and more like a second-class citizen on .NET, but I don't have much personal experience.

I used to, but the knowledge of .NET seems mostly transferrable to C#. It's super useful to do `dotnet fsi` and then work out the appropriate .NET calls in the F# repl.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#602

Post by zbentley »

philipwhiuk wrote: post #547
twodave wrote: post #545

How is it we've made it this far and we still don't have any kind of independent auditing of basic publish security on NPM? You'd think this would be collectively a trivial and high priority task (to ensure that all publishes for packages over a certain download volume are going through a session that authenticated via MFA, for instance).

> You'd think this would be collectively a trivial and high priority task (to ensure that all publishes for packages over a certain download volume are going through a session that authenticated via MFA, for instance). Because all mainstream packages are published via CI/CD pipeline not by an MFA'd individual uploading a GZIP to npm.com

Requiring a human-in-the-loop for final, non-prerelease publication doesn't seem like that onerous of a burden. Even if you're publishing multiple releases a day on the regular (in which case ... I have questions, but anyway) there are all sorts of automations that stay secure while reducing the burden of having to manually download an artifact from CI, enter MFA, and upload it by hand.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#603

Post by zbentley »

ArcHound wrote: post #43
jmward01 wrote: post #33

This may not be popular, but is there a place for required human actions or just timed actions to slow down things like this? For instance, maybe a GH action to deploy requires a final human click and to change that to cli has a 3 day cooling period with mandatory security emails sent out. Similarly, you switch to read only for 6 hrs after an email change. There are holes in these ideas but the basic concept is to tr…

Hi, security here. We've tried, but the amount of people you need for this vs the amount of people you have trying to review and click the big button always means that this step will be a bottleneck. Thus this step will be eliminated. A much better approach would be to pin the versions used and do intentional updates some time after release, say a sprint after.

Pinning, escrowing, and trailing all help, but I'm not sure "this step will be eliminated" is inevitable.

Package manager ecosystems are highly centralized. npm.org could require MFA (or rate limit, or email verification, or whatever) and most packagers would gripe but go along with this. A minority would look for npm competitors that didn't have this requirement, and another minority would hack/automate MFA and remove the added security, but the majority of folks would benefit from a centralized requirement of this sort.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#605

Post by 6thbit »

roflcopter69 wrote: post #522
6thbit wrote: post #502

I don’t buy the “wait 7 days” being thrown around as a guard. Wouldn’t that just encourage the bad actors to delay the activation of their payloads a few days or even remotely activated on a switch?

Of course the "wait 7 days" are not a silver bullet, but it gives automated scanners plenty of time to do their work. Those automated scanners surely catch this `eval(base64.decode("..."))` stuff that some of those attacks used so in my book this dependency cooldown is a net win. I guess the skilled malicious actors will then up their game but I think it's okay to kick off an arms race between them and the security s…

That's a good point. In some level I'd prefer the delay to happen on publication of the package itself. Do any of these scanners have cryptographic attestations or similar?

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#606

Post by croemer »

Has anyone else noticed there was a recent sudden flurry of 3000 deleted issues on axios/axios? The jump happened on March 23. Was this a first sign of compromise? Or just coincidence of an AI agent going rogue.

There are pretty much exactly 3000 deleted issues, with the range starting at https://github.com/axios/axios/issues/7547 (7547) and ending at https://github.com/axios/axios/issues/10546 (10546 which is 7547+2999)

Maybe just a coincidence but they have cubic-dev-ai edit every single PR with a summary. And that bot edits PR descriptions even for outside contributors.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#607

Post by dboreham »

paustint wrote: post #455
woodruffw wrote: post #431

There’s a recurrent pattern with these package compromises: the attacker exfiltrates credentials during an initial phase, then pivots to the next round of packages using those credentials. That’s how we saw them make the Trivy to LiteLLM leap (with a 5 day gap), and it’ll almost certainly be similar in this case. The solution to this is twofold, and is already implemented in the primary ecosystems being targeted (Pyt…

In this case, the author's NPM account was taken over, email address changed to one the attacker controls, and the package was manually published. Since the attacker had full control of the NPM account, it is game over - the attacker can login to NPM and could, if they wanted, configure Trusted Publishing on any repo they control. Axios IS using trusted publishing, but that didn't do anything to prevent the attack si…

One wonders if Microsoft/npm.js should allow new packages to be published immediately following an account email address change? I mean changes to email address are already recognized as potential attack vectors, so emails are sent to the old address warning of potential account take over. But this seems to have been done at night, so the warning email would not be seen yet. Even so a new package could be published and served to the world immediately. Unless I misunderstand something about the facts this would indicate an extreme lack of imagination in the people at Microsoft who already went through several cycles of hardening the service against supply chain poisoning attacks.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#608

Post by zbentley »

ex-aws-dude wrote: post #564

Why is it with Javascript the culture is to use so many dependencies?

All sorts of reasons, but this isn't a left-pad situation. Axios's functionality is something provided by a library in a lot of languages (C/C++ with libcurl and friends, Python with requests, Rust with reqwest, and so on).

That's not to say it's inherently necessary for it to be a third-party package (Go, Ruby, and Java are counterexamples). But this isn't a proliferation/anemic stdlib issue.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#609

Post by paulpauper »

woodruffw wrote: post #431

There’s a recurrent pattern with these package compromises: the attacker exfiltrates credentials during an initial phase, then pivots to the next round of packages using those credentials. That’s how we saw them make the Trivy to LiteLLM leap (with a 5 day gap), and it’ll almost certainly be similar in this case. The solution to this is twofold, and is already implemented in the primary ecosystems being targeted (Pyt…

Was this an drive-by/auto-install attack?

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#610

Post by [deleted] »

postalcoder wrote: post #26

PSA: npm/bun/pnpm/uv now all support setting a minimum release age for packages. I also have `ignore-scripts=true` in my ~/.npmrc. Based on the analysis, that alone would have mitigated the vulnerability. bun and pnpm do not execute lifecycle scripts by default. Here's how to set global configs to set min release age to 7 days: ~/.config/uv/uv.toml exclude-newer = "7 days" ~/.npmrc min-release-age=7 # days ignore-scr…

[deleted]
Post reply on HN