Transmissões do Node.js: os engenheiros do Google encontraram uma vulnerabilidade nos scripts do NPM

Desenvolvedores do Node.js., execute o comando `npm install` por seu próprio risco e lembre-se de que o worm de propagação automática percorre livremente o ecossistema.

Você nunca pode assumir que um arquivo baixado da Internet é seguro. Isso vale para o NPM, o gerenciador de pacotes padrão do Node.js. A vulnerabilidade na instalação de scripts permite que um invasor crie um worm de propagação automática que pode passar pelos pacotes NPM.


"Isso é possível devido ao fato de que um pacote NPM pode facilmente passar a maior parte do ecossistema por si mesmo", escreve o desenvolvedor do Google Sam Sakoni em seu artigo "expondo a NPM Hydra".

Como em outros gerenciadores de pacotes, o NPM suporta scripts de "ciclo de vida" que podem ser executados por comandos externos no sistema como o usuário atual. Embora esses scripts sejam frequentemente úteis e usados ​​para limpar arquivos após o processo de instalação, compilando módulos binários e criando automaticamente arquivos de configuração, eles podem ser perigosos ao mesmo tempo, pois podem fazer alterações no sistema ao executar vários comandos.
“Talvez os pacotes NPM escritos com intenção maliciosa, durante a instalação, executem scripts incorporados em outros pacotes, que por sua vez são publicados no registro, e outros pacotes criados pelo usuário”, escreveu o artigo no blog oficial do NPM. No entanto, a empresa relata que os benefícios do uso desses scripts superam os riscos de uma ameaça em potencial.

A publicação minimiza o risco e chama a atenção para os pacotes "limpos desde o início", mas nem todos têm "cem por cento" de certeza disso. O artigo de Sakoni, com exceção de algumas soluções alternativas, não deixa claro como ter certeza de que os pacotes que os usuários instalam não serão o que eles esperavam.

"O NPM não pode garantir que o registro de pacotes seja seguro", observa o artigo.

Worm escoa através de dependências de pacotes

O worm tira proveito de três recursos do NPM: versão semântica (semver), publicação em um registro centralizado e privilégios para um usuário que efetua login automaticamente. Porque o usuário permanece autorizado até efetuar login manualmente. Quem faz login e executa a instalação permite que outros módulos executem uma ampla variedade de comandos. Desde que não haja ligação a versões específicas, os pacotes podem ser atualizados para novas versões e cada um deles pode executar código. E, finalmente, eles podem enviar pacotes para o servidor de registro central, de onde outros podem instalá-los.

O ataque de vermes depende da engenharia social para a infecção inicial e as mencionadas "melhorias" podem se mover livremente pelo ecossistema.

Primeiro, o invasor engana o proprietário do pacote NPM para instalar o pacote infectado em seu sistema. Pode ser phishing ou qualquer outro ataque semelhante. Uma vez instalado, ele cria uma versão “trojan” do pacote do proprietário do módulo NPM e define um gancho para iniciar o worm onde quer que esteja instalado. O módulo modificado publicado na conta do proprietário se torna o ponto de partida para a infecção de todos os seus pacotes, iniciando o módulo Trojan como uma dependência. O worm cria novas versões de módulos na conta com o comentário "bugfix" e agora, quando instalado, o código de propagação automática pode ser executado.

Por um exemplo. O Phonegap possui 463 dependências intermediárias. E 276 contas NPM individuais podem atualizar versões de seus pacotes. Agora, apenas uma pessoa dessas 276 é suficiente para o worm continuar infectando todos os que instalaram o pacote do projeto PhoneGap, diz Sakoni.

O NPM nega riscos

Embora o buraco não tenha sido fechado, uma observação sobre a vulnerabilidade da Equipe de prontidão para emergências de computadores dos Estados Unidos destaca várias soluções para contornar o perigo. Eles usam a opção “-ignore-scripts” quando instalam novas dependências, fecham versões com o `npm-shrinkwrap` e incentivam os usuários cujos módulos são constantemente desvinculados do NPM.

As organizações que usam o NPM em seus ambientes devem executar um espelho de registro local do NPM e impedir que usuários individuais instalem dependências diretamente do registro principal. Eles devem verificar regularmente o registro local e garantir que arquivos maliciosos não estejam na lista de dependências.

Sakoni recomendou definir o tempo de validade dos tokens e forçar os usuários a sair do NPM após um certo período de tempo. Em um post no blog, a empresa não descreveu essas recomendações, mas anunciou outras soluções para minimizar os riscos.

Uma idéia é complicar a publicação de módulos; se o usuário não estiver ciente do perigo, isso pode ser uma autenticação de dois fatores. Você ainda pode trabalhar com empresas que fornecem proteção, oferecendo ao último a verificação dos módulos, mas até agora isso não é possível. No momento, a empresa monitora pacotes atualizados com freqüência, uma vez que o worm pode ser detectado por lançamentos muito frequentes de novas versões, mas depende mais de usuários que notificarão pacotes suspeitos.

"Sem dúvida, se muitos usuários tentarem publicar massivamente pacotes maliciosos em conjunto, eles estarão disponíveis no registro do NPM", disse o blog.

Confie, mas verifique

Serão alguns dias difíceis para o NPM. Identificar pacotes publicados maliciosos é o seu "calcanhar de Aquiles". No debate atual sobre o tema da regulamentação pelo gerente de pacotes removidos do registro. Remoção pelo desenvolvedor de um pacote do NPM na semana passada, interrompendo muitos projetos que dependem dele. Também é bastante simples registrar seu código com o nome do módulo remoto. Qualquer pessoa que tenha atribuído o nome de outra pessoa pode definir o código para qualquer usuário, o que depende do original.

Nos últimos dias, o Reddit e o GitHub discutiram muito sobre a confiança nos desenvolvedores, o suporte dos pacotes que eles criaram e se eles começarão a criar código malicioso. No ecossistema global, essa é uma suposição perigosa, porque se um desses desenvolvedores quiser quebrar muito código, ele terá que enfrentar toda a comunidade. No entanto, deve haver maneiras de instalar os módulos com segurança, pode ser uma assinatura digital ou outros métodos de verificação do código quanto à segurança e correção. Enquanto isso, resta apenas sentir o alarme toda vez que você executa o comando `npm install`.

Artigo original: www.infoworld.com/article/3048526/security/nodejs-alert-google-engineer-finds-flaw-in-npm-scripts.html

Source: https://habr.com/ru/post/pt392409/