Ataque ao NPM: Pacotes com mais de 2 bilhões de downloads semanais foram comprometidos

O esquema de phishing e o comprometimento da conta

O ataque à cadeia de suprimentos foi iniciado por um e-mail de phishing meticulosamente elaborado, enviado a Josh Junon, um mantenedor prolífico e confiável do npm conhecido como Qix. O e-mail, que vinha do domínio enganoso support[at]npmjs[dot]help —muito similar ao legítimo npmjs.com—, era parte de uma tática de intimidação. Falsamente, afirmava que a conta de Junon seria bloqueada em 10 de setembro de 2025 se ele não atualizasse suas credenciais de autenticação de dois fatores (2FA), as quais, segundo o e-mail, tinham mais de 12 meses de idade.

(Imagem tirada do GitHub.)

O site de phishing apresentava um formulário de login que, ao ser enviado, exfiltraria as credenciais do usuário para uma URL controlada pelos atacantes. Apesar de sua cautela habitual, Junon, que estava usando seu dispositivo móvel e havia tido uma semana longa e ocupada, cometeu o erro de clicar no link e inserir suas credenciais. Essa única ação concedeu aos atacantes o controle total de sua conta do npm, permitindo que eles publicassem versões maliciosas dos pacotes que ele mantinha. Os atacantes registraram o domínio de phishing apenas três dias antes do ataque, o que demonstra uma ação calculada e bem preparada.

Um ataque furtivo e de amplo alcance

O comprometimento foi inicialmente detectado pela Aikido Security em 8 de setembro, às 13:16 UTC. Seu sistema de inteligência sinalizou uma série de atualizações de pacotes suspeitas na conta de Junon. Ao confirmar o comprometimento, a Aikido o notificou via Bluesky (que já estava ciente da situação), e ele iniciou o processo de limpeza pouco mais de uma hora e meia depois, às 15:15 UTC. A rápida resposta tanto dos pesquisadores de segurança quanto do mantenedor ajudou a mitigar o dano potencial.

Os atacantes aproveitaram seu acesso para injetar código malicioso nas versões mais recentes de 18 pacotes do npm muito populares. O número combinado de downloads semanais desses pacotes é de cerca de 2,6 bilhões, o que torna este um ataque verdadeiramente massivo.

_____

Nota: Node Package Manager (npm) é o gerenciador de pacotes padrão para Node.js, um ambiente de execução que permite que o código JavaScript seja executado fora de um navegador. O NPM serve como um vasto registro público para pacotes de software e como uma ferramenta de linha de comando que os desenvolvedores usam para instalá-los e gerenciá-los, o que o torna a espinha dorsal do ecossistema moderno do JavaScript.

_____

Os pacotes comprometidos mais baixados incluíram (o número de downloads semanais é mostrado entre parênteses):

• ansi-styles (371,4 milhões)

• debug (357,6 milhões)

• chalk (300,0 milhões)

• supports-color (287,1 milhões)

• strip-ansi (261,2 milhões)

• ansi-regex (243,6 milhões)

• wrap-ansi (198,0 milhões)

• color-convert (193,5 milhões)

• color-name (191,7 milhões)

• is-arrayish (73,8 milhões)

• slice-ansi (59,8 milhões)

• error-ex (47,2 milhões)

• color-string (27,5 milhões)

• simple-swizzle (26,3 milhões)

• supports-hyperlinks (19,2 milhões)

• has-ansi (12,1 milhões)

• chalk-template (3,9 milhões)

• backslash (0,3 milhões)

Muitos deles são dependências fundamentais, mantidas em conjunto com Sindre Sorhus, um dos mantenedores mais populares do npm. Essa profunda integração no ecossistema JavaScript ampliou o "raio de impacto" do ataque. Ao comprometer uma conta de alto perfil, os atacantes conseguiram atingir um grande número de aplicações e bibliotecas que dependiam indiretamente desses pacotes.

Como o malware operava

O código malicioso, que parece ser consistente em todos os pacotes comprometidos, foi projetado para atuar como um interceptor baseado no navegador, visando a atividade de criptomoedas e Web3. Era altamente intrusivo e furtivo, operando em múltiplas camadas para evadir a detecção.

A funcionalidade principal do malware envolvia um processo de várias etapas:

1. Injeção e "hooking": O código se injetava nas funções principais de JavaScript do navegador, como fetch e XMLHttpRequest, e em APIs comuns de carteiras, especificamente no objeto window.ethereum para carteiras compatíveis com Ethereum como a MetaMask, bem como nas APIs utilizadas por carteiras compatíveis com Solana como a Phantom. Isso lhe permitia interceptar tanto o tráfego web quanto a atividade da carteira.

2. Vigilância de dados: Ele escaneava as respostas da rede e as cargas úteis das transações em busca de qualquer coisa que se assemelhasse a um endereço ou transferência de criptomoedas. O malware era capaz de reconhecer múltiplos formatos nas principais redes, incluindo Ethereum, Bitcoin, Litecoin, Solana e Tron.

3. Substituição de endereços: Usando a lógica de correspondência de strings (string-matching) e listas predefinidas de endereços controlados pelos atacantes, o malware substituía o endereço do receptor legítimo por um endereço "semelhante" da lista dos atacantes. Isso tornava a transação fraudulenta mais difícil de ser detectada.

4. Sequestro de transações: Antes que um usuário pudesse assinar uma transação, o malware alterava os parâmetros da mesma (por exemplo, receptores, aprovações, permissões). Mesmo se a interface de usuário mostrasse o destino correto, os dados da transação subjacente já haviam sido modificados para desviar os fundos para os atacantes.

5. Furtividade e engano: O código era fortemente ofuscado para ocultar seu propósito. Ele usava variáveis com prefixos _0x e um enorme array de strings ofuscadas que eram decodificadas em tempo de execução. Para evitar levantar suspeitas, às vezes ele evitava mudanças óbvias na interface de usuário enquanto sequestrava silenciosamente a transação em segundo plano. O malware até mesmo retornava uma resposta de "sucesso" falsa para a aplicação, fazendo parecer que a transação havia sido concluída corretamente.

O código malicioso visava especificamente interações relacionadas a criptomoedas, o que significa que nem todas as aplicações que usavam os pacotes comprometidos foram afetadas. De acordo com Andrew MacPherson, engenheiro principal de segurança da Privy, critérios específicos precisavam ser atendidos para que uma aplicação fosse vulnerável, incluindo uma instalação recente ou um arquivo package-lock.json criado durante o breve período em que as versões maliciosas estiveram ativas.

Implicações mais amplas e recomendações para desenvolvedores

O ataque a Qix é um duro lembrete da crescente ameaça de ataques à cadeia de suprimentos. Como demonstrado por incidentes recentes direcionados a eslint-config-prettier e outras bibliotecas do npm, os atacantes estão cada vez mais focados na cadeia de suprimentos de software para obter uma base em milhares de aplicações simultaneamente. O navegador web, com sua ampla superfície de API, se tornou um alvo principal para este tipo de ataque.

Por enquanto, é fortemente recomendado que os desenvolvedores tomem as seguintes medidas para proteger a si mesmos e a seus usuários:

• Reverter: Retornem imediatamente para uma versão segura conhecida de qualquer pacote comprometido. As versões maliciosas foram removidas pela equipe do npm, mas é crucial garantir que seus projetos estejam usando versões seguras e previamente verificadas.

• Auditar dependências: Realizem uma auditoria completa de seus arquivos package.json e package-lock.json para verificar se houve atualizações recentes dos pacotes afetados que possam ter ocorrido durante a janela do ataque.

• Monitorar transações: Se suas aplicações interagem com carteiras de criptomoedas ou APIs da Web3, monitorem as transações de perto em busca de qualquer atividade incomum.

• Habilitar 2FA: Fortaleçam a segurança de suas próprias contas habilitando a autenticação de dois fatores e usando uma chave de hardware, se possível. Desconfiem extremamente de qualquer e-mail, mesmo aqueles que pareçam legítimos, que peçam para atualizar credenciais ou clicar em links. Em vez disso, naveguem diretamente para o site oficial.

Embora a rápida detecção e resposta tenham limitado o dano geral, este incidente destaca uma fragilidade significativa. Um único ataque de phishing bem-sucedido contra um mantenedor de alto perfil pode ter um efeito cascata em todo o ecossistema de software, expondo potencialmente milhões de usuários finais a perdas financeiras. Este evento ressalta a necessidade de vigilância contínua, protocolos de segurança aprimorados e esforços de colaboração entre pesquisadores de segurança, provedores de plataformas e a comunidade de desenvolvedores para proteger a cadeia de suprimentos digital.

Embora, do lado de Qix, o problema parecesse ter sido "resolvido" horas depois, vale a pena mencionar que outros mantenedores do npm também foram afetados, como é indicado aqui:

Na Fluid Attacks, elogiamos a transparência e a rápida reação da comunidade de desenvolvedores e pesquisadores de segurança ao responder a este incidente. É um testemunho do espírito de colaboração que sustenta o mundo do software de código aberto, do qual, saibamos ou não, dependemos quase todos em grande parte.

Embora neste caso o ataque tenha sido bem-sucedido devido a um erro humano e não a uma vulnerabilidade de software, o incidente ainda ressalta a importância crítica de ter uma defesa sólida. Na Fluid Attacks, como parte de nossa completa solução de Hacking Contínuo, além de AST automatizado e PTaaS, oferecemos análise de composição de software (SCA), incluindo listas de materiais de software (SBOM), para ajudar as empresas a rastrear e gerenciar continuamente suas dependências, identificar vulnerabilidades e proteger de forma proativa sua cadeia de suprimentos de software.

Convidamos você a iniciar nosso teste gratuito de 21 dias agora mesmo.