On August 1 npm was notified via twitter by Oscar Bolmsten that a package is maliciously stealing environment variables on install, using the popular cross-env package as bait by publishing a package similarly called as crossenv.

@kentcdodds Hi Kent, it looks like this npm package is stealing env variables on install, using your cross-env package as bait: pic.twitter.com/REsRG8Exsx

— Oscar Bolmsten (@o_cee) August 1, 2017

According to npm report further investigations revealed 40 packages in total using the same bait technique coined as "typo-squatting".

What does this mean?

Environment variables are usually where application servers keep all their secrets such as database passwords, Amazon AWS access keys and much more sensitive data.

Because these packages often reach the production servers this can cause a hostile takeover to do anything the attacker wants, including spinning up new servers inducing large costs to the victims or gain access to databases and stealing users private data.

What do we do now?

First check the published list of malicious dependencies and check if your application or any of your dependencies are using any of the reported packages using npm ls in your application.

If you were affected you should reset all passwords and access tokens and removing the malicious packages.

How do we prevent this in the future?

While we can never guarantee malicious code entering our codebases via trusted and well known dependencies, we can continuously scan our applications for vulnerabilities using various services such as: snyk, Node Security Project (NSP), BlackDuck or any similar services which monitor our dependencies and check for vulnerbilities.

These services can alert us sooner so we can minimize the damage done as soon as possible.

Why this isn't enough?

This isn't the first time npm was mentioned in the context of security issues. Just over a year ago npm experienced a meltdown when a package called left-pad got unpublished, causing many popular packages such as Babel and ReactNative to fail installing.

Following this Nicolás Bevacqua authored a post about the security implications of npm where many concerns were not addressed. The current state of npm packages requires us to establish trust in package authors and npm but many things can go wrong even if the package author did not intend to harm us.

A package author may get his account compromised, go rogue or make a mistake. Even worse, a package could be taken over by a new author using npm Dispute Resolution which could release new versions of the package without the end users even noticing.

There are no validations in place when a package was transferred to a new author, no indication to users that the author has changed and no mechanism in place to force a major version release so users will at least have a hint to look into what changed in the package.

While npm currently deals with the issue at hand, these repeating issues call for npm to take security more seriously and think on how they can minimize attacks in the future using their platform.