O que é typosquatting e como esses ataques levam à publicação de módulos maliciosos no npm

Você talvez já tenha ouvido falar de pacotes maliciosos em diferentes contextos, como um contêiner Docker malicioso ou um pacote de código aberto malicioso em um registro público de algum ecossistema. A Snyk também publicou uma pesquisa abrangente sobre malware em aplicativos móveis, chamado SourMint.

Já analisamos alguns desses incidentes de segurança, que abrangem mais de um ecossistema:

• Ataques de typosquatting no registro PyPI do Python

• O conhecido incidente do event-stream, envolvendo uma versão maliciosa publicada no ecossistema JavaScript do npm

• Execução remota de código malicioso nos populares projetos de gems do Ruby bootstrap-sass e strong_password

No entanto, os pacotes maliciosos não são todos iguais. Em relação aos registros dos ecossistemas, podemos classificá-los, de modo geral, em uma destas categorias:

• Ataques de typosquatting — agentes mal-intencionados publicam pacotes maliciosos em um registro na esperança de enganar usuários e fazê-los instalá-los. Já vimos esse tipo de pacote nos registros do PyPI e do Node.js. O caso mais notável foi o crossenv. Com um nome parecido com o do popular pacote cross-env, ele replicava a mesma funcionalidade, mas também capturava variáveis de ambiente e as enviava para um servidor remoto controlado por um invasor.

• Contas comprometidas — quem mantém projetos de código aberto não necessariamente tem mais conhecimento de segurança do que outros desenvolvedores. Isso pode levar a práticas inseguras e descuidadas no tratamento de segredos relacionados às permissões de publicação. A situação fica ainda mais complexa quando um projeto tem vários mantenedores e é preciso aplicar as políticas a todos. Contas também podem ser comprometidas devido à falta de controles adequados de autenticação em alguns registros. Ainda assim, contas comprometidas podem resultar em graves incidentes de segurança, devido à grande popularidade potencial dos projetos mantidos por essas contas e ao impacto imediato no ecossistema.

• Engenharia social em vez de analisar o grafo de dependências — a comunidade de código aberto valoriza e acolhe a colaboração. No entanto, enquanto uma linha de código maliciosa em um pull request provavelmente chamaria a atenção de muita gente rapidamente, a situação é diferente quando essa linha é adicionada a uma dependência do projeto.

Ataques de typosquatting

Entre os tipos de pacotes e versões maliciosos publicados em repositórios mencionados acima, o typosquatting é um dos mais comuns. Isso acontece porque a barreira de entrada para os invasores é muito baixa e há poucas medidas para combatê-lo.

O que são ataques de typosquatting?

Ataques de typosquatting acontecem quando agentes mal-intencionados publicam pacotes maliciosos em um registro na esperança de enganar usuários e fazê-los instalá-los. Registros públicos de software, como npm e PyPI, são exemplos de ecossistemas em que já presenciamos esse tipo de tentativa.

Isso é muito parecido com ataques de phishing em sites, que exploram erros de digitação de pessoas que podem inserir um endereço incorreto por acidente. Por exemplo, digitar https://bankofamerca.com em vez de https://bankofamerica.com. Se o domínio incorreto estivesse sob o controle de um invasor, ele poderia criar um site falso que imitasse o verdadeiro e roubar informações financeiras confidenciais, como credenciais e dados bancários.

Exemplos de módulos maliciosos de typosquatting encontrados no banco de vulnerabilidades da Snyk, com registros que remontam a 2017:

E se você acha que o typosquatting acabou em 2020, pense de novo:

A história do crossenv

Um caso particularmente notável de ataque de typosquatting é o crossenv. O invasor usou um nome parecido com o do popular pacote cross-env e até replicou exatamente a funcionalidade do módulo original para fazer parecer que ele funcionava como esperado. Na prática, porém, também capturava variáveis de ambiente e as enviava para um servidor remoto controlado por um invasor.

Em 19 de julho, o usuário do npm hacktask publicou o crossenv como um dos mais de 30 pacotes maliciosos usados para roubar variáveis de ambiente de vítimas enganadas a instalá-los.

Como C J Silverio compartilhou em seu blog, confira a lista completa de pacotes e o total de downloads que cada um teve enquanto esteve disponível no registro público do npm:

