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

141–150 of 894 posts

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

#141

Post by captn3m0 »

himata4113 wrote: post #30

I recommend everyone to use bwrap if you're on linux and alias all package managers / anything that has post build logic with it. I have bwrap configured to override: npm, pip, cargo, mvn, gradle, everything you can think of and I only give it the access it needs, strip anything that is useless to it anyway, deny dbus, sockets, everything. SSH is forwarded via socket (ssh-add). This limits the blast radius to your CW…

This only works for post-install script attacks. When the package is compromised, just running require somewhere in your code will be enough, and that runs with node/java/python and no bwrap.

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

#142

Post by sayamqazi »

zdragnar wrote: post #97
reactordev wrote: post #21

Earlier quoted context omitted.

You can do all of that in fetch really easily with the init object. fetch('https://api.example.com/data', { headers: { 'Authorization': 'Bearer ' + accessToken } })

There are pretty much two usage patterns that come up all the time: 1- automatically add bearer tokens to requests rather than manually specifying them every single time 2- automatically dispatch some event or function when a 401 response is returned to clear the stale user session and return them to a login page. There's no reason to repeat this logic in every single place you make an API call. Likewise, every respo…

> usage patterns

IMO interceptors are bad. they hide what might get transformed with the API call at the place it is being used.

> Likewise, every response I get is JSON. There's no reason to manually unwrap the response into JSON every time.

This is not true unless you are not interfacing with your own backends. even then why not just make a helper that unwraps as json by default but can be passed an arg to parse as something else

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

#143

Post by [deleted] »

friendzis wrote: post #98
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…

> (Side note, it's wild that npm, bun, and pnpm have all decided to use different time units for this configuration.) First day with javascript?

[deleted]

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

#145

Post by himata4113 »

captn3m0 wrote: post #141
himata4113 wrote: post #30

I recommend everyone to use bwrap if you're on linux and alias all package managers / anything that has post build logic with it. I have bwrap configured to override: npm, pip, cargo, mvn, gradle, everything you can think of and I only give it the access it needs, strip anything that is useless to it anyway, deny dbus, sockets, everything. SSH is forwarded via socket (ssh-add). This limits the blast radius to your CW…

This only works for post-install script attacks. When the package is compromised, just running require somewhere in your code will be enough, and that runs with node/java/python and no bwrap.

node is also sandboxed within bwrap I have sandbox -p node if I have to give node access to other folders, I also have sandbox -m to define custom mountpoints if necessary and UNSAFE=1 as a last resort which just runs unsandboxed.

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

#146

Post by [deleted] »

hvb2 wrote: post #128
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…

If you're developing for the web your attack surface is quite a bit bigger. Your proposed solution of copying a few files might work but how do you keep track of updates? You might be vulnerable to a published exploit fixed a few months ago. A package manager might tell you a new version is available. I don't know how that would work in your scenario.

[deleted]

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

#148

Post by strogonoff »

Essential steps to minimise your exposure to NPM supply chain attacks:

— Run Yarn in zero-installs mode (or equivalent for your package manager). Every new or changed dependency gets checked in.

— Disable post-install scripts. If you don’t, at least make sure your package manager prompts for scripts during install, in which case you stop and look at what it’s going to run.

— If third-party code runs in development, including post-install scripts, try your best to make sure it happens in a VM/container.

— Vet every package you add. Popularity is a plus, recent commit time is a minus: if you have this but not that, keep your eyes peeled. Skim through the code on NPM (they will probably never stop labelling it as “beta”), commit history and changelog.

— Vet its dependency tree. Dependencies is a vector for attack on you and your users, and any new developer in the tree is another person you’re trusting to not be malicious and to take all of the above measures, too.

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

#149

Post by layer8 »

superjan wrote: post #88
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…

About the use of different units: next time you choose a property name in a config file, include the unit in the name. So not “timeout” but “timeoutMinutes”.

Or require the value to specify a unit.
Post reply on HN