Here it's clear that the package links to something in a weird, non-standard way. A manual review would tell you that this is not axios.
The package.json lets you link to things that aren't even on npm [1]. You could update this to something like:
"axios": "git://cdnnpmjs.com/axios"
And it becomes less clear that this is not the thing you were intending. But at least in this case, it's clear that you're hitting a git repository somewhere. What about if we update it to the following?
"axios": "axiosjs/latest"
This would pull the package from GitHub, from the org named "axiosjs" and the project named "latest". This is much less clear and is part of the package.json spec [2]. Couple this with the fact that the npm website tells you the project depends on Axios, and I doubt many people would ever notice.
this is still true of node/npm. It's also true of Cargo (Rust), Nuget (C#), and a handful of others. I'd say it's probably the _norm_ for most ecosystems to allow some form of pre/post-install execution.
For what is worth in nix after the code is downloaded the code is built in a sandbox without network access. So one does have a viable alternative for Rust.
And is true that most package managers for popular language allow arbitrary code execution during the install process. That is how husky adds git hooks to the developers machines.
For example in Ruby I need to patch the Kafka gem, karafka because it downloads, builds and stores librdkafa.so in the gem's directory.
I understand that this as well as the husky example comes from a desire to make developer lifes easier but I'd rather we erred on the side of caution. Making sure that software builds without access to the network and without being able to modify your system (ej. Adding files to $HOME)
I'm one of the co-founders @ Phylum. We've been tracking this campaign [1] (along with several other unrelated ones). The collective group of security researchers (Shoutout to https://vipyrsec.com/) in our Discord have been reporting these packages to PyPI for removal. If this is something you'd be interested in helping with, please join our Discord (https://discord.gg/Fe6pr5eW6p)!
Besides the gigantic analytics platform we've constructed to monitor supply chain attacks targeting open source, we've also open sourced a few tools to better mitigate attacks targeting developers. For example, a sandbox to minimize the impacts of malicious packages during installation [2] (with a pre-check to our API for known malware), which allows you to do things like
phylum npm install <pkgName>
Happy to answer any questions about this campaign or others we've uncovered!
Yeah, the broad campaign makes it extremely noticeable. There are active campaigns right now that don't take this approach. Singular packages with novel malicious payloads.
> As a person who regularly runs pip install on my main desktop, where I am worried about arbitrary code execution that happens when you pip install.
We've open-sourced a sandbox and wrapped the Phylum CLI with it so you can do something like `phylum pip install <pkgName>,` it'll check our API first for known malware, then if it appears clean, will perform the installation in the sandbox. You can specify what the sandbox is allowed to touch in a TOML file.
Co-founder @ Phylum here (https://phylum.io). We've been actively scanning dependencies across most open source package registries (e.g., npm, PyPI, Crates.io, etc.) for a few years now. Quite successfully, I might add, with recent findings targeting financial institutions [1], North Korean state actors [2], and some of the first malware staging to be seen on Crates.io [3].
The fact that an attacker was able to pull this off against a _secure_ hardware device is shocking but not surprising. The mechanism by which they did it is interesting and fairly insidious. Unlike a lot of other attacks that will publish the malware to the registry, this one pulls the payload from a CDN. So, static analysis of the loader (i.e., the intermediary package on npm) is unlikely to yield sufficiently interesting results. Solely focusing on the obfuscation angle is also not of particular use since quite a bit of packages are obfuscated on npm (like, a surprising amount of it. In Q3 2023 we saw over 5,000 _new_ packages shipped with some form of obfuscation).
Nonetheless, our automated platform pinged us this morning about some changes to this package and our research team has been digging into it to determine the impacts.
With that said, we've produced (and open sourced!) several tools that aim to help with software supply chain style attacks:
1. Birdcage is a cross-platform embeddable sandbox [4]
2. Our CLI is extensible and integrates Birdcage so you can do things like `phylum npm install...` or `phylum pip install...` and have the package installations be sandboxed [5]
We've also got a variety of integrations [6] along with a threat feed of software supply chain attacks (of which the Ledger package and other APT attacks have appeared).
Happy to answer any questions! A collective of us are active in Discord (https://discord.gg/Fe6pr5eW6p), continuing to hunt attacks like these. If that's something that interests you, we'd love to have you!
https://www.darpa.mil/program/translating-all-c-to-rust