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

451–460 of 894 posts

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

#451

Post by pavel_lishin »

sverhagen wrote: post #375
wongarsu wrote: post #319

Earlier quoted context omitted.

Seconds are also unambiguous. Depending on your chosen definition, "X days" may or may not be influenced by leap seconds and DST changes. I doubt anyone cares about an hour more or less in this context. But if you want multiple implementations to agree talking about seconds on a monotonic timer is a lot simpler

I came here to argue the opposite. Expressing it in seconds takes away questions about time zones and DST. I think you're incorrect to say that second are also ambiguous. Maybe what you mean is that days are more practical, but that seems very much a personal preference.

I think you misread the comment you're replying to.

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

#452

Post by zwily »

PunchyHamster wrote: post #394
otterley wrote: post #65

Earlier quoted context omitted.

What do you base that on? Threat researchers (and their automated agents) will still keep analyzing new releases as soon as they’re published.

The fact threat researchers and especially their automated agents are not all that good at their jobs

Those threat researchers and their autonomous agents caught this axios release.

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

#453

Post by integralid »

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!

>What type of developer chooses UX and performance over security? So reckless.

Initially I assumed this is sarcastic, but apparently not. UX and performance is what programmers are paid to do! Making sure UX is good is one of the most important things in programmer job.

While security is a moving target, a goal, something that can never be perfect, just "good enough" (if NSA wants to hack you, they will). You make it sound like installing third party packages is basically equivalent to a security hole, while in practice the risk is low, especially if you don't overdo it.

Wild to read extreme security views like that, while at the same time there are people here that run unconstrained AI agents with --dangerous-skip-confirm flags and see nothing wrong with it.

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

#454

Post by funcDropShadow »

withinboredom wrote: post #254
weird-eye-issue wrote: post #108

Earlier quoted context omitted.

timeoutMs is shorter ;) You guys can't appreciate a bad joke

timoutμs is even better. People will learn how to type great symbols.

They wouldn't have to, if the file format accepted floats in proper exponential format.

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

#455

Post by paustint »

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 since the entire NPM account was taken over and config can be modified to allow publishing using a token.

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

#456

Post by EMM_386 »

zdc1 wrote: post #275
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…

The other thing that keeps coming up is the github-code-is-fine-but-the-release-artifact-is-a-trojan issue. It really makes me question if "packages" should even exist in JavaScript, or if we could just be importing standard plain source code from a git repo. I understand why this doesn't work well with legacy projects, but it's something that the language could strive towards.

This might make things worse not better.

Yes - the postinstall hook attack vector goes away. You can do SHA pinning since Git's content addressing means that SHA is the hash of the content. But then your "lockfile" equivalent is just... a list of commit SHAs scattered across import statements in your source? Managing that across a real dependency tree becomes a nightmare.

This is basically what Deno's import maps tried to solve, and what they ended up with looked a lot like a package registry again.

At least npm packages have checksums and a registry that can yank things.

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

#457

Post by slowmovintarget »

ghurtado wrote: post #210
gib444 wrote: post #140

Earlier quoted context omitted.

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

If we're taking suggestions, I'd like to propose "parsec" (not to be confused with the unit of distance of the same name) That way Han Solo can make sense in the infamous quote. EDIT: even Gemini gets this wrong: > In Star Wars, a parsec is a unit of distance, not time, representing approximately 3.26 light-years

Parallax arc-second -> distance.

For Star Wars, they retconned it to mean he found the shortest possible route through dangerous space, so even for Han Solo's quote, it's still distance.

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

#458

Post by sph »

skydhash wrote: post #365
fluxist wrote: post #215

A command to recursively check for the compromised axios package version: find / -path '*/node_modules/axios/package.json' -type f 2>/dev/null | while read -l f; set -l v (grep -oP '"version"\s*:\s\*"\K(1\.14\.1|0\.30\.4)' $f 2>/dev/null); if test -n "$v"; printf '\a\n\033[1;31m FOUND v%s\033[0m \033[1;33m%s\033[0m\n' $v (string replace '/package.json' '' -- $f); else; printf '\r\033[2m scanning: %s\033[K\033[0m' (st…

What’s with all those escapes codes?

script kiddies love their ANSI color codes and fancy ASCII art

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

#459

Post by cyco130 »

afavour wrote: post #370
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…

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.

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

#460

Post by pier25 »

mrsmrtss wrote: post #265
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…

Fully agree with this! I think today .NET is probably the most batteries included platform you can get. This means that even if you use third-party libraries, these typically depend only on first-party dependencies, making it much less likely for something shady to sneak in.

Kinda.

With Bun I use less dependencies from NPM than I used from Nuget with .NET to build minimal apis. For example the pg driver.

Post reply on HN