NPM Supply Chain Security

[shippj]

I'd like to start a discussion about how NPM sabotages and hacks pertain to Mesh Central. I know almost nothing about NPM or Node.js but I listen to the SANS Internet Stormcenter Daily Cyber Security Podcast and they are constantly talking about attacks on NPM packages, so when I noticed Mesh Central depends on NPM, it made my eyebrow raise. These sabotages can be devastating. Check out this issue - I'm assuming the maintainer deleted it from GitHub so more people wouldn't find out:
https://web.archive.org/web/20220317140201/https://github.com/RIAEvangelist/node-ipc/issues/308

I see the "colors" NPM was recently sabotaged. (just google "npm colors sabotage") and I see Mesh Central has this folder: C:\Program Files\nodejs\node_modules\npm\node_modules\colors

Is Mesh Central using the same package that got sabotaged? Were any Mesh Central servers harmed? If not, why not? Because Mesh Central's NPM packages don't auto-update? When a Mesh Central server is installed, does it download the latest NPM packages?

I see 355 folders in: C:\Program Files\nodejs\node_modules\npm\node_modules
Does that mean any of the maintainers of any of these packages can sabotage a Mesh Central server? NPM repositories also get hacked sometimes - is there any chance those hackers could gain control over a Mesh Central server that way?

p.s. Mesh Commander and Mesh Central are of the most useful programs ever created, and Ylianst and the team must be awesome. I rank Ylianst and the team way up there with Linus Torvalds and his team. I wish I could buy them all a round of beer. I noticed Ylianst and the team have implemented fantastic security in Mesh Central (like IP allowlisting and encryption in lots of places). I hope somebody here is able to show we don't have to worry about NPM attacks.

[Ylianst]

Thanks. We are no Linus, but do appreciate the p.s. note.

This is a good discussion to be had. I have a healthy concern with security at all times and familiar with the supply chain issues on NPM. This does worry me. One idea I was going to look into was to lock MeshCentral to very specific versions of modules so that even if a new module version is released, it would not be used unless verified first. This would only work for the top-level dependencies.

You can use this site or this site to visualize MeshCentral dependencies. This will only show you the minimum dependencies, if you add more features, MeshCentral will install more modules and so, obviously more dependencies will be required.

You mention "colors", I am familiar with that one and we not aware that it was in any MeshCentral sub-dependencies. Now, I need to go search for it. It's certainly not part of the minimal set.

I am open to suggestions on this topic. One option would be to bundle all known good dependencies into a "node_modules" compressed file that people could use. I need to look into a way to specify the exact versions of everything in the dependency tree. That would be ideal.

[silversword411]

Tactical RMM has a full dependency lock file, and dependencies are definitely manually migrated forward.

You can see the regular update cycle being done here:

amidaware/tacticalrmm@50cd7f2

It's still a manual process...and you're depending on the person doing version changes to check each version they're updating to.

Being a little behind on versions...and watching for news on bad NPM commits is a job unto itself.

Discussions along this line have been a frequent visitor to the "Security Now" podcast as well. Apparently Google has started a new dedicated "open source security" team, and hopefully positive things will come of it.

[shippj]

Here's another eye-opening indicator to the current state of NPM security. I heard about this from the "Security Now" podcast.

"I just noticed "foreach" on npm is controlled by a single maintainer.
I also noticed they let their domain expire, so I bought it before someone else did.
I now control "foreach" on NPM, and the 36826 projects that depend on it."

link to original post: https://twitter.com/lrvick/status/1523787247706951680

and it was also posted on slashdot

[The-Real-Admin-Guy]

While we cant accelerate production and security implementation of any third part creators we can surely anticipate them to update and patch as soon as they are aware:

I keep an eye here:
https://www.cvedetails.com/product/44073/?q=npm
and here:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=npm

My take on this is keep an eye on NPM and patch quickly...

I run this on the server site 3 times a week!
Check revisions:
node --version
npm --version

Check if the developers have a currently identify vulnerability + fix
npm update npm -g

produces this output:
removed 1 package, changed 14 packages, and audited 530 packages in 6s

16 packages are looking for funding
run npm fund for details

2 high severity vulnerabilities

To address all issues (including breaking changes), run:
npm audit fix --force

or simply:
npm audit fix

I hope this helps...