The Wacky World of JavaScript and npm: Protecting The Software Supply Chain (Not!)

The Wacky World of JavaScript and npm: Protecting The Software Supply Chain (Not!)

PIP and NPM under attack?

JavaScript is the best and the worst of computer programming. It is able to exist in both the front end (the browser) and in the back end (with Node.js). It basically saved the Web as we moved from static Web pages to delivering dynamic content. With JavaScript, we could then enable direct interaction with the user but also capture and process data when required. It was a stroke of genius that allowed the same code in a Web page to be used on the back end (Node.js).

But, it is sloppy language and rather unpredictable. Many love its methods, as a simple npm (Node Package Manager) can install the required software and libraries without any fuss:

npm install cryptography

But this simplicity can lead to problems. And, for Python, the pip command makes it easy to install libraries:

pip install cryptography

But these can lead to back-door trojans if an adversary places a back door in one of the associated libraries. Along with this, we can get typosquatting, and where a developer might type:

pip install crypgraphy

and download a malicious library. For this, an adversary needs to get their code onto one of the trusted repositories for JavaScript and Python.

Protecting the supply chain

The SolarWinds attack should act as a lesson in the importance of protecting the software supply chain, as backdoors can be applied to trusted software. For this, an adversary could either break into a trusted software system and add a backdoor in the software and then, with a compromised private key, sign the update as being valid. Also, an adversary could add a backdoor to open-source software that might go unnoticed when built.

And, so, software languages tend to vary greatly in their control of libraries. With Rust, for example, we have Cargo, and which is a strongly versioned package manager. This will build a Rust program with a strict linkage of libraries to a given version — rather than taking the up-to-date version. All of the code is compiled strictly against versions of the binding to the code. Golang is less tightly defined and uses a git pull of the current version and stores it locally on a machine. A new git pull is required to update the version.

The problem with npm and pip

Now, it has been reported by Phylum that a new stealthy malware is spreading within npm [here]:

With this, they reported on 31 July 2023 that there were suspicious activities on npm, and that 10 “test” packages were published. The research team found that they were part of a targeted malware attack — and which focused on exfiltrating source code and confidential information. This involved several iterations of updates before the final malware was constructed, as it shows that adversaries can focus on small incremental updates rather than showing the complete code at a single instance. This can allow malicious code to go undetected — and where the increments look like sensible updates.

Overall, the packages had sensible-looking names —and an example of “npm typosquatting”. A recent example included the creation of a package named “aabquerys”, which is similar to the valid package of “abquery” [here]. With is it was found that it installs a legitimate EXE (wsc_proxy.exe) and which is digitally signed with a valid certificate but where is can be used as a side loader for malware. With a side loader, a valid and trusted program is run, but where it loads malicious code. In the malware version, a malicious file named wsc.dll is placed in the same place as wsc_proxy.exe, and which loads wsc.dll when invoked (Figure 1).

And pip, too, does not have a great track record for protecting against malicious packages. A recent report from ReversingLabs involves the integration of the Python Package Index (PyPI) repository and includes the identification of 24 malicious packages that link to three popular open-source tools: vConnector, eth-tester and databases [here]. The target for these seem to be for cryptocurrency-focused developers.

Conclusions

Watch the versions of your code, as you could be a trojan for others. A backdoor compiler, for example, is one of the most difficult threats to detect, and it can infect a whole lot of systems that you may be responsible for.