Suspicious Maintainer Unveils Threads of npm Supply Chain Attack
Tags: engineering, vulnerabilityinsights, javascript, node
Published: 2024-07-17 02:00:26

This story starts when [Sébastien Lorber](https://x.com/sebastienlorber), 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](https://github.com/yargs/cliui?tab=readme-ov-file) npm package:


![](https://res.cloudinary.com/snyk/image/upload/v1721139020/blog-supply-chain-attack-12.png)
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](/blog/exploring-extensions-of-dependency-confusion-attacks-via-npm-package-aliasing/) 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](/advisor/npm-package/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*](https://snyk.io/blog/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/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.


![](https://res.cloudinary.com/snyk/image/upload/v1721139020/blog-supply-chain-attack-11.png)
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?


![](https://res.cloudinary.com/snyk/image/upload/v1721139020/blog-supply-chain-attack-2.png)

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](https://www.npmjs.com/package/@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


![](https://res.cloudinary.com/snyk/image/upload/v1721139020/blog-supply-chain-attack-3.png)
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:


![](https://res.cloudinary.com/snyk/image/upload/v1721139020/blog-supply-chain-attack-1.png)
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:


![](https://res.cloudinary.com/snyk/image/upload/v1721139020/blog-supply-chain-attack-4.png)
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.


![](https://res.cloudinary.com/snyk/image/upload/v1721139020/blog-supply-chain-attack-7.png)
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`:


![](https://res.cloudinary.com/snyk/image/upload/v1721139020/blog-supply-chain-attack-8.png)
We mentioned that one of the `strip-ansi-cjs` dependencies was named `clazz-transformer`. Let’s look at it:


![](https://res.cloudinary.com/snyk/image/upload/v1721139021/blog-supply-chain-attack-5.png)
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:


![](https://res.cloudinary.com/snyk/image/upload/v1721139020/blog-supply-chain-attack-10.png)
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:


![](https://res.cloudinary.com/snyk/image/upload/v1721139020/blog-supply-chain-attack-6.png)
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](https://tea.xyz/) 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](https://forum.tea.xyz/t/most-of-the-projects-are-useless-spam/12684) that further supports the concern of tea abuse:


![](https://res.cloudinary.com/snyk/image/upload/v1721139020/blog-supply-chain-attack-9.png)
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](https://snyk.io/blog/why-npm-lockfiles-can-be-a-security-blindspot-for-injecting-malicious-modules/)
* [10 npm Security Best Practices](https://snyk.io/blog/ten-npm-security-best-practices/)
* [NPM security: preventing supply chain attacks](https://snyk.io/blog/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.