babelcli: 42
cross-env.js: 43
crossenv: 679
d3.js: 72
fabric-js: 46
ffmepg: 44
gruntcli: 67
http-proxy.js: 41
jquery.js: 136
jquery.js: 136
mariadb: 92
mongose: 196
mssql-node: 46
mssql.js: 48
mysqljs: 77
node-fabric: 87
node-opencv: 94
node-opensl: 40
node-openssl: 29
node-sqlite: 61
node-tkinter: 39
nodecaffe: 40
nodefabric: 44
nodeffmpeg: 39
nodemailer-js: 40
nodemailer.js: 39
nodemssql: 44
noderequest: 40
nodesass: 66
nodesqlite: 45
opencv.js: 40
openssl.js: 43
proxy.js: 43
shadowsock: 40
smb: 40
sqlite.js: 48
sqliter: 45
sqlserver: 50
tkinter: 45

Como é um pacote malicioso como o crossenv?

Para analisar o caso do pacote malicioso crossenv, vamos começar pelo arquivo package.json:

Ao analisar o arquivo package.json, vale observar alguns pontos suspeitos:

• Linha 2: o nome do pacote está claramente incorreto, mas vamos supor que isso tenha passado despercebido.

• Linha 13: inclui o pacote cross-env legítimo, que, como você pode ver, também tem uma versão diferente (5.0.1) da versão do próprio módulo (6.1.1 na linha 3).

• Linha 8: aqui, o radar de suspeitas deveria apitar. O que há em package-setup.js e por que esse pacote precisa desse tipo de configuração?

Antes de nos aprofundarmos na história por trás de node package-setup.js, vamos dar um passo atrás e explicar por que essa linha é tão importante. O script de execução postinstall é um dos hooks integrados ao ciclo de vida dos pacotes do npm. Ele é executado automaticamente quando um pacote é instalado.

Qualquer comando definido em um script postinstall será executado por uma tarefa npm install, mesmo que você não tenha chamado esse script no seu próprio código.

Ato 1: o payload malicioso do pacote npm

Ao prosseguirmos com a investigação e analisarmos o conteúdo do arquivo package-setup.js, revelamos uma série de ações maliciosas:

Como esse script é executado durante parte do processo de instalação do pacote npm, ele coleta todas as variáveis de ambiente usando process.env, converte-as em um payload codificado em base64 e o envia em uma requisição HTTP POST para um servidor remoto controlado por um invasor.

A ação maliciosa acontece uma única vez, durante a instalação. Depois disso, o pacote crossenv continua oferecendo a funcionalidade para a qual foi instalado originalmente, ao encapsular o pacote cross-env legítimo. Por isso, ele pode passar despercebido.

Ato 2: vamos refletir sobre o impacto dos pacotes maliciosos

Encontrar e expor essa vulnerabilidade de segurança é importante, mas não basta. Para entender os danos que ela poderia ter causado e as consequências desse ataque, vamos refletir sobre algumas perguntas:

1. Que informações armazenamos em nossas variáveis de ambiente?

2. O que teria acontecido se um desenvolvedor tivesse mesclado isso em uma branch e executado em um servidor de CI? E se isso tivesse sido promovido para um servidor de produção?

3. Como isso afetaria você se o ataque não se limitasse a ler variáveis de ambiente e avançasse para outras ações maliciosas, como instalar backdoors, infectar ambientes com worms autorreplicantes e causar outros pesadelos?

Epílogo: como descobrimos esse pacote malicioso no npm?

Oscar Bolmsten, engenheiro de software sueco, publicou um tweet sobre uma possível atividade maliciosa no pacote crossenv. Ao que tudo indica, ninguém percebeu por duas semanas:

https://twitter.com/o\_cee/status/892306836199800836?ref\_src=twsrc%5Etfw

O que podemos fazer?

• Não armazene informações confidenciais em variáveis de ambiente.

• Conecte seu repositório à Snyk para monitorarmos diariamente as dependências do seu projeto e avisarmos se encontrarmos pacotes maliciosos ou outras vulnerabilidades. Se encontrarmos uma vulnerabilidade de segurança que possa ser corrigida, abriremos automaticamente um pull request (ou merge request) no seu repositório para resolvê-la!

• Consulte o Snyk Advisor antes de instalar pacotes para ter uma visão geral da saúde, popularidade, manutenção, segurança e outras características do pacote.

• Ao instalar pacotes, use a opção de linha de comando do npm --ignore-scripts para evitar a execução de scripts de pacotes de terceiros durante a instalação.

• Considere usar o npq para instalar pacotes com mais segurança, consultando informações sobre a saúde deles antes da instalação.

Para conhecer mais práticas recomendadas e dicas de segurança para o npm, confira o guia rápido de segurança do npm.