You are here

You are here

Check your dependencies: GitHub's npm finds nasty Trojan packages

Richi Jennings Industry analyst and editor, RJAssociates

Our favorite JavaScript package manager, npm, has ’fessed up to hosting four highly malicious packages for up to 18 months. And it’s not the first time the GitHub-owned registry has had to kick code from dodgy devs.

So what? I don’t have any dependencies on plutov-slack-client, nodetest1010, nodetest199, or npmpubman. But it’s hard to be sure: What about my subdeps? Or my subsubdeps? Or my subsubsubdeps. Or my …

You get the picture? In this week’s Security Blogwatch, we’re in a maze of twisty little passages, all alike.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: icky fruit.

“Now Publish Malware”

What’s the craic? Careful with that Ax Sharma—NPM nukes NodeJS malware opening Windows, Linux reverse shells:

NPM has removed [four] packages hosted on its repository this week that established connection to remote servers and exfiltrated user data. [The] packages had collected over 1,000 total downloads over the course of the last few months.

plutov-slack-client, nodetest1010, and nodetest199 share identical code. The simplistic code … is capable of running on both Windows and Unix-based systems. After the packages are installed, the code establishes a reverse shell to the attacker's server, allowing the attacker to obtain remote access to the compromised machine.

npmpubman has a very different code structure and purpose. It collects user data from the environment variables and uploads this information. [It] could be used as a part of an attacker's reconnaissance efforts to collect information about a system, whereas the other packages establish a direct connection.

Cases of malware infiltrating the open-source ecosystem have been on the rise. … By exploiting the trust within the open-source community, attackers benefit from pushing their malicious code "downstream" to any developer or customer who may mistakenly include these malicious packages as a dependency in their application.

And Catalin Cimpanu says npm has history—npm packages found opening shells:

Npm's security staff regularly scans its collection of JavaScript libraries, considered the largest package repository for any programming language. … While malicious packages are removed on a regular basis, this week's enforcement is the third major crackdown in the last three months.

In August, npm staff removed a malicious JavaScript library designed to steal sensitive files from an infected users' browser and Discord application. In September, npm staff removed four JavaScript libraries for collecting user details and uploading the stolen data to a public GitHub page.

What have the npm gnomes to say for themselves? Severity Critical—Malicious Package:

Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer.

As full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

At which, bill_mcgonigle waxes excoriating:

Hey, npm, nobody is installing those manually. The responsible thing to do is work your logs and build the reverse dependency graph of what was including them. Admins can act on that and CVE can do its thing.

What's never going to happen is that every time npm discovers a problem, every admin everywhere who has some dev who's touched npm is going to scour their systems.

So don’t install random dep libs in the first place? u/IdiotCharizard doubts that’ll work:

You're probably not going to see any worthwhile software written without the use of other libraries. … And each dependency you have has a bunch of subdependencies, and so on. It's really hard to be 100% on top of.

Take a look at any interactive webapp you'd consider quality. Extra points for open source ones. They all use a ton of libraries because they don't want to reinvent the wheel

Pretty much everyone knows exactly what their direct dependencies are, and how safe they are. Most also have a vague idea at least about the major subdependencies those have. The problem comes from subsubdeps and subsubsubdeps, and so on.

Modern web stack makes it almost impossible to not end up downloading random packages you can't trust. … Your best bet is to do daily audits of your shrinkwrap for known malicious libraries like these … but that's an enormous time investment.

But intrabusinfoe throws out baby+bathwater:

I know enough to understand that I will not be using npm for any development efforts. This is scary and confirms my suspicions on the security of open source repositories.

How do I quickly check that I’m not using one of the malicious packages? Explain like we’re 15, u/eritbh:

You can use npm ls packagename in a project to see if packagename is installed in a project, and if it is, show a tree describing what other packages are requiring it. If it's there, then you need to remove dependence on packages (or package versions) that create that dependency.

You can pin a package's version to a version from before the vulnerable dependency was introduced if you need to. You'll also probably want to delete and regenerate your lockfile, assuming it's version controlled.

Alternatively, luntrus is lost in translation:

Scan with Retire.JS or with SNYK. … Make it visible at

But, c’mon. The big, trusted packages aren’t going to be dependent on any of these garbage libraries, right? Wrong, says u/0xc0ba17:

As an attacker, you just need to somehow gain access (through social engineering or hacking) to a small package deeply nested in the dependencies tree, compromise it, and now your malicious code is bundled with Webpack or Angular.

The moral of the story?

Code reuse is a wonderful thing. But only if you trust all the code you’re reusing.

And finally

What’s this lurking in my refrigerator?

Hat tip: Xeni Jardin

Previously in “And finally”

You have been reading Security Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or Ask your doctor before reading. Your mileage may vary. E&OE. 30.

This week’s zomgsauce: David Everett Strickler (via Unsplash)

Keep learning

Read more articles about: SecurityInformation Security