Um novo alerta de segurança está chamando a atenção da comunidade de desenvolvedores: pacotes NPM maliciosos foram descobertos se passando por bibliotecas relacionadas ao WhatsApp. O objetivo? Executar comandos destrutivos que podem apagar todos os arquivos do projeto do desenvolvedor — e até afetar o sistema operacional.
A ameaça é real e reforça a necessidade de atenção redobrada com os riscos de ataques à cadeia de suprimentos de software. Este artigo detalha o funcionamento do ataque, identifica os pacotes perigosos e oferece orientações práticas sobre como proteger seus projetos e sistemas contra esse tipo de ameaça.
A descoberta foi feita pela empresa de segurança Socket, que revelou como atacantes estão explorando a confiança da comunidade open source para infiltrar código perigoso em projetos aparentemente inofensivos. A seguir, entenda como tudo aconteceu e o que você pode fazer agora mesmo para se proteger.
O ataque em detalhes: como os pacotes enganam os desenvolvedores
A armadilha foi cuidadosamente construída para atingir desenvolvedores desatentos ou apressados. Os pacotes maliciosos simulam ser bibliotecas legítimas do WhatsApp, aproveitando-se de nomes parecidos e de uma falsa aparência de utilidade.
Os pacotes maliciosos: naya-flore e nvlore-hsc
Os pacotes maliciosos identificados foram naya-flore e nvlore-hsc, ambos publicados no repositório NPM, um dos principais gerenciadores de pacotes utilizados no ecossistema Node.js.
Apesar de serem relativamente novos, os pacotes chegaram a contabilizar dezenas de downloads antes de serem retirados do ar. Eles enganavam os usuários ao se apresentarem como interfaces não-oficiais do WhatsApp Web, com descrições vagas e promissoras para desenvolvedores que buscavam soluções rápidas para integrações com a plataforma.
No entanto, por trás da fachada, os pacotes carregavam um payload altamente destrutivo.
O payload destrutivo: o perigo do comando rm -rf *
Dentro do código do pacote, foi identificada uma função chamada requestPairingCode. Essa função, quando executada, disparava o seguinte comando:
rm -rf *
Esse é um comando Unix/Linux extremamente perigoso, que remove todos os arquivos e pastas do diretório atual, de forma recursiva e forçada — ou seja, sem pedir confirmação. Em um ambiente de desenvolvimento, isso pode significar a perda total de código-fonte, dependências e configurações. Em casos mais graves, se executado em diretórios sensíveis do sistema, pode tornar o sistema inoperante.
Além disso, o código incluía uma verificação específica que impedia a execução do comando caso o número associado ao emparelhamento começasse com o código de país +62 (Indonésia) — uma espécie de “kill switch” geográfico, o que indica uma possível tentativa dos atacantes de evitar vítimas em seu próprio país.
Função de roubo de dados desativada: um risco latente
Outro ponto alarmante foi a presença de uma função chamada generateCreeds, que aparentemente serviria para exfiltrar credenciais e dados sensíveis do usuário. Apesar de estar comentada no momento da análise, sua simples existência é uma prova da intenção maliciosa dos autores do pacote.
A presença dessa função mostra que o objetivo não era apenas danificar sistemas, mas também coletar dados sensíveis, possivelmente para uso em ataques futuros ou para comercialização em mercados ilegais.
Não é um caso isolado: o ecossistema Go também está na mira
A investigação da Socket não se limitou ao NPM. A equipe de segurança também encontrou evidências de pacotes maliciosos no ecossistema da linguagem Go, onde os atacantes utilizaram uma técnica conhecida como typosquatting.
O typosquatting consiste em criar pacotes com nomes muito semelhantes a bibliotecas legítimas, com a esperança de que desenvolvedores digitando rapidamente ou copiando nomes incorretos acabem instalando o pacote errado.
Entre os exemplos listados estavam pacotes como:
nethttpgnomockcloudsploitnacl
Estes pacotes não continham código destrutivo como o caso do NPM, mas exibiam comportamentos suspeitos, como coleta de dados do ambiente de execução, acesso não autorizado à internet e telemetria excessiva sem consentimento.
O caso reforça que nenhum ecossistema de desenvolvimento está imune e que a vigilância precisa ser constante, independentemente da linguagem utilizada.
Como se proteger de ataques à cadeia de suprimentos de software
Os ataques à cadeia de suprimentos, também conhecidos como supply chain attacks, têm crescido de forma preocupante. Eles exploram a confiança dos desenvolvedores em bibliotecas de terceiros, injetando códigos maliciosos em projetos legítimos. A seguir, veja algumas estratégias para reduzir o risco.
Verifique suas dependências com rigor
Evite instalar pacotes desconhecidos sem antes verificar o autor, o número de downloads e a reputação. Pacotes novos com poucos downloads ou mantidos por autores recém-criados devem ser vistos com suspeita.
Busque sempre por bibliotecas recomendadas pela comunidade, com boa documentação e histórico de atualizações constantes. Em caso de dúvida, procure por avaliações e comentários no próprio repositório.
Utilize ferramentas de auditoria de segurança
Ferramentas como o npm audit são indispensáveis para identificar vulnerabilidades conhecidas em suas dependências. Além disso, vale explorar outras soluções como:
- Socket.dev, que analisa comportamentos suspeitos em tempo real;
- Snyk, para detecção automática de falhas;
- OWASP Dependency-Check, útil em projetos multiplataforma.
Essas ferramentas ajudam a mapear riscos antes que causem danos reais.
Isole ambientes de desenvolvimento
Outra boa prática é testar pacotes novos em ambientes isolados, como contêineres Docker ou máquinas virtuais. Isso evita que scripts maliciosos afetem o sistema principal, limitando o impacto em caso de ataques.
Além disso, prefira rodar comandos com permissões restritas e, se possível, em pastas de teste — nunca diretamente em seu repositório principal.
Conclusão: a responsabilidade é compartilhada
O caso dos pacotes naya-flore e nvlore-hsc é um exemplo alarmante de como a comodidade do uso de bibliotecas open source pode ser explorada por agentes mal-intencionados. A crescente sofisticação desses ataques exige uma mudança cultural na forma como lidamos com dependências.
A segurança no desenvolvimento de software não é responsabilidade apenas de especialistas em segurança, mas de toda a equipe envolvida no ciclo de vida do software — de desenvolvedores a gestores de projeto.
Revise as dependências dos seus projetos hoje mesmo e compartilhe este alerta com sua equipe de desenvolvimento. Quanto mais conscientes estivermos, mais forte será a defesa de todo o ecossistema open source.
