Live data from Hacker News

Axios compromised on NPM – Malicious versions drop remote access trojan

stepsecurity.io

471–480 of 894 posts

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

#471

Setting min-release age to 7 days is great, but the only true way to protect from supply chain attacks is restricting network access. This needs to be done (as we've seen from these recent attacks) in your devenv, ci/cd and prod environments. Not one, or two, but all of these environments. The easiest way is via using something like kubernetes network policies + a squid proxy to allow limited trusted domains through,…

> Setting min-release age to 7 days is great, but the only true way to protect from supply chain attacks is restricting network access.

Getting zero day patches 7 days later if no proper monitoring about important patches or if this specific patch is not in the important list. Always a tradeoff.

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

#472
post #442

Earlier quoted context omitted.

People use axios or ky because with fetch you inevitably end up writing a small wrapper on top of it anyway.

Some might say the tradeoff of writing a small wrapper is worth it given what’s been demonstrated here.

Yeah but what about other deps like db drivers?

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

#473

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

Irony is that Node has no need for Axios, native fetch support has been there for years, so in terms of network requests it is batteries included.

It doesn't have a need _now_. Axios is more than 10 years old now, and even before axios other libraries did the same utility of making requests easier

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

#474

I lost respect for Axios when they made a breaking change in a patch release. Digging into the root cause, I found the maintainer had approved an outside PR with an obvious AI slop PR description: https://github.com/axios/axios/issues/7059 Looks like the maintainer wasn't just careless when reviewing PRs.

True, but think of how many new successfully closed PRs will be created as a result of this ~~incident~~ opportunity. Exponential KPI growth!

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

#476

Earlier quoted context omitted.

Irony is that Node has no need for Axios, native fetch support has been there for years, so in terms of network requests it is batteries included.

I'm not sure fetch is a good server-side API. The typical fetch-based code snippet `fetch(API_URL).then(r => r.json())` has no response body size limit and can potentially bring down a server due to memory exhaustion if the endpoint at API_URL malfunctions for some reason. Fine in the browser but to me it should be a no-no on the server.

Hm, I don't think axios would do much better here. `fetch` is the official replacement for axios. If both are flawed that's another topic

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

#477
post #140

Earlier quoted context omitted.

OP should be glad a new time unit wasn't invented

Workdays! Think about it, if you set the delay in regular days/seconds the updated dependency can get pulled in on a weekend with only someone maybe on-call. (Hope your timezones and tzdata correctly identifies Easter bank holiday as non-workdays)

When I worked in Finance our internal Date extension did actually have Workdays that took into account Stock Market and Bank Holidays.

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

#478

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…

Well, that sucks! It’ll be interesting to learn how they obtained a valid second factor or 2FA bypass; that will inform the next round of defenses here.

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

#479
This is exactly to avoid this kind of issue that I decided to work on StableBuild. StableBuild pins and hosts a copy of your dependencies at a specific freeze date, so that your supply chain is never contaminated. This way, a compromised version published after your freeze date (even with the same version number!) would never reach your build.
Post reply on HN