Node.js broadcasts: Google engineers found vulnerabilities in NPM scripts

Node.js developers, run the `npm install` command at your own risk and remember that the self-propagating worm walks freely through the ecosystem.

You can never assume that a file downloaded from the Internet is safe. This is also true for NPM, the standard Node.js package manager. Script installation vulnerability allows an attacker to create a self-propagating worm that can pass through NPM packages.


“This is possible because one NPM package can easily pass through most of the ecosystem,” writes Google developer Sam Sakoni in his article “Exposing the NPM Hydra.”

Just like in other package managers, NPM supports “lifecycle” scripts that can be executed by third-party commands in the system as the current user. Although these scripts are often useful and used to clean up files after the installation process, compiling binary modules and automatically creating configuration files, but at the same time they can be dangerous, as they can make any changes to the system when executing various commands.
“Probably, NPM packages written with malicious intent, when installed, execute scripts that are embedded in other packages, which in turn are published in the registry, and other packages created by the user,” write an article in the official NPM blog. However, the company reports that the benefits of using these scripts outweigh the risks of a potential threat.

Post minimizes the risk and draws attention to the packages that are “clean from the very beginning,” but not all of them are “one hundred percent” sure of this. The article Sakoni, in addition to a few workarounds, does not make it clear how to be sure that the packages that users install will not turn out to be what was expected.

“NPM cannot guarantee that their package registry is secure,” the article notes.

Worm leaks through package dependencies

The worm uses three possibilities in NPM: semantic versioning (semver), publication in a centralized registry, and user privileges, which automatically log in. Because the user remains logged in until he logged out manually. Anyone who entered and started the installation allows other modules to execute a wide variety of commands. While there is no binding to specific versions, packages can be updated to new versions, and each of them can execute code. And finally, they can send packages to the central registry server, from where others can install them.

The attack of the worm relies on social engineering for initial infection and the aforementioned “improvements” can move freely throughout the ecosystem.

First, the attacker fraudulently forces the owner of the NPM package to install the infected package on his system. This could be phishing or any other such attack. Once installed, it creates a “Trojan” version of the package of the owner of the NPM module and sets up an interceptor (hook) to launch the worm wherever it is installed. A modified module published on the owner’s account becomes the starting point for infecting all its packages, launching the Trojan module as a dependency. The worm creates new versions of the modules in the account with the comment “bugfix”, and now, when it is installed, the self-propagating code can be executed.

For example. PhoneGap has 463 intermediate dependencies. And 276 individual NPM accounts can update their package versions. Now only one person from the 276 is enough for the worm to continue to infect everyone who installed the package from the PhoneGap project, Sakoni says.

NPM avoids risks

Until the “hole” is closed, a note on the vulnerability to the “United States Computer Emergency Readiness Team” covers several solutions for circumventing the danger. They use the “-ignore-scripts” option when they install new dependencies, close the versions with `npm-shrinkwrap`, and encourage users whose modules themselves are constantly logged out from NPM.

Organizations using NPM in their environments should run the local mirror of the NPM registry and prevent individual users from installing dependencies directly from the main registry. They should regularly check the local registry and make sure that the malicious files are not in the list of dependencies.

Sakoni recommended setting the time for tokens to expire and forcing users to leave NPM after a certain period of time. In a blog, the company did not describe these recommendations, but voiced other solutions to minimize risks.

One of the ideas is to complicate the publication of the modules, if the user is not aware of the danger, it can be two-factor authentication. You can still work with companies that offer protection by offering the latest test modules, but for now this is not possible. At the moment, the company monitors frequently updated packages, since the worm can be detected by very frequent releases of new versions, but they rely more on users who will themselves notify about suspicious packages.

“Undoubtedly, if many users attempt to massively publish malicious packages, they will be available in the NPM registry,” the blog said.

Trust but check

This will be a difficult few days for NPM. Detection of malicious published packages is their “Achilles heel”. In current debates on the topic of regulation by the manager of packages removed from the registry. The removal of the developer package from NPM last week, thereby breaking a lot of projects dependent on him. It is also quite simple to register your code under the name of the remote module. Anyone who has assigned someone else's name can set the code to any user who depends on the original.

Reddit and GitHub have been arguing a lot over the past few days about the credibility of developers, the maintenance of the packages they have created and whether they will not start creating malicious code. In a global ecosystem, this is a dangerous assumption, because if one such developer wants to break a lot of code, he will have to confront the whole community. However, there must be ways to safely install modules, it can be a digital signature or other code verification methods for security and correctness. In the meantime, it remains only to feel anxiety every time you run the `npm install` command.

Original article: www.infoworld.com/article/3048526/security/nodejs-alert-google-engineer-finds-flaw-in-npm-scripts.html