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

431–440 of 894 posts

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

#431

Post by woodruffw »

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 (Python and JS): packagers should use Trusted Publishing to eliminate the need for long lived release credentials, and downstreams should use cooldowns to give security researchers time to identify and quarantine attacks.

(Security is a moving target, and neither of these techniques is going to work indefinitely without new techniques added to the mix. But they would be effective against the current problems we’re seeing.)

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

#432

Post by _lvbh »

pamcake wrote: post #324
_lvbh wrote: post #60

There are so many scanners these days these things get caught pretty quick. I think we need either npm or someone else to have a registry that only lets through packages that pass these scanners. Can even do the virustotal thing of aggregating reports by multiple scanners. NPM publishes attestation for trusted build environments. Google has oss-rebuild. All it takes is an `npm config set` to switch registries anyways…

Sounds great until trivy images get compromised, like last week.

Hence why you source data from multiple vendors I'd say. Rather than putting all eggs in one basket

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

#433

Post by sbarre »

woodruffw wrote: post #421
umko21 wrote: post #169

Earlier quoted context omitted.

My bad. This works for per project configuration, but not for global user configuration.

It should work for global configuration too, please file an issue if you’re observing otherwise. (Make sure you’re on a version that actually supports relative times, please!)

This is what tripped me up. I added that config and then got this error:

error: Failed to parse: `.config/uv/uv.toml` Caused by: TOML parse error at line 1, column 17 | 1 | exclude-newer = "7 days" | ^^^^^^^^ failed to parse year in date "7 days": failed to parse "7 da" as year (a four digit integer): invalid digit, expected 0-9 but got

I was on version 0.7.20, so I removed that line, ran "uv self update" and upgraded to 0.11.2 and then re-added the config and it works fine now.

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

#434

Post by sbarre »

antihero wrote: post #302
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…

npm is claiming this doesn’t exist

Make sure you're on version 11.10 or later?

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

#435

Post by lukewarm707 »

lepuski wrote: post #183

I believe compartmentalized operating systems like Qubes are the future for defending against these kinds of attacks. Storing your sensitive data on a single bare-metal OS that constantly downloads and runs packages from unknown maintainers is like handing your house key out to a million people and hoping none of them misuse it.

i am rolling back a huge number of 'features' in my personal pc and going back to extremely miminal setups

the security solution i have is where it needs to become more simple, getting rid of attack surface that is coming out of these bloated releases

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

#436

Post by _lvbh »

drum55 wrote: post #86
_lvbh wrote: post #60

There are so many scanners these days these things get caught pretty quick. I think we need either npm or someone else to have a registry that only lets through packages that pass these scanners. Can even do the virustotal thing of aggregating reports by multiple scanners. NPM publishes attestation for trusted build environments. Google has oss-rebuild. All it takes is an `npm config set` to switch registries anyways…

The ones you hear about are caught quickly, I’m more worried about the non obvious ones. So far none of these have been as simple as changing a true to a false and bypassing all auth for all products or something, and would that be caught by an automated scanner?

There are definitely levels to this. Yes I think it can be caught by automated scanners in theory. Either commit by commit scanning and reproducible builds or fuzzing and getting the behavioral differences between versions

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

#437

Post by TZubiri »

bob1029 wrote: post #241

"Batteries included" ecosystems are the only persistent solution to the package manager problem. If your first party tooling contains all the functionality you typically need, it's possible you can be productive with zero 3rd party dependencies. In practice you will tend to have a few, but you won't be vendoring out critical things like HTTP, TCP, JSON, string sanitation, cryptography. These are beacons for attackers…

But javascript is batteries included in this case, you can use xmlhttprequest or fetch

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

#438

Post by wongarsu »

paintbox wrote: post #416
wongarsu wrote: post #327

Earlier quoted context omitted.

> In practice you will tend to have a few, but you won't be vendoring out critical things like HTTP, TCP, JSON, string sanitation, cryptography Unless you are Python, where the standard library includes multiple HTTP libraries and everyone installs the requests package anyways. Few languages have good models for evolving their standard library, so you end up with lots of bad designs sticking around forever. Libraries…

What type of developer chooses UX and performance over security? So reckless. I removed the locks from all the doors, now entering/exiting is 87% faster! After removing all the safety equipment, our vehicles have significantly improved in mileage, acceleration and top speed!

Better developer UX can directly lead to better safety. "You are holding it wrong" is a frequent source of security bugs, and better UX reduces the ways you can hold it wrong, or at least makes you more likely to hold it the right way

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

#439

Post by pier25 »

bob1029 wrote: post #241

"Batteries included" ecosystems are the only persistent solution to the package manager problem. If your first party tooling contains all the functionality you typically need, it's possible you can be productive with zero 3rd party dependencies. In practice you will tend to have a few, but you won't be vendoring out critical things like HTTP, TCP, JSON, string sanitation, cryptography. These are beacons for attackers…

I agree. Got downvoted a lot the other day for proposing Node should solve fundamental needs.

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

#440

Post by TZubiri »

h4ch1 wrote: post #13

I can't even imagine the scale of the impact with Axios being compromised, nearly every other project uses it for some reason instead of fetch (I never understood why). Also from the report: > Neither malicious version contains a single line of malicious code inside axios itself. Instead, both inject a fake dependency, plain-crypto-js@4.2.1, a package that is never imported anywhere in the axios source, whose only pu…

>(I never understood why).

Because axios existed before the builtin fetch, and so there's a lot of stackoverflow answers explaining how to use fetch, and the llm models are trained on that, so they will write axios requests instead of fetch

Post reply on HN