In recent months, there have been a number of high-profile supply-chain attacks on the npm package repository and some key packages.
To make it easier to see whether you are impacted by such a compromise, I've created a quick tool that lets you check whether you have a compromised package installed and what it belongs to.
Actual checks for whether you have been infected (just because you have a compromised version, it does not necessarily mean you've actually run the compromised code in the package) are beyond the scope of a simple checker I'm afraid and you will need to review the information about the attack to know what, if anything, you need to do.
The tool is published here: https://www.npmjs.com/package/npm-supply-chain-check
You should, of course, do a quick check of the code before running it to make sure you are happy. Note though, that I've locked down the package and its source GitHub to prevent unwanted changes. In addition, the package has no external dependencies at all.
You don't need to install it, you can run it with npx instead if you prefer:
Here is an example of checking against the latest attack:
cd ~/.node-red
npx npm-supply-chain-check axios
npx npm-supply-chain-check axios global
Note that you should check both the local and global locations.
Yes, this isn't meant to be a comprehensive security tool but rather something that anyone can use, regardless of experience, to do a quick check to see if they may have a problem that should be followed up.
According to the write up, the attack actually cleans up the package.json files leaving the RAT behind. If I understand correctly. So running this script might well give one a false sense of security because the indicators the script checks for have already been cleaned away, leaving the executable behind.
No, I don't think so, it uses npm ls to do the checks which will, I believe, check down the tree regardless of the package.json. The package.json is only used to identify root folders to check (folder contains package.json). Correct me if I'm wrong.
Another reason for using Sentinel's custom package installer. It wont run package scripts unless an Admin confirms he wants to proceed. In the warning message it will ask people to verify the changes and confirm.
Additionally, packages are going to be setup and analyzed in a ephemeral docker container before being added to the node_modules nodered sees. This way the attack surface caused by these scripts, if they are accidentally run, will be limited to the container.
Minor question, does this work on environments without docker, e.g. raspberries? Also how does this work if NR is run inside a docker container? Docker within docker is possible but needs extra configuration step.
Just to note that the check does not appear to follow modules installed in local files. I have a locally built version of @flowfuse/node-red-dashboard, so in package.json I see "@flowfuse/node-red-dashboard": "file:../nodes/node-red-dashboard",
It does (partially) follow local file installs. On my dev instance, I have a local development version of uibuilder installed. Searching for "express", I get these results (NB: the package.json in my userDir folder has a name of node-red-userDir)
*** FOUND: 3 installed instances of "express" ***
Installed version : 5.2.1
Location : nested — node_modules/@modelcontextprotocol/sdk/node_modules/express
Depended on by :
• @modelcontextprotocol/sdk
Installed version : 4.22.1
Location : top-level (hoisted)
Depended on by :
• ../../node-red-contrib-uibuilder
• @flowfuse/node-red-dashboard
• express-rate-limit
Installed version : 4.22.1
Location : nested — node_modules/node-red-contrib-web-worldmap/node_modules/express
Depended on by :
• node-red-contrib-web-worldmap
Which does indeed include the version in the local uibuilder install.
However, as you point out, if the top-level lock file doesn't include the searched for package AND it isn't used anywhere else, then it doesn't find it, as in this example searching for jsdom:
Checking node-red-userdir ... not found
──────────────────────────────────────────────────────────────────────
Project : node-red-userdir
Rel path: .
Path : D:\src\nr\data
──────────────────────────────────────────────────────────────────────
(not found — "jsdom" is not in this project's lock file)
I won't be able to make it work with DinD setups because it adds a new set of threats and complexity that will make the security guards via filesystem way more fragile.
