Wednesday, 05 July 2023 13:58

NPM is back in the news as Node.js is found to be open to a Manifest Confusion Attack

Written by

Reading time is around minutes.

It has been a few days since we talked about NPM and node.js. The popular repository has been taking a bit of a beating in recent months as attackers, hacktivists, and others seek to compromise their packages as part of a general supply chain attack. Supply chain attacks are in vouge right now and are part of the reason you might be seeing the acronym SBOM (Software Build of Materials) so much. Sure, SBOM is not a new term, but the push for it and the rise of an entire vertical in the cybersecurity industry is new and should be a bit of an indicator that there is a problem.

Ok back to the beleaguered NPM. It seems that the popular package node.js is vulnerable to what is called manifest confusion. The attack is pretty much what it sounds like. A Manifest is a list of dependencies and actions that are executed during the installation of node.js. In the case of node.js, the manifest is not part of the tarball (package) and is not validated. The repository and installation just assume that the manifest in use is consistent and all good. This leaves a bit of a security gap. An attacker can upload a package with a poisoned manifest. This manifest can download malware, execute scripts and all kinds of fun stuff.

This means that development environments need to do some work on the front end to ensure that the manifests connected to the module in use are the correct ones and do not contain any “extra” features. Not a terribly difficult thing to do, but sadly, many development environments are not set up to properly integrate security into their development operations. I my experience, security (including EDR and DLP) is seen as a problem that prevents proper development and impacts the ability to get new software out. This is not to say that all development environments are wide open to attack. It is just that many are left more open than they should be due to the way EDR and other security tools impact testing and even compilation of new binaries.

The new focus on open-source repositories and other common components for development should change that. Well, let me rephrase that; this new attack vector should persuade organizations to review and identify areas of improvement in the building of new software. The development of scanning new modules and other packages in use along with scanning for existing vulnerabilities in the SBOM should be the next step in proper DevSecOps program development. If this will really happen is anyone’s guess. Sometimes it takes a big compromise before anything changes, but we do hope the industry will take proactive steps to shore up security on the front end instead of trying to patch things after the shit has hit the fan.

Open-source repositories are fantastic for helping to save time when developing new software. However, they are also more and more open to attacks. This does not mean that people should stop using them, it just means that both the repository admins and the people using those modules need to be aware of the existing threat and take steps to make sure they do not become victims of malicious activity.
Happy coding

Read 560 times

Leave a comment

Make sure you enter all the required information, indicated by an asterisk (*). HTML code is not allowed.