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

691–700 of 894 posts

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

#691

Post by Quothling »

troad wrote: post #350
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…

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 extend. Python is terrible, but on the plus side it's relatively easy to write your own libraries with Python, and use C/Zig to do so if you need it. The biggest challenges for us is that we aren't going to write a better MSSQL driver than Microsoft, so we use quite a bit of dependencies from them since we are married with Azure. These live in a little more isolation than what you might expect, so they aren't updated quite as often as many places might. Still, it's a relatively low risk factor that we can accept.

Our React projects are the contrast. They live in total and complete isolation, both in development and in production. You're not going to work on React on a computer that will be connected to any sort of internal resources. We've also had to write a novel's worth of legal bullshit explaining how we can't realistically review every line of code from React dependencies for compliance.

Anyway, I don't think JS/TS is that bad. It has a lot of issues, but then, you could always have written your own wrapper ontop of Node's fetch instead of using Axios. Which I guess is where working in the NIS2 compliance sector makes things a little bit different, because we'd always chose to write the wrapper instead of using one others made. With the few exceptions for Microsoft products that I mentioned earlier.

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

#692

Post by zymhan »

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…

> They are going to be out of date whenever a standard changes (HTML, etc.)

You might want to elaborate on the "etc.", since HTML updates are glacial.

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

#693

Post by carlbarrdahl »

Imustaskforhelp wrote: post #690
carlbarrdahl wrote: post #686

Many of the suggestions in this thread (min-release, ignore script) are defenses for the consumers. I've been working on Proof of Resilience, a set of 4 metrics for OSS, and using that as a scoring oracle for what to fund. Popularity metrics like downloads, stars, etc are easy to fake today with ai agents. An interesting property is that gaming these metrics produces better code, not worse. These are the 4 metrics: 1…

Carl, with all due respect, have you used AI for making this hackmd post? "it's not just a waste of money — it's a security problem" I am really passionate about these things, but I am not going to read something which you haven't written. Even sharing a prompt/rough-sketches/raw-writing might be beneficial but I recommend writing it by-hand man, we are all burnt out reading AI slop, I can't read more AI

You're right, I used an LLM to help write it from sketches. Gonna rewrite it properly because I think the ideas are worth exploring. Thanks for taking the time to read and reply.

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

#694

Post by zymhan »

integralid wrote: post #453
paintbox wrote: post #416

Earlier quoted context omitted.

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…

Installing 3rd party packages the way Node and Python devs do regularly _is_ a security hole.

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

#695

Post by mrits »

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…

Python, .NET, and Java are not examples of batteries included.

Django and Spring

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

#696

Post by mrits »

zymhan wrote: post #692
rhdunn wrote: post #674

Earlier quoted context omitted.

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…

> They are going to be out of date whenever a standard changes (HTML, etc.) You might want to elaborate on the "etc.", since HTML updates are glacial.

glaciers change faster than HTML

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

#697

Post by estebank »

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.

Is there any package manager incapable of working offline?

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

#698

Post by xyst »

yet another npm supply chain attack, these are becoming as ubiquitous as gun violence in the US.

We have become numb to it.

One of my tools, bruno, was impacted but seems to be limited to cli via npm install [1]

[1] https://github.com/usebruno/bruno/security/advisories/GHSA-6...

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

#699

Post by cleansy »

dj_mc_merlin wrote: post #231
cleansy wrote: post #218

To have an initial smoke test, why not run a diff between version upgrades, and potentially let an llm summarise the changes? It’s a baffling practice that a lot of developers are just blindly trusting code repos to keep the security standards. Last time I installed some npm package (in a container) it loaded 521 dependencies and my heart rate jumped a bit

Is this the first time you have ever thought about the idea of supply chain attacks? This is the first thought 90% of people have and it doesn't work. Too much work to manually verify diffs and LLMs aren't good enough at this yet.

No, I think about it all the time. It’s just baffling that this kind of attack is still a thing, after a decade+ of this happening over and over again.

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

#700

Post by twodave »

philipwhiuk wrote: post #547
twodave wrote: post #545

How is it we've made it this far and we still don't have any kind of independent auditing of basic publish security on NPM? You'd think this would be collectively a trivial and high priority task (to ensure that all publishes for packages over a certain download volume are going through a session that authenticated via MFA, for instance).

> You'd think this would be collectively a trivial and high priority task (to ensure that all publishes for packages over a certain download volume are going through a session that authenticated via MFA, for instance). Because all mainstream packages are published via CI/CD pipeline not by an MFA'd individual uploading a GZIP to npm.com

You can still have a step that requires a certain user/group to sign off, and you can still enforce that those users have MFA set up. Almost any serious shop that expects to pass audits already does this in some form or fashion before pushing code to prod.
Post reply on HN