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

751–760 of 894 posts

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

#751

Post by lelanthran »

commandlinefan wrote: post #662
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…

> "Batteries included" ecosystems are the only persistent solution Or write your own stuff. Yes, that's right, I said it. Even HTTP. Even cryptography. Just because somebody else messed it up once doesn't mean nobody should ever do it. Professional quality software _should_ be customized. Professional developers absolutely can and should do this and get it right. When you use a third-party HTTP implementation (for ex…

> When you use a third-party HTTP implementation (for example), you're invariably importing more functionality than you need anyway. If you're just querying a REST service, you don't need MIME encoding, but it's part of the HTTP library anyway because some clients do need it. That library (that imports all of its own libraries) is just unnecessary bloat, and this stuff really isn't that hard to get right.

This post is modded down (I think because of the "roll your own crypto vibe", which I disagree with), but this is actually spot on the money for HTTP.

The surface area for HTTP is quite large, and your little API, which never needed range-requests, basic-auth, multipart form upload, etc suddenly gets owned because of a vulnerability in one of those things you not only never used, you also never knew existed!

"Surface area" is a problem, reducing it is one way to mitigate.

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

#752

Post by 1970-01-01 »

__jonas wrote: post #542
1970-01-01 wrote: post #494

Earlier quoted context omitted.

I use Jia Tan as a figurehead for malicious maintainers. This clearly was a targeted hack. Does it really matter how long it took to get the job done?

I'd argue this has not much in common with Jia Tan apart from both being supply chain attacks, there is no malicious maintainer here, a trusted maintainer had their account taken over. I guess the end result is the same, a malicious package pushed by an account that was thought to be trusted, but I think the Jia Tan case is worth being looked at differently than just simple account takeover.

It's just a longer backstory. All the same in the end. Hackers targeted a popular package. The lead maintainer was compromised. The pattern fits. There will be more of these.

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

#753

Post by vovavili »

mrits wrote: post #695
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…

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

Python's standard library is definitely much more batteries-included than JavaScript's.

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

#754

Post by commandlinefan »

lelanthran wrote: post #751
commandlinefan wrote: post #662

Earlier quoted context omitted.

> "Batteries included" ecosystems are the only persistent solution Or write your own stuff. Yes, that's right, I said it. Even HTTP. Even cryptography. Just because somebody else messed it up once doesn't mean nobody should ever do it. Professional quality software _should_ be customized. Professional developers absolutely can and should do this and get it right. When you use a third-party HTTP implementation (for ex…

> When you use a third-party HTTP implementation (for example), you're invariably importing more functionality than you need anyway. If you're just querying a REST service, you don't need MIME encoding, but it's part of the HTTP library anyway because some clients do need it. That library (that imports all of its own libraries) is just unnecessary bloat, and this stuff really isn't that hard to get right. This post i…

> the "roll your own crypto vibe", which I disagree with

Again, you run into the attack surface area here. Think about the Heartbleed vulnerability. It was a vulnerability in the DTLS implementation of OpenSSL, but it affected every single user, including the 99% that weren't using DTLS.

Experienced developers can, and should, be able to elide things like side-channel attacks and the other gotchas that scare folks off of rolling their own crypto. The right solution here is better-defined, well understood acceptance criteria and test cases, not blindly trusting something you downloaded from the internet.

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

#755

Post by exyi »

raddan wrote: post #376
mrsmrtss wrote: post #265

Earlier quoted context omitted.

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.

With the notable exception of cross-platform audio.

and cross-platform UI

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

#756

Post by habinero »

skydhash wrote: post #731
habinero wrote: post #653

Earlier quoted context omitted.

> Smaller algorithms can be shared with gists and blog articles You just invented a worse Stack Overflow. Using libraries is good, actually.

Like is-even or leftpad?

Like requests and pytest and ruff and so on, yes.

Rewriting the world to protect against a specific kind of threat is insane.

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

#757

Post by nailer »

augusto-moura wrote: post #629
nailer wrote: post #570

Earlier quoted context omitted.

> `fetch` is the official replacement for axios. No. Axios is still maintained. They have not deprecated the project in favor of fetch.

I'm not saying that axios is unmaintained, I'm saying that if you want something like axios from the standard lib, fetch is the closest thing you get to official

Sure but Axios determine what the official replacement for Axios is.

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

#758

Post by lelanthran »

commandlinefan wrote: post #754
lelanthran wrote: post #751

Earlier quoted context omitted.

> When you use a third-party HTTP implementation (for example), you're invariably importing more functionality than you need anyway. If you're just querying a REST service, you don't need MIME encoding, but it's part of the HTTP library anyway because some clients do need it. That library (that imports all of its own libraries) is just unnecessary bloat, and this stuff really isn't that hard to get right. This post i…

> the "roll your own crypto vibe", which I disagree with Again, you run into the attack surface area here. Think about the Heartbleed vulnerability. It was a vulnerability in the DTLS implementation of OpenSSL, but it affected every single user, including the 99% that weren't using DTLS. Experienced developers can, and should, be able to elide things like side-channel attacks and the other gotchas that scare folks of…

The reason I disagree about crypto is because:

1. It's really really hard to verify that you have not left a vulnerability in (for a good time, try figuring out all the different "standards" needed in x509), but, more importantly,

2. You already have options for a reduced attack surface; You don't need to use OpenSSL just for TLS, you can use WolfSSL (I'm very happy with it, actually). You don't need WolfSSL just for public/private keys signing+encryption, use libsodium. You don't need libsodium just for bcrypt password hashing, there's already a single function to do that.

With crypto, you have some options to reduce your attack surface. With HTTP you have few to none; all the HTTP libs take great care to implement as much of the specification as possible.

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

#759

Post by habinero »

ArcHound wrote: post #738
zbentley wrote: post #603

Earlier quoted context omitted.

Pinning, escrowing, and trailing all help, but I'm not sure "this step will be eliminated" is inevitable. Package manager ecosystems are highly centralized. npm.org could require MFA (or rate limit, or email verification, or whatever) and most packagers would gripe but go along with this. A minority would look for npm competitors that didn't have this requirement, and another minority would hack/automate MFA and remo…

Let me rephrase - manual security verification is a velocity blocker. People won't do manual security verification of changes. I agree that npm.org requiring MFA is a good idea in general and in this case.

Yup. As someone who's been on both the eng and security side, you cannot improve security by blocking the product bus. You're just going to get run over. Your job is to find ways of managing risk that work with the realities of software development.

And before anyone gets upset about that, every engineering discipline has these kind of risk tradeoffs. You can't build a bridge that'll last 5,000 years and costs half of our GDP, even though that's "safer". You build a bridge that balances usage, the environment, and good stewardship of taxpayer money.

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

#760

Post by habinero »

SkyPuncher wrote: post #468
silverwind wrote: post #367

Earlier quoted context omitted.

Eventually you will want to update it, every update is a risk.

But, pinning has prevented most of the recent supply chain attacks. As long as you don't update your pins during an active supply chain attack, the risk surface is rather low.

The flip side of that is now you're running old software and CVEs get published all the time. Threat actors actively scan the internet looking for software that's vulnerable to new CVEs.
Post reply on HN