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

771–780 of 894 posts

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

#771

Post by crimsonnoodle58 »

TacticalCoder wrote: post #531
crimsonnoodle58 wrote: post #402

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

> but raw.githubusercontent.com would be as it doesn't allow data to be submitted to it But raw.githubusercontent.com still contains code and now the attacker can publish the code he wants no!? Don't get me wrong: I love the idea to secure as much as possible. I'm running VMs and containerizing and I eat firewalling rules for breakfast, my own unbound DNS with hundreds of thousands (if not millions) of domains blocke…

In the case of compromised code, the attacker has already loaded what he wants, so loading extra code from raw.githubusercontent.com is not the issue, or our threat model. We are already compromised!

The issue is that code then extracting secrets and data from your organisation, ie. data exfil.

raw.githubusercontent.com can not be used to submit data to, it's read only, but github.com obviously can.

Note, if you really needed github.com access in your application or environment, then you need to use SSL interception (using squid or a firewall) and allow certain URLs and methods ie. GET requests only from your organisations path, to make it safe.

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

#772

Post by zadikian »

beart wrote: post #16
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…

> nearly every other project uses it for some reason instead of fetch (I never understood why). Fetch wasn't added to Node.js as a core package until version 18, and wasn't considered stable until version 21. Axios has been around much longer and was made part of popular frameworks and tutorials, which helps continue to propagate it's usage.

Right. Though I would've used the built in xhr then. Not going to install a dep just to make http calls.

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

#774

Post by [deleted] »

rhdunn wrote: post #674
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…

There are several issues with "Batteries Included" ecosystems (like Python, C#/.NET, and Java): 1. They are not going to include everything. This includes things like new file formats. 2. They are going to be out of date whenever a standard changes (HTML, etc.), application changes (e.g. SQLite/PostgreSQL/etc. for SQL/ORM bindings), or API changes (DirectX, Vulcan, etc.). 3. Things like data structures, graphics APIs…

[deleted]

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

#775

Post by troad »

Quothling wrote: post #691
troad wrote: post #350

Earlier quoted context omitted.

What are some examples of batteries-included languages that folk around here really feel productive in and/or love? What makes them so great, in your opinion? (Leaving aside thoughts on language syntax, compile times, tooling etc - just interested in people's experiences with / thoughts on healthy stdlibs)

I work in a NIS2 compliance sector, and we basically use Go and Python for everything. Go is awesome, Python isn't as such. Go didn't always come with the awesome stllib that it does today, which is likely partly why a lot of people still use things like Gin for web frameworks rather than simply using the standard library. Having worked with a lot of web frameworks, the one Go comes with is nice and easy enough to ex…

This is really interesting, thanks for sharing. Great food for thought.

Being tightly coupled with MS already, did you ever explore .NET?

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

#776

Post by mkdelta221 »

This is the second major npm supply chain attack this year and the playbook is identical every time: hijack a maintainer account, publish via CLI to bypass CI/CD, inject a dependency nobody's heard of.

The fix isn't better scanning (though Socket catching it in 6 minutes is impressive). The fix is npm making Trusted Publishers mandatory for packages above a download threshold. If axios can only be published through GitHub Actions OIDC, a stolen password is useless.

We run a fleet of AI agents that depend on npm packages. First thing we did tonight was audit every lockfile. Clean — but only because we aggressively minimise dependencies. The real victims here are the thousands of teams who npm install with ^ ranges and never check what changed.

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

#777

Post by chrisldgk »

My main question here is mostly why so many people still rely on axios for their fetch implementation. Native fetch has been a thing in the JavaScript world for so long, and the DX gains to using axios over it are miniscule. The only thing I can think of is axios instances, but you can easily write a tiny wrapper for fetch that would do the same.

This is a genuine question - if you still use axios, why exactly?

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

#778

Post by Quothling »

troad wrote: post #775
Quothling wrote: post #691

Earlier quoted context omitted.

I work in a NIS2 compliance sector, and we basically use Go and Python for everything. Go is awesome, Python isn't as such. Go didn't always come with the awesome stllib that it does today, which is likely partly why a lot of people still use things like Gin for web frameworks rather than simply using the standard library. Having worked with a lot of web frameworks, the one Go comes with is nice and easy enough to ex…

This is really interesting, thanks for sharing. Great food for thought. Being tightly coupled with MS already, did you ever explore .NET?

We used to have some C# but we moved away from it to have fewer languages and because it was a worse fit for us than Go and Python. I'm not sure .NET would really give us any advantages though. Microsoft treats most major languages as first class citizens in Azure, and since we build everything to be sort of platform agnostic, we wouldn't have the tie-ins that you could have with .NET. I'm not saying it would be fun to switch cloud, but all our services are build so that there is a decoupled "adapter" between our core logic and Azure. We use a lot of Azure functions as an example, but they run in container apps on a managed k8s, so the Azure function part is really just an ingress that could be swapped for anything else.

It's been a while since I worked with an "actual" function app in Azure. We did have a few .NET ones that weren't using containers. At the time they were pretty good, but today I'm not sure what the benefit over a managed container envrionment with container apps would be. Similarily with sqlserver. We use it because of governance and how it ties into data factory and I guess fabric, but we don't use ORM's so something like Entity Framework wouldn't really be something we'd benefit from with .NET.

I think the only thing we couldn't realistically replace and get something similar is the governance, but that's more to do with how Management Groups, Policies, Subscriptions and EntraID works than anything else.

Eventuallyt everything will probably be Python and then C/Zig for compute heavy parts. Not because Python is great, it's terrible, but it's what everyone uses. We're an energy company and with the internal AI tools we've made widely available we now have non-SWE employees writing code. It's Business Intelligence, it's Risk analysys, it's powerplant engineers, it's accountants. They're all working with AI code in their sandboxed environments and it's all Python. Since some of it actually turns out to generate great value, it's better for us (and the business) if our SWE teams can easily take over when "amateur hour" needs to meet operational compliance for the more "serious" production envrionments. I put things in "'s because I'm still not entirely sure how to express this. A lot of what gets build is great, and would have never been build without AI because we don't have the man power, but it's usually some pretty bad software. Which is fine, until it isn't.

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

#779

Post by everforward »

gjadi wrote: post #657
estebank wrote: post #537

Earlier quoted context omitted.

Don't do this. Use a package manager that let's you specify a specific version to pin against. Vendoring side steps most automated tooling that can warn you about vulnerabilities. Vendoring is a signal that your tooling is insufficient, 99% of the time.

Vendoring means you don't have to fetch the internet for every build, that you can work offline, that you're not at the mercy of the oh-so-close-99.999 availability, that it will keep on working in 10 years, and probably other advantages. If your tooling can pull a dependency from the internet, it could certainly check if more recent version from a vendored one is available.

This is only true if you aren’t internally mirroring those packages.

Most places I’ve worked have Artifactory or something like it sitting between you and actual PyPI/npm/etc. As long as someone has pulled that version at some point before the internet goes out, it’ll continue to work after.

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

#780

Post by themafia »

ArcHound wrote: post #743
themafia wrote: post #714

Earlier quoted context omitted.

Are those the ones typically involved in supply chain attacks? There are no perfect solutions; but, let's be reasonable.

Actually, yes, they are the prime targets: https://en.wikipedia.org/wiki/Npm_left-pad_incident or seemingly https://en.wikipedia.org/wiki/XZ_Utils_backdoor as well.

xz has dozens of contributors and two active maintainers. It was the actual example I was thinking of. The code was submitted by a third party and not a result of a developer machine compromise.

left pad wasn't a security incident. It was a capitalism incident.

Post reply on HN