Onda de Ataques à Cadeia de Suprimentos do npm: O que Aconteceu? Como Mitigar o Risco?

Título original do artigo: "Supply Chain Attack Goes Viral Overnight: What Happened? How to Mitigate Risk?"

Autor original do artigo: Azuma, Odaily

Em 9 de setembro, horário do Leste Asiático, o Diretor de Tecnologia da Ledger, Charles Guillemet, publicou um alerta no X, afirmando: "Um ataque em larga escala à cadeia de suprimentos está em andamento, com a conta NPM de um desenvolvedor renomado comprometida. O pacote de software afetado já foi baixado mais de 1 bilhão de vezes, indicando que todo o ecossistema JavaScript pode estar em risco."

Guillemet explicou ainda: "O código malicioso funciona modificando silenciosamente endereços de criptomoedas em segundo plano para roubar fundos. Se você usa uma carteira de hardware, verifique cuidadosamente cada transação de assinatura e estará seguro. Se você não usa uma carteira de hardware, por favor, evite temporariamente qualquer transação on-chain. Ainda não está claro se o invasor já roubou a frase mnemônica de carteiras de software."

O que aconteceu?

De acordo com o relatório de segurança citado por Guillemet, a causa direta deste incidente foi: a conta NPM do renomado desenvolvedor @qix foi comprometida, levando à publicação de versões maliciosas de dezenas de pacotes de software, incluindo chalk, strip-ansi e color-convert. O código malicioso pode ter se espalhado para usuários finais quando desenvolvedores ou usuários instalaram automaticamente dependências.

Nota Odaily: Dados semanais de volume de download dos pacotes de software comprometidos.

Em resumo, este é um caso clássico de ataque à cadeia de suprimentos—onde um invasor implanta código malicioso (como um pacote NPM) em uma ferramenta de desenvolvimento ou sistema de dependências para realizar atividades maliciosas. NPM, abreviação de Node Package Manager, é a ferramenta de gerenciamento de pacotes mais utilizada no ecossistema JavaScript/Node.js. Suas principais funções incluem gerenciamento de dependências, instalação e atualização de pacotes, compartilhamento de código, entre outras.

Devido à imensa escala do ecossistema NPM, que atualmente consiste em milhões de pacotes de software, quase todos os projetos Web3, carteiras de criptomoedas e ferramentas de frontend dependem do NPM—é exatamente por isso que as extensas dependências do NPM e sua complexa cadeia de ligações o tornam um ponto de entrada de alto risco para ataques à cadeia de suprimentos. Ao implantar código malicioso em um pacote de software amplamente utilizado, os invasores podem potencialmente impactar milhares de aplicações e usuários.

Como mostrado no fluxograma de propagação do código malicioso acima:

· Um determinado projeto (caixa azul) depende diretamente de algumas bibliotecas open-source comuns, como express.

· Essas dependências diretas (caixas verdes) então dependem de outras dependências indiretas (caixas amarelas, como lodash).

· Se uma dependência indireta for secretamente injetada com código malicioso por um invasor (caixa vermelha), ela será propagada ao longo da cadeia de dependências para esse projeto.

O que isso significa para as criptomoedas?

A relevância direta deste incidente de segurança para a indústria de criptomoedas é que o código malicioso implantado pelo hacker no pacote de software comprometido mencionado acima é um sofisticado "sequestrador de área de transferência de criptomoedas" que rouba ativos de criptomoedas substituindo endereços de carteiras e sequestrando transações.

O fundador da Stress Capital, GE (@GuarEmperor), detalhou isso no X, afirmando que a injeção do "sequestrador de área de transferência" do hacker adota dois modos de ataque—usando passivamente o algoritmo de distância de Levenshtein para substituir endereços de carteira, que são visualmente semelhantes e, portanto, extremamente difíceis de detectar; e alterando ativamente o endereço de destino na carteira de criptomoedas detectada pelo navegador antes do usuário assinar a transação.

Como esse ataque teve como alvo as bibliotecas de camada fundamental de projetos JavaScript, até mesmo projetos que dependem indiretamente dessas bibliotecas podem ser afetados.

Como o hacker lucra?

O código malicioso implantado pelo hacker também divulgou seus endereços de ataque. O principal endereço de ataque do hacker na Ethereum é 0xFc4a4858bafef54D1b1d7697bfb5c52F4c166976, com fundos provenientes principalmente dos seguintes três endereços:

· 0xa29eEfB3f21Dc8FA8bce065Db4f4354AA683c0240

· x40C351B989113646bc4e9Dfe66AE66D24fE6Da7B

· 0x30F895a2C66030795131FB66CBaD6a1f91461731

A equipe da Arkham criou uma página de rastreamento para este evento de ataque, onde você pode consultar informações em tempo real sobre os ganhos e transferências do hacker.

No momento da redação, o ataque do hacker rendeu apenas US$ 496, mas considerando a propagação ainda não determinada do código malicioso, espera-se que esse número continue a crescer—o desenvolvedor já foi notificado e está colaborando ativamente com a equipe de segurança do NPM para resolver o problema. O código malicioso foi removido da maioria dos pacotes afetados, então a situação está sob controle.

Como mitigar o risco?

O fundador da Defillama @0xngmi afirmou que, até o momento no X, embora este evento possa parecer perigoso, o impacto real não é tão amplo—pois este evento só afeta sites que fizeram atualizações desde que o pacote de software NPM comprometido foi lançado, outros projetos continuarão usando a versão antiga; e a maioria dos projetos trava suas dependências, então mesmo que façam atualizações, ainda usarão o código antigo e seguro.

No entanto, como os usuários finais não podem realmente saber se um projeto travou as dependências ou se possuem algumas dependências baixadas dinamicamente, é essencial, neste momento, que o projeto venha a público para autoinspeção e divulgação.

No momento da redação, vários projetos de carteiras ou aplicativos, incluindo MetaMask, Phantom, Aave, Fluid, Jupiter, já divulgaram que não foram afetados por este evento. Portanto, teoricamente, os usuários podem usar com confiança carteiras que foram confirmadas como seguras para acessar protocolos que também foram confirmados como seguros. No entanto, para carteiras ou projetos que ainda não passaram por divulgação de segurança, evitar seu uso temporariamente pode ser uma abordagem mais segura.