A campanha que hackeou Axios expõe a fragilidade das cadeias de fornecimento de software

Nesta semana, a comunidade de desenvolvimento de Node.js teve que se encaixar um lembrete desconfortável: as cadeias de fornecimento do software são tão frágeis como as pessoas que as mantêm. Os responsáveis pelo cliente de HTTP Axios publicaram um relatório detalhado sobre um incidente em que atacantes conseguiram comprometer uma conta de manutenção e publicar duas versões maliciosas do pacote no registo npm. Essas versões, rotuladas como 1.14.1 e 0.30.4, introduziram uma dependência chamadaplain-crypto-jsTinha um trovão de acesso remoto capaz de ser executado no macOS, Windows e Linux.

A janela de exposição foi curta – as versões maliciosas estiveram no registro cerca de três horas antes de serem retiradas –, mas esse breve lapso foi suficiente para projetos e ambientes que as baixaram ficar em risco. Os mantenedores de Axios avisaram que qualquer sistema que instalou essas versões durante esse período deve ser considerado comprometido e recomendaram rotar credenciais e chaves de autenticação. Além disso, a equipe afetada borrou máquinas comprometidas e restabeleceu acessos enquanto implementa medidas para reduzir a probabilidade de algo similar voltar a ocorrer. Você pode ler o post-mortem oficial no repositório de Axios no GitHub: https://github.com/axios/axios/issues/10636.

O que torna especialmente perturbador este incidente não é apenas o malware em si, mas a forma como os atacantes conseguiram acesso: uma campanha de engenharia social muito trabalhada dirigida a mantenedores. Segundo a crônica dos afetados, o ataque começou com a suplantação de uma empresa legítima, replicando sua imagem corporativa e criando perfis falsos que simulavam funcionários e colaboradores do ecossistema de código aberto. A partir daí, convidaram os desenvolvedores a um espaço do Slack "de confiança" e organizaram videochamadas que pareciam autênticas.

Durante uma dessas reuniões simuladas os atacantes mostraram um suposto erro técnico que motivava a instalar uma atualização da Microsoft Teams. Essa "atualização" não era outra coisa que um instalador que instalou um RAT na equipe do mantenedor, permitindo aos atacantes acederem a sessões autenticadas e extrair credenciais de npm. Ou seja, a proteção baseada em MFA ficou prejudicada porque o acesso foi materializado desde sessões já autenticadas. A explicação e análise do Google Threat Intelligence Group, que atribui a operação ao ator rastreado como UNC1069, inclui mais detalhes sobre a infraestrutura usada e seus paralelos com campanhas prévias: https://cloud.google.com/blog/topics/threat-intelligence/north-korea-threat-actor-targets-axios-npm-package.

Grupos de segurança que acompanharam a pista a esta atividade apontam que não se trata de um ataque isolado, mas de uma campanha coordenada e dirigida a projetos com muita dependência no ecossistema Node.js. A assinatura Socket, que publicou uma análise do padrão de ataque, tem documentado como os atacantes contataram múltiplos mantenedores através do LinkedIn, Slack ou outras plataformas e replicaram o mesmo modo operandi: convites a espaços privados, reuniões com atores aparentemente reais e pressão para instalar software "nativo" ou executar comandos de consola que terminavam descarregando malware. Socket resume seus achados e preocupação com o impacto em pacotes de alto uso neste artigo: https://socket.dev/blog/attackers-hunting-high-impact-nodejs-maintainers.

Nem todos os objetivos cederam. Vários mantenedores compartilharam como rejeitaram os pedidos de instalar binários ou executar comandos, e um deles, Pelle Wessman, mostrou uma captura da mensagem fraudulenta que lhes apresentaram - um suposto erro de conexão RTC - e explicou que quando se recusou a executar o instalador os atacantes até tentaram convencê-lo de executar um comando curl para baixar código. Seu testemunho está disponível no LinkedIn e nos fios do post-mortem: publicação de Pelle Wessman.

Uma dimensão técnica relevante aqui é que os atacantes não modificaram diretamente o código fonte do projeto Axios. Em vez disso, injetaram uma dependência maliciosa em pacotes legítimos, uma tática que permite aos atores maliciosos empacotar código prejudicial dentro de uma atualização aparentemente confiável. Essa estratégia sublinha por que as cadeias de fornecimento de software, e em particular os repositórios de pacotes, são objetivos tão atraentes: comprometer uma livraria popular pode amplificar um ataque a milhares ou milhões de usuários.

O que pode fazer um desenvolvedor ou um computador se suspeitar que instalou uma das versões afetadas? O mais imediato e prudente é agir como se o sistema estivesse comprometido: assumir que tokens, credenciais de npm e sessões foram expostas, e proceder a rotar-las e revogar. Também convém auditar os ficheiros de bloqueio (package-lock.json, yarn.lock) para detectar dependências inesperadas, examinar histórias de instalação e rever logs de CI/CD por atividade incomum. Para a gestão específica de contas npm, ativar ou reforçar a autenticação de dois fatores e revisar tokens de automação é recomendável; npm documenta boas práticas e a configuração de 2FA em seu site: https://docs.npmjs.com/configuring-two-factor-authentication.

Além das operações de emergência, este episódio abre perguntas mais amplas sobre como proteger o ecossistema de código aberto. Os mantenedores costumam trabalhar com recursos limitados e recebem pedidos de colaboração legítimas com asiduidade; no entanto, a sofisticação dessas campanhas exige protocolos mais estritos: verificação de identidade de novos colaboradores, canais de comunicação claramente definidos, práticas de hardening de máquinas de manutenção (máquinas dedicadas e segregadas), e processos de publicação que minimizem o uso de tokens pessoais em favor de credenciais de curto tempo ou fluxos de CI com permissões mínimas.

Finalmente, convém lembrar que atores com motivações financeiras ou estatais utilizaram táticas semelhantes antes, estabelecendo uma variedade de ferramentas como backdoors, downloadres e infostealers destinados a coletar credenciais, cookies e outros segredos. A atribuição do Google à UNC1069 menciona o uso de uma variante batizada WAVESHAPER.V2, o que liga este incidente com padrões observados em campanhas anteriores contra vítimas do setor cripto e outras infra-estruturas: análise do GTIG.

A lição é clara e dura: a segurança do software não é apenas um problema técnico, é também uma questão humana. Proteger projetos de alto impacto exige não só controles automáticos, mas formação, protocolos e recursos para que aqueles que mantêm as peças críticas não sejam o elo mais fraco. Enquanto isso, se você administra projetos que dependem de Axios ou trabalha com pacotes de npm, verifique suas instalações, assume precaução se as versões mencionadas e rota chaves e tokens foram baixados.

Para ampliar a leitura do incidente e sua pesquisa, além do post-mortem de Axios e do relatório do Google, você pode consultar a cobertura técnica em meios especializados, por exemplo em BleepingComputer, que resume o ataque e seu alcance: https://www.bleepingcomputer.com/news/security/hackers-compromise-axios-npm-package-to-drop-cross-platform-malware/.