Suspicious Maintainer Unveils Threads of npm Supply Chain Attack

This story starts when Sébastien Lorber, maintainer of Docusaurus, the React-based open-source documentation project, notices a Pull Request change to the package manifest. Here’s the change proposed to the popular cliui npm package:

Specifically, drawing our attention to the npm dependencies change that use an unfamiliar syntax:

  "dependencies": {
    "string-width": "^5.1.2",
    "string-width-cjs": "npm:string-width@^4.2.0",
    "strip-ansi": "^7.0.1",
    "strip-ansi-cjs": "npm:strip-ansi@^6.0.1",
    "wrap-ansi": "^8.1.0",
    "wrap-ansi-cjs": "npm:wrap-ansi@^7.0.0"

Most developers would expect to see a semver version range in the value of a package or perhaps a Git or file-based URL. However, in this case, there’s a special npm: prefix syntax. What does it mean?

So, in the case of the change proposed in this pull request, the package string-width-cjs will resolve to the package string-width in versions ^4.2.0. This means there will be a node_modules directory entry for string-width-cjs but with the contents of string-width@^4.2.0 and similar behavior in the lockfile (package-lock.json).

Package aliasing is an npm package manager feature and could legitimately be used for such cases as hinted here (to help with ESM vs CJS support).

With that said, package aliasing can be abused. In an article and security disclosure dating back to 2021, Nishant Jain, a Snyk Ambassador, demonstrated how the official npmjs registry could be fooled to misinform dependency information based on package aliasing as part of a dependency confusion and supply chain security concern.

This pull request is indeed benign, and there’s no risk of a supply chain attack. However, Sébastien was suspicious of such package names and found out that there was more to be worried about.

Finding suspicious behavior in npm lockfiles concerning malicious modules

When Sébastien examined the pull request, he ran a tool called lockfile-lint, which helps in validating lockfiles such as package-lock.json or yarn.lock to ensure that they weren’t tampered with to inject malicious packages instead of the original npm package.

Running the tool showed the following warnings:

npx lockfile-lint --path package-lock.json --allowed-hosts yarn npm --validate-https --validate-package-names

detected resolved URL for package with a different name: string-width-cjs
    expected: string-width-cjs
    actual: string-width

detected resolved URL for package with a different name: strip-ansi-cjs
    expected: strip-ansi-cjs
    actual: strip-ansi

detected resolved URL for package with a different name: wrap-ansi-cjs
    expected: wrap-ansi-cjs
    actual: wrap-ansi

 ✖ Error: security issues detected!

Disclaimer: lockfile-lint is a tool that I developed in 2019 following my publication that disclosed the security concern with lockfiles: why npm lockfiles can be a security blindspot for injecting malicious modules.

High-alert: popular packages look-alikes on npm

Given the above lockfile-lint results, Sébastien looked up these package names on npm and surprisingly found that these do exist on the public npm registry:

• https://www.npmjs.com/package/string-width-cjs

• https://www.npmjs.com/package/strip-ansi-cjs

• https://www.npmjs.com/package/wrap-ansi-cjs

Sébastien noted that not only do these package names exist on npm, but they have indicators that raise concerns:

• These packages aren’t tied to any public source code repository

• If inspected for their contents, these packages are empty of any actual code.

• The author's identity who published these packages is anonymous and isn’t associated with any personal or identifiable information.

Looking at the npm package strip-ansi-cjs, there’s no README and no source code repository associated with the package but there are many legitimate and popular packages citing the same behavior.

In fact, for this particular package, there are signals of popularity in the form of many dependents (other packages that depend on this one) - 529 dependents to be exact, and also a growing number of weekly downloads, totaling 7,274 at the time of writing.

Looking at the code for strip-ansi-cjs it shows that there’s only a single file in this package, the package manifest package.json file.

So, why does a package that doesn’t do anything get so many downloads, and why do so many other packages depend on it?

Let’s continue to inspect the author of these npm packages.

All three packages are owned by himanshutester002, and their packages were all published last year with programmatic version numbers. Some are interesting to call out:

• isaacs-cliui npm package - potentially a typosquatting attempt on Isaac’s own fork of the cliui project and the legitimate npm package under their namespace: @isaacs/cliui.

• azure-sdk-for-net npm package - potentially an attempt at dependency confusion campaign to attack private packages of the same name.

• link-deep npm package - squatting on a popular capability related to utility packages such as lodash and others

You can also note that the user himanshutester002 has no identifiable information on this user profile page on npmjs.

We previously noted that the strip-ansi-cjs npm package has over 500 other packages that use it, therefore, potentially a positive indicator for popularity. Let’s look at them:

If you give it a glance, this might transfer some sort of legitimacy with this list, but is it?
For example, names like clazz-transformer or react-native-multiply or maybe gh-monoproject-cli seem legitimate, but are they?

Here is the react-native-multiply npm package page:

This package has virtually no downloads and its author is also an anonymous npm user with no identifiable information. The source URL repository this package redirects to is https://github[.]com/hasandader/react-native-multiply which doesn’t exist and the GitHub user profile looks very suspicious and lacks practical activity.

The npm package contents might seem like there’s some actual source code in there, but in reality, it looks like a generated code sample for a “hello world” application prototype.

You also have to wonder, if this package is just a multiplication library, then why does it need 776 dependencies to do the following:

import { multiply } from 'react-native-multiply';
const result = await multiply(3, 7);

While some may mock JavaScript for its abuse of dependencies, contributing to an astronomical tree of nested packages, it doesn’t make any sense for a project to declare 776 direct (top-level) dependencies.

Among all of these dependencies, are the 3 suspicious npm packages that our story began with: string-width-cjs, strip-ansi-cjs, and wrap-ansi-cjs:

We mentioned that one of the strip-ansi-cjs dependencies was named clazz-transformer. Let’s look at it:

Let’s explain what is happening here:

• The npm package name is clazz-transformer, yet the package has a title of class-transformer at the top of the README’s package page here which was purposely done.

• Similarly, the source code repository is https://github[.]com/typestack/class-transformer which might be a legitimate repository or a fake one, but it is not associating itself at all with the wording “clazz”.

The associated repository’s typstack/class-transformer on GitHub has the package.json file as  follows:

Looking at the package.json file on GitHub shows no declaration of dependencies, yet if we inspect the source code of the actual package on npmjs we see the 437 dependencies that this clazz-transformer is packaged with. Again, very conveniently bundling the 3 suspicious *-cjs packages:

Further thoughts on suspicious npm package findings

Before we draw further conclusions, it is important to mention a few of the traits of the npm packages we observed above:

• The React Native packages seem to be derived from the create-react-native-library scaffold tool which also features the default multiply function example as part of the stock source code generated for a new project.

• Packages have directory and file structures and dependencies that could be derived from Next.js 14 starter boilerplate, such as those created with npx create-next-app@14.

Our peers at Sonatype have previously identified similar cases of flooding open-source registries with packages. In these cases, the ultimate goal was for developers to reward themselves with Tea tokens, which is a Web3 platform for monetizing open-source software.

Finding some tea.yaml files in the mentioned packages further supports the thesis that part of this campaign’s purpose is to mine Tea tokens through the misuse of Tea.

Earlier this year, on April 14th, 2024, a Tea forum user posted a comment that further supports the concern of tea abuse:

Before reaching out with concluding thoughts, I would like to sincerely thank Sébastien Lorber for his cautious maintainer mindset and for helping unveil these threads of a potential npm supply chain attack.

What is going on with string-width-cjs?

At this point, I have high confidence that I can continue poking holes in the rest of the packages that are supposedly dependent on string-width-cjs to find very dubious indicators of authentic legitimacy.

It is my assumption that all of these dependent packages and download boosts are leading to the sole purpose of creating false legitimacy for the 3 *-cjs packages so that in due time, with the proper victim at play, these fake packages will be installed and then follow with a new malicious version.

To help you stay secure while working with open-source software, I highly recommend adopting security practices and specifically these follow-up educational resources:

• Why npm lockfiles can be a security blindspot for injecting malicious modules

• 10 npm Security Best Practices

• NPM security: preventing supply chain attacks

Did we catch a supply chain security campaign amid their foul-play, or is this all about the money trail and as such can be attributed to spam and abuse of public registries like npm and GitHub to mine for Tea tokens?

However this unfolds, stay vigilant.