Software Supply Chain Redux: npmjs shells your hosts

In supply chain security risk in action: ESLint I showed how good packages could become bad, and get imported directly into your network, your workstation, your delivered software. In that case it was eslint, today it is four less well known packages.

The four packages are:

1. plutov-slack-client – claims to be a “Node.JS Slack Client” according to the information in the manifest 
2. nodetest199 – no description
3. nodetest1010 – no description
4. npmpubman – claims to be “a simple implementation about Linux shell login” according to the information in the manifest 

Now, its somewhat unlikely that you have added these to your project. However, more likely, some package you rely on was modified to import these.

Today NPM has removed these packages, but, they’ve been around for a while. The iceberg theory suggests that, the 4 we know of, implies more are out there.

The risk of importing bad software is expensive and complex to mitigate. The simple cheap things to do include SAST (we run npm audit in our CI as a voting stage, documented here), east-west and egress firewalls. Here, which terrifies you most:

1. a reverse shell open on a developer workstation? (they have your source, maybe it commits something bad, steals it, …)
2. a reverse shell open in your CI (you are building and signing the code here)
3. a reverse shell open in your production (you are processing customer credit cards and home addresses)

I didn’t put a 4) all of the above, but you can feel free to add it in your mind.

The simplicity of these attacks coupled with the go-go-go development cadence of today suggests we are going to see much more of them. Diligence, inspection, technology: we’ll all need to be alert.

As for the specific malware just released, well we can read the CVE which has some modest detail:

All versions of plutov-slack-client contain malicious code. Upon installation the package opens a shell to a remote server. The package affects both Windows and *nix systems.

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.
The package should be removed, but 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.
https://www.npmjs.com/advisories/1569

And, the last bit is something we tend to forget. If this got in, it for sure did a lot of damage. Signing keys for your application? Credentials for your GCP or AWS? Service accounts? As a good proxy, assume that the developer workstation it was on, that the person who uses that has become actively malicious: if they had access, the attacker has access.

Think this would never happen to you? You would never have a developer load ‘plutov-slack-client’? What about loadyaml ? Seems much more innocuous. Or, lodashs , a simple typo-squat. Would you catch that in all design reviews? What about if you are an end-user of software. Do you feel that all developers in all the companies all the way back up your supply chain are diligent enough?