O ataque da cadeia de suprimentos da NPM: o que aconteceu, por que isso importa e como ficar seguro

Em qualquer dia, milhões de desenvolvedores em todo o mundo executam o NPM sem pensar. É um comando simples que baixa pacotes-blocos de código pré-escritos que tornam o software de construção mais rápido, mais fácil e eficiente. Mas e se esses pacotes estiverem envenenados? A Folha de Cheatra de Segurança da Cadeia de Suprimentos de Software da OWASP estabelece a arquitetura crítica que frequentemente ignoramos: “Nenhum pedaço de software é desenvolvido no vácuo … os desenvolvedores devem entender ameaças e técnicas comuns para reduzir o risco de cadeia de suprimentos de software”. Foi exatamente isso que se desenrolou no mais recente ataque da cadeia de suprimentos do NPM, uma situação em desenvolvimento que abalou as comunidades de segurança de código aberto e Web3. A conta de um mantenedor confiável foi comprometida, as atualizações maliciosas foram empurradas para pacotes amplamente usados ​​e o código injetado silenciosamente partiu para sequestrar transações de criptografia em Ethereum, Bitcoin, Solana e além. Esta não foi uma exploração teórica. Era real. E poderia ter afetado bilhões de downloads semanais no ecossistema JavaScript. O que aconteceu: uma conta confiável transformou hackers mal -intencionados, obteve acesso à conta do NPM de um mantenedor de confiança conhecido como “CJX”. Com essa posição, eles publicaram versões maliciosas de vários pacotes amplamente usados, incluindo giz, depuração, estilos de ANSI e outros. Se você não é um desenvolvedor, aqui está por que isso importa: essas bibliotecas não são ferramentas marginais. Eles fazem parte da espinha dorsal do ecossistema JavaScript e Node.JS. Eles alimentam tudo, desde interfaces de linha de comando até aplicativos corporativos. Em suma, eles estão por toda parte. O código injetado executado no lado do cliente nos navegadores, interceptando silenciosamente transações de criptografia. Ele teve como alvo os principais blockchains – ETH, BTC, SOL, TRX, LTC, BCH – e manipulou o que os usuários viram nas respostas da interface do usuário e da API. Os endereços da carteira foram trocados em tempo real, tornando a exploração quase invisível até que os fundos fossem redirecionados. Os pacotes afetados pelo menos 18 pacotes foram comprometidos, incluindo: o relógio de giz com suporte de giz suporta-hyperlinks Hasi-Ansi Simple-swizzle cor de cor name de cor é-mancheish slice-Ansi color-inconvert wrap-esty-Ansi Ansi-Regex suporta listras-corcoros e depuração de giz e de debug ansi @s.2. O fato de tais pacotes fundamentais terem sido impactados é arrepiante. Milhões de projetos dependem dessas bibliotecas e, quando envenenadas, tornam -se vetores de ataque silencioso. Por que o NPM importa para entender a gravidade, você precisa apreciar o que é o NPM. NPM (Node Package Manager) é o maior registro de software do mundo. Ele alimenta o ecossistema JavaScript de código aberto, que sustenta o desenvolvimento da Web e da Web3. Os desenvolvedores dependem do NPM para importar código pronto, confiando em mantenedores para manter os pacotes seguros e funcionais. 2,1 milhões de pacotes estão disponíveis no NPM. Bilhões de downloads por semana acontecem globalmente. Tudo, desde aplicativos de inicialização a trocas financeiras e protocolos de blockchain, depende disso. Em outras palavras: se o NPM espirra, a internet pega um resfriado. É por isso que um compromisso da cadeia de suprimentos aqui não é apenas mais uma manchete. É um risco sistêmico para o desenvolvimento de software em todo o mundo. O código malicioso: como funcionou a carga útil injetada foi projetada para: interceptar atividade criptográfica: observando transações envolvendo ETH, BTC, SOL, TRX, LTC e BCH. Manipular as respostas da interface do usuário e da API: Fazer com que os endereços da carteira pareçam inalterados para os usuários, mesmo enquanto são trocados. Substitua os endereços do destinatário: redirecionando os fundos diretamente para carteiras controladas por atacantes. Este é o cenário de pesadelo de um ataque da cadeia de suprimentos de software: invisível, escalável e devastador. Ao contrário de um email de phishing que visa uma pessoa, um pacote envenenado tem como alvo todos os desenvolvedores e o usuário final a jusante. Em uma veia paralela, os reversores relataram que, em 2024, os incidentes de malware de código aberto diminuíram-mas vazamentos de segredos de desenvolvedor aumentaram 12%, alimentando compromissos da cadeia de suprimentos de alto perfil. Joe Nicastro (CTO de campo na Legit Security) ecoou a idéia: “Controles de acesso fortes-como a autenticação multifatorial e o acesso menos privilegiado-garantindo que apenas as pessoas certas possam modificar o código ou construir”. Como foi detectado ironicamente, os atacantes cometeram erros. O código injetado causou falhas de pipeline de CI/CD – os sistemas de construção automatizados começaram a falhar. Isso levantou bandeiras vermelhas mais cedo, levando a uma investigação e mitigação mais rápidas. Jeff Williams (CTO e co-fundador da Security Security) é franco: “Se um invasor puder acessar qualquer parte-do laptop de um desenvolvedor a um servidor de compilação-ele pode injetar código malicioso. Depois de estar no lugar, é incrivelmente difícil de identificar”. Se não fosse por esses acidentes, o ataque pode ter sido detectado por muito mais tempo, com consequências potencialmente catastróficas para carteiras e trocas. Por que esse ataque atinge o Web3, enquanto os ataques da cadeia de suprimentos afetam todo o software, este teve uma reviravolta no Web3. O código malicioso direcionou explicitamente usuários de criptografia, seqüestrando transações de blockchain em voo. Para uma indústria descentralizada que se orgulha de sistemas sem confiança, isso é um lembrete gritante: o link mais fraco nem sempre é o blockchain – é a infraestrutura ao seu redor. As carteiras, extensões de navegador e ferramentas de desenvolvedor dependem do código de código aberto. E quando esse código é comprometido, a descentralização não o protege. Etapas de mitigação A equipe de segurança do NPM e os mantenedores ainda estão limpando, mas aqui está o que desenvolvedores e usuários devem saber: para os desenvolvedores congelam instalações/implantam imediatamente. Volte para as versões publicadas antes de 8 de setembro. Auditefiles de auditoria e reconstrua do zero. Use o NPM Config Set Scripts Ignore-Scrits para instalações de emergência. Purge os caches CDN/navegador quando as construções limpas estão prontas. Inspecione as compilações para o código ofuscado ou padrões de regex direcionados a endereços de criptografia. Gire os tokens NPM, segredos de CI/CD e aplique 2FA/Passkeys para mantenedores. Para os usuários finais, as carteiras de hardware permanecem seguras. Sempre verifique os endereços no dispositivo antes de assinar. Evite usar carteiras de software/navegador até que as compilações corrigidas estejam totalmente implantadas. Revise todas as transações feitas desde ~ 13: 00 UTC no dia do ataque. Se os endereços do destinatário não correspondem à intenção, revogue as aprovações. Lições, devemos levar a sério o código aberto ≠ seguro por padrão apenas porque um pacote é popular não significa que é seguro. Os atacantes sabem que as dependências mais usadas são os alvos mais lucrativos. Os ataques da cadeia de suprimentos são a nova fronteira, em vez de atacar uma empresa, os maus atores envenenam as ferramentas das quais milhares de empresas dependem. É eficiente, furtivo e destrutivo. A confiança humana é as blockchains de ligação mais fracas podem ser imutáveis, mas os sistemas que construímos em cima deles não são. Uma conta de mantenedor comprometida pode causar mais danos do que uma exploração de dia zero. As carteiras de hardware salvam vidas (e fundos), esse ataque prova mais uma vez por que as carteiras de hardware são essenciais. Verificações claras de assinatura e transação quebram a capa da invisibilidade em que os atacantes confiam. Uma chamada para vigilância Este incidente não deve ser eliminado como “apenas mais um hack do NPM”. É um alerta. Para desenvolvedores: proteja suas contas, audite dependências e nunca assuma que os pacotes amplamente usados ​​são à prova de balas. Para usuários do Web3: não confie apenas nas carteiras do navegador e sempre confirme transações em hardware confiável. Para o ecossistema, a segurança da cadeia de suprimentos deve se tornar tão importante quanto as auditorias de contratos inteligentes. Conclusão O ataque da cadeia de suprimentos da NPM pode ter sido detectado mais cedo, mas a ameaça está longe de se foi. As listas de dependência e os indicadores de compromisso ainda estão sendo atualizados à medida que os pesquisadores se aprofundam. No Web3, gostamos de dizer “não confie, verifique”. Essa sabedoria não se aplica apenas à atividade na cadeia. Ele se aplica ao código que importamos, as ferramentas que usamos e a confiança que estendemos aos mantenedores invisíveis. Porque no final, nem sempre é a blockchain que falha – é o humano por trás do código. Se você gostou dessa história, considere ingressar em nossa lista de discussão. Compartilhamos histórias reais, guias e insights com curadoria sobre desenvolvimento da Web, segurança cibernética, blockchain e computação em nuvem, sem spam, apenas conteúdo que vale o seu tempo.

Fonte