Un mainteneur suspect dévoile les fils d'une attaque de la chaîne d'approvisionnement npm

Cette histoire commence lorsque Sébastien Lorber, responsable de Docusaurus, le projet de documentation open source basé sur React, remarque une modification de Pull Request dans le manifeste du package. Voici le changement proposé au populaire package cliui npm :

Plus précisément, attirant notre attention sur le changement de dépendances npm qui utilisent une syntaxe inconnue :

  "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"

La plupart des développeurs s'attendraient à voir une plage de versions semver dans la valeur d'un package ou peut-être une URL Git ou basée sur un fichier. Cependant, dans ce cas, il existe une syntaxe spéciale npm: prefix. Qu'est-ce que cela signifie ?

Ainsi, dans le cas du changement proposé dans cette pull request, le package string-width-cjs sera résolu en package string-width dans les versions ^4.2.0. Cela signifie qu'il y aura une entrée de répertoire node_modules pour string-width-cjs mais avec le contenu de string-width@^4.2.0 et un comportement similaire dans le fichier de verrouillage (package-lock.json).

L'alias de package est une fonctionnalité du gestionnaire de packages npm et pourrait légitimement être utilisé dans des cas tels que ceux indiqués ici (pour faciliter la prise en charge d'ESM vs CJS).

Cela dit, l'alias de package peut être abusé. Dans un article et une divulgation de sécurité remontant à 2021, Nishant Jain, un ambassadeur de Snyk, a démontré comment le registre officiel npmjs pouvait être trompé en désinformant les informations de dépendance basées sur l'alias de package dans le cadre d'une confusion de dépendances et d'un problème de sécurité de la chaîne d'approvisionnement.

Cette pull request est en effet bénigne et il n’y a aucun risque d’attaque de la chaîne d’approvisionnement. Cependant, Sébastien se méfiait de ces noms de paquets et a découvert qu'il y avait bien plus de raisons de s'inquiéter.

Trouver un comportement suspect dans les fichiers de verrouillage npm concernant les modules malveillants

Lorsque Sébastien a examiné la pull request, il a exécuté un outil appelé lockfile-lint, qui aide à valider les fichiers de verrouillage tels que package-lock.json ou Yarn.lock pour s'assurer qu'ils n'ont pas été falsifiés pour injecter des packages malveillants au lieu de le package npm d'origine.

L'exécution de l'outil a affiché les avertissements suivants :

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!

Avertissement : lockfile-lint est un outil que j'ai développé en 2019 suite à ma publication qui révélait le problème de sécurité avec les fichiers de verrouillage : pourquoi les fichiers de verrouillage npm peuvent être un angle mort de sécurité pour l'injection de modules malveillants.

Alerte élevée : sosies de packages populaires sur npm

Compte tenu des résultats lockfile-lint ci-dessus, Sébastien a recherché ces noms de packages sur npm et a découvert avec surprise qu'ils existent dans le registre public npm :

• 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 a noté que non seulement ces noms de packages existent sur npm, mais qu'ils comportent des indicateurs qui suscitent des inquiétudes :

• Ces packages ne sont liés à aucun référentiel de code source public
• S'ils sont inspectés pour leur contenu, ces paquets sont vides de tout code réel.
• L'identité de l'auteur qui a publié ces packages est anonyme et n'est associée à aucune information personnelle ou identifiable.

En regardant le package npm strip-ansi-cjs, il n'y a pas de README ni de référentiel de code source associé au package, mais il existe de nombreux packages légitimes et populaires citant le même comportement.

En fait, pour ce package particulier, il existe des signaux de popularité sous la forme de nombreuses dépendances (d'autres packages qui dépendent de celui-ci) - 529 dépendances pour être exact, et aussi un nombre croissant de téléchargements hebdomadaires, totalisant 7 274 à au moment de la rédaction.

En regardant le code de strip-ansi-cjs, il montre qu'il n'y a qu'un seul fichier dans ce package, le fichier manifest package.json.

Alors, pourquoi un package qui ne fait rien obtient-il autant de téléchargements, et pourquoi tant d'autres packages en dépendent-ils ?

Continuons à inspecter l'auteur de ces packages npm.

Les trois packages appartiennent à himanshutester002, et leurs packages ont tous été publiés l'année dernière avec des numéros de version programmatiques. Certains sont intéressants à dénoncer :

• 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:

• Les packages React Native semblent être dérivés de l'outil d'échafaudage create-react-native-library qui présente également l'exemple de fonction de multiplication par défaut dans le cadre du code source stock généré pour un nouveau projet.
• Les packages ont des structures et des dépendances de répertoires et de fichiers qui pourraient être dérivées du modèle de démarrage Next.js 14, telles que celles créées avec npx create-next-app@14.

Nos pairs de Sonatype ont déjà identifié des cas similaires d'inondation de registres open source avec des packages. Dans ces cas, l'objectif ultime était que les développeurs se récompensent avec des jetons Tea, qui est une plateforme Web3 permettant de monétiser des logiciels open source.

La recherche de fichiers tea.yaml dans les packages mentionnés confirme en outre la thèse selon laquelle une partie du but de cette campagne est d'exploiter des jetons Tea grâce à une utilisation abusive de Tea.

Plus tôt cette année, le 14 avril 2024, un utilisateur du forum Tea a publié un commentaire qui conforte davantage les inquiétudes concernant l'abus de thé :

Avant de formuler des réflexions finales, je voudrais sincèrement remercier Sébastien Lorber pour son état d'esprit prudent en tant que responsable et pour avoir aidé à dévoiler ces fils de discussion sur une potentielle attaque de chaîne d'approvisionnement npm.

Que se passe-t-il avec string-width-cjs ?

À ce stade, je suis convaincu que je peux continuer à percer des trous dans le reste des packages qui sont censés dépendre de string-width-cjs pour trouver des indicateurs très douteux de légitimité authentique.

Je suppose que tous ces packages dépendants et ces augmentations de téléchargement ont pour seul objectif de créer une fausse légitimité pour les packages 3 *-cjs afin qu'en temps voulu, avec la bonne victime en jeu, ces faux packages être installé puis suivre avec une nouvelle version malveillante.

Pour vous aider à rester en sécurité lorsque vous travaillez avec des logiciels open source, je vous recommande fortement d'adopter des pratiques de sécurité et en particulier ces ressources pédagogiques de suivi :

• Pourquoi les fichiers de verrouillage NPM peuvent être un angle mort de sécurité pour l'injection de modules malveillants
• 10 bonnes pratiques de sécurité npm
• Sécurité NPM : prévenir les attaques de la chaîne d'approvisionnement

Avons-nous détecté une campagne de sécurité de la chaîne d'approvisionnement au milieu de leurs actes déloyaux, ou s'agit-il uniquement de piste d'argent et, en tant que tel, peut être attribué au spam et à l'abus de registres publics comme npm et GitHub pour extraire des jetons de thé ?

Quelle que soit l'évolution de la situation, restez vigilant.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!