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

271–280 of 894 posts

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

#271

Post by nailer »

hresvelgr wrote: post #211
pjc50 wrote: post #154

Earlier quoted context omitted.

Package managers are now basically a requirement for language adoption. Doing it manually is not a solution, in an automated world. What is a problem is library quality. Which is downstream of nobody getting paid for it, combined with an optimistic but unrealistic "all packages are equal" philosophy. > High quality C libraries > OpenSSL OpenSSL is one of the ones where there's a ground up rewrite happening because th…

> Package managers are now basically a requirement for language adoption. Doing it manually is not a solution, in an automated world. Absolute nonsense. What does automated world even mean? Even if one could infer reasonably, it's no justification. Appealing to "the real world" in lieu of any further consideration is exactly the kind of mindlessness that has led to the present state of affairs. Automation of dependen…

> Automation of dependency versions was never something we needed

How do you handle updating dependencies then?

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

#272

Post by dfreire »

sgt wrote: post #195

Is this an issue for those only using axios on the frontend side like in a VueJS app?

Absolutely. If you ever did a npm install on a project using one of the affected axios versions, your entire system may be compromised.

> The malicious versions inject a new dependency, plain-crypto-js@4.2.1, which is never imported anywhere in the axios source code. Its sole purpose is to execute a postinstall script that acts as a cross platform remote access trojan (RAT) dropper, targeting macOS, Windows, and Linux. The dropper contacts a live command and control server and delivers platform specific second stage payloads. After execution, the malware deletes itself and replaces its own package.json with a clean version to evade forensic detection.

I strongly recommend you read the entire article.

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

#273

Post by nesarkvechnep »

whatisthiseven wrote: post #230
berkes wrote: post #220

Earlier quoted context omitted.

> Workdays! This is java script , not Java. In JavaScript something entirely new would be invented, to solve a problem that has long been solved and is documented in 20+ year old books on common design patterns. So we can all copy-paste `{ or: [{ days: 42, months: 2, hours: "DEFAULT", minutes: "IGNORE", seconds: null, timezone: "defer-by-ip" }, { timestamp: 17749453211*1000, unit: "ms"}]` without any clue as to what…

But you know that Java solution will continue working even after we no longer use the Gregorian Calendar, the collapse and annexation of Malaysia to some foreign power, and then us finally switching to a 4-day work week; so it'd be worth it.

It probably won’t work correctly from the get go. But it can be debugged everywhere so that’s good.

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

#274

Post by Levitating »

ivanjermakov wrote: post #266
Ciantic wrote: post #263

NPM should learn from Linux distribution package managers. Have a branch called testing, and packages stay in testing for few weeks, after which they go to stable. That is how many Linux distributions handle packages. It would have prevented many of these. Advising every user of npm/pnpm to change their settings and set their own cooldown periods is not a real choice.

NPM is one big AUR, where anyone can submit arbitrary unverified code. The difference is that AUR is intentionally harder to use to prevent catastrophic one-line installs.

Is a "AUR" now just how we name unaudited software repositories?

Just to note, if we're talking about Linux Distributions. There's also COPR in Fedora, OBS for OpenSUSE (and a bunch of other stuff, OBS is awesome), Ubuntu has PPAs. And I am sure there's many more similar solutions.

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

#275

Post by zdc1 »

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.

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

#276

Post by abustamam »

WD-42 wrote: post #99
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…

Props to uv for actually using the correct config path jfc what is “bunfig”

Silly portmanteau of "bun" and "config"

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

#277

Post by cowl »

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…

min release age to 7 days about patch releases exposes you to the other side of the coin, you have an open 7 days window on zero-day exploits that might be fixed in a security release

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

#278

Post by victorbjorklund »

nananana9 wrote: post #114

Package managers are a failed experiment. We have libraries like SQLite, which is a single .c file that you drag into your project and it immediately does a ton of incredibly useful, non-trivial work for you, while barely increasing your executable's size. The issue is not dependencies themselves, it's transitive ones. Nobody installs left-pad or is-even-number directly, and "libraries" like these are the vast majori…

I think you can do copy paste in most languages. But it will be a pain to update when there are improvements / security fixes.

You got a project with 1-2 depencies? Sure. But if you need to bring in 100 different libs (because you bring in 10 libs which in turn brings in 10 libs) good luck.

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

#279

Post by powerpixel »

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…

Is there a way to do that per repo for these tools ? We all know how user sided configuration works for users (they usually clean it whenever it goes against what they want to do instead of wondering why it blocks their changes :))

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

#280

Post by Levitating »

Ciantic wrote: post #263

NPM should learn from Linux distribution package managers. Have a branch called testing, and packages stay in testing for few weeks, after which they go to stable. That is how many Linux distributions handle packages. It would have prevented many of these. Advising every user of npm/pnpm to change their settings and set their own cooldown periods is not a real choice.

Not all distributions work with a staging repository, and it's not really intended for this purpose either.

Besides there's always a way to immediately push a new version to stable repositories. You have to in order to deal with regressions and security fixes.

Post reply on HN