NPM Security Concerns for JavaScript Developers

Cover Photo by Leone Venter on Unsplash

npm packages are one of the most amazing things that ever happened to JavaScript. npm says there are over 800,000 packages in the npm repository, making it the largest open-source code repository in the world. Since the JS community is so familiarized with and used to code reusability, npm was a blessing for us.

Although npm was pretty much successful, you must know what you might run into if all hell breaks loose. This article isn’t intended to freak you out but rather to educate you on the possible risks you face when you install an npm package. Understanding security concerns in the npm ecosystem is an absolute must for anyone who is doing JavaScript-related development.

What's Wrong With npm Packages?

Malicious modules

In npm, anyone with an email address can contribute. While anyone with an npm client can consume a module. A module can become malicious due to:

Upon requiring it, the module could gather information from your system or network and send it out to a third party that can cause you several issues
Upon installing it, the module could have an install phase, where it’ll run destructive commands, for example, rm -rf /

You might now wonder, why would anyone install a malicious module knowing about the security risks they pose? There are several reasons why.

You’re too lazy

Yes, this is how lazy people are. Modules are very much capable of containing security vulnerabilities.

You might say you’re not stupid enough to install modules like this. But, to be honest, you might’ve installed a genuine package that has added a malicious package as a dependency. At the end of the day, either you or the module developer was lazy, and it might cost you as a user.

Typosquatting

This is a form of attack where malicious packages are named similar to the real modules and can be installed by an accidental typo by the user. This problem is commonly found even in the PyPi Python registry as well. npm has added new naming rules to fix this.

Source: Snyk

Malicious contributors

In another scenario, the owner of the package might’ve been genuine with their intention, but a malicious contributor of the package can send a PR with a backdoor — or even add a project dependency that contains vulnerabilities.

You might not notice this, even during code review, and then you end up with a malicious package that can infect millions of users.

Compromised contributors

A member of the Node Core Technical Committee was able to gain publish permissions for popular repositories such as:

Debug
Express
React
React Native
Mongoose
Electron
MySQL

And the list goes on.

How did they manage to get permissions for these packages? Poor passwords.

According to Nikita, 662 users had the password 123456, 174 users had the password 123, and 124 users had the password password. Read more.

EventStream Chaos

EventStream is a toolkit for developers to make creating and working with streams easy. This module was compromised when it was infected with a vulnerable dependency in order to steal bitcoins from wallet applications.

The original owner of the package had transferred the ownership of the package to a user named right9ctrl. The owner indicated that he hadn’t used the module for years and transferred its ownership after he received an email regarding its maintenance.

The new maintainer then released a new version of the package with a new dependency called flatmap-stream that contained the malicious code. As flatmap-stream was encrypted, the malicious code remained undetected for over two months until a user flagged an issue. npm then reviewed the malicious code and found it to be stealing bitcoins from Copay wallets, as Copay is said to have incorporated EventStream into its app.

The backdoor has since been removed from npm.

Photo by Florencia Viadana on Unsplash

Vulnerability Discovered in Komodo’s Agama Wallet

Blockchain business Komodo discovered a vulnerability upon receiving a private notification from npm about a vulnerability in one of the upstream libraries Komodo’s Agama Wallet was using.

The malicious bug was specifically targeted at Komodo’s version of Agama Wallet. The hacker had spent several months making useful contributions to the Agama repository and eventually added malicious code to an update of a module that Komodo’s Agama was already using.

In an attempt to safeguard the funds, the Komodo team acted swiftly and had socked away 8 million KMD (Komodo) and 96 BTC (Bitcoin) tokens — worth almost $13 million — from the wallets and stashed them into two digital wallets under its control. The customers were later advised on how to reclaim their lost funds.

The vulnerable package, electron-native-notify, was added to the dependencies of Agama by the hacker. This vulnerability followed a similar pattern of the attack made on the event-stream module.

In the end, the hacker managed to gain control of approximately 1 million KMD, which is approximately $750,000 at the time of writing.

The ‘left-pad’ Fiasco

This was one of the more popular events, making news by breaking thousands of projects, including Node and Babel. The man behind the whole fiasco was Azer Koçulu — the owner of the package. This package pads out the left-hand side of strings with zeroes or spaces.

This incident came after a naming dispute with the messaging app Kik, where one of Azer’s modules was also called Kik. According to Koçulu, Kik’s briefs told him to rename the module. He refused, so the lawyers went to npm’s admins claiming brand infringement. When npm took Kik away from the developer, he was angry and unpublished all of his NPM managed modules.

“This situation made me realize that npm is someone’s private land where corporate is more powerful than the people, and I do open source because, Power To The People.” — Blog post by Koçulu

Because of the huge drama, npm stepped in and fixed the issue by forcibly restoring the project, which was unprecedented. The CTO of npm also mentioned, “Un-un-publishing is an unprecedented action that we’re taking given the severity and widespread nature of breakage, and isn’t done lightly.”

This incident shows you the level of fragility among our applications, such that if one package is removed from npm, it can affect thousands of users.

Although it’s true that, in this case, there wasn’t much of a security concern. But what if the author decided to push in some malicious code that didn’t produce an error, nor was that easy to notice.

Something for you to think about.

How to Be Safe

As I mentioned at the beginning of this article, my intention is not to freak you out but rather to educate and spread awareness.

Users

Pay attention to what modules you’re using. Don’t install unnecessary packages.
Make sure there are no typos when you install a package. Although this has been fixed on npm’s end with their new rules, it’s better to be safe on your end as well.
Run security audits (npm audit) to find and fix security vulnerabilities in existing packages
Use tools like Snyk that’ll allow you to find whether the packages you’re about to install are vulnerable or contain any malicious code. Over 400,000 developers use Snyk.

Module author

Use 2FA with authentication tokens on npm, and use tools such as Snyk in your continuous integration
Make sure your passwords aren’t reused from anywhere and that they’re quite strong (no 12345678 or password)

Enterprise

Here are some of the solutions given by Kate at QCon.

Although this doesn’t sound very practical, some companies opt to write everything from scratch
Paying open-source maintainers: Although this holds someone responsible for the security of the package, it doesn’t guarantee they won’t be compromised
Code audits: They can be great, but they still can’t assure you of the stability of a package because there are things that code audits miss
Set up a private npm repository. Although it’s convenient to use public repositories, you might run the risk of your npm modules’ security becoming compromised.

Conclusion

That’s it for this article. I highly advise you to read the below-mentioned resources to get a thorough knowledge of npm security.

Happy coding!

Why You Should Think Twice Before Installing an NPM Package or Module