GlassWorm ressurge e compromete mais de 430 repositórios, pacotes e extensões em nova ofensiva supply chain

A campanha GlassWorm voltou em uma nova onda muito mais ampla e preocupante. Pesquisadores de múltiplas empresas identificaram 433 componentes comprometidos em março, espalhados entre repositórios Python e JavaScript no GitHub, extensões para VSCode/OpenVSX e pacotes publicados no npm.

O ponto mais crítico é o encadeamento do ataque: o comprometimento começa em contas e repositórios do GitHub, evolui para a publicação de componentes contaminados em ecossistemas amplamente usados por desenvolvedores e termina com a execução de um stealer em JavaScript capaz de coletar carteiras de criptomoedas, credenciais, tokens de acesso, chaves SSH e dados do ambiente de desenvolvimento.

O que torna esta onda diferente

Desta vez, os pesquisadores correlacionaram a atividade em diferentes plataformas por meio do mesmo endereço na blockchain Solana usado para comando e controle, além de payloads e infraestrutura semelhantes. Segundo os levantamentos divulgados, a ofensiva alcançou:

• 200 repositórios Python no GitHub
• 151 repositórios JavaScript/TypeScript no GitHub
• 72 extensões no ecossistema VSCode/OpenVSX
• 10 pacotes publicados no npm

Outro elemento relevante é o uso de código ofuscado com caracteres Unicode invisíveis, uma técnica pensada para dificultar inspeção manual e detecção simples durante revisão de código.

Impacto para equipes de desenvolvimento

Na prática, o caso reforça um risco recorrente no supply chain de software: confiar apenas na reputação de um repositório, pacote ou extensão não basta. Uma vez que o componente malicioso seja instalado, a cadeia pode levar ao roubo de segredos, persistência local, comprometimento de pipelines e movimentação lateral a partir do ambiente do desenvolvedor.

Equipes que instalam pacotes diretamente de repositórios clonados ou que dependem de extensões menos auditadas devem revisar históricos de commit, verificar alterações forçadas em branches, procurar por instalações inesperadas do Node.js no diretório do usuário e investigar artefatos suspeitos usados para persistência.

Medidas imediatas recomendadas

• Revisar projetos clonados e dependências recentemente adicionadas
• Auditar histórico de commits em busca de force-pushes e datas incoerentes
• Procurar indicadores de comprometimento e arquivos suspeitos no ambiente do desenvolvedor
• Rotacionar credenciais, tokens e chaves caso haja qualquer indício de exposição
• Reforçar validação de origem antes de instalar pacotes, extensões e forks de terceiros

O caso mostra que ataques contra supply chain continuam migrando rapidamente entre registries, marketplaces e repositórios de código, explorando exatamente o ponto em que confiança e velocidade de desenvolvimento costumam se encontrar.

Fonte: BleepingComputer