GlassWorm ataca OpenVSX: 73 extensões dormidas que escondem malware e roubam seus segredos

Uma nova onda da campanha conhecida como GlassWorm voltou a bater o ecossistema de extensões de editor ao aparecer 73 pacotes “durmientes” no OpenVSX, dos quais seis já foram ativados e entregam carga maliciosa, segundo a pesquisa publicada por Socket. A técnica empregada é preocupante pela sua simplicidade e eficácia: as extensões são inicialmente subendas como artefatos inocuos e, após uma atualização posterior, mudam seu comportamento para baixar e instalar código adicional ou para carregar módulos compilados (.node) que contêm a lógica maliciosa.

O que faz especialmente insidiosa a esta campanha é a tática de suplantação visual de listados legítimos: ícones, nomes e descrições muito semelhantes que enganam o desenvolvedor que confia na aparência em vez de verificar o editor ou o identificador único. Em muitos casos, o primeiro pacote atua como um “loader” leve que, em tempo de execução, baixe pacotes VSIX desde repositórios no GitHub, executa comandos CLI para instalar, ou executa código JavaScript fortemente ofuscado que decifra URLs de apoio e payloads.

O impacto potencial não é apenas a execução remota de código na máquina de um desenvolvedor: trata-se de uma porta de entrada a segredos sensíveis. Campanhas anteriores de GlassWorm têm buscado chaves de carteiras de criptomoeda, credenciais, tokens de acesso, chaves SSH e dados do ambiente de desenvolvimento. Se uma única estação de trabalho comprometida pode exfiltrar credenciais da CI/CD ou tokens que concedem acesso a repositórios e serviços na nuvem, o alcance pode rapidamente escalar a compromissos de infraestrutura e cadeias de fornecimento.

Se você acredita ter instalado alguma das extensões envolvidas, o primeiro é assumir uma possível exposição e agir rapidamente: desinstala as extensões suspeitas, verifica processos e conexões de rede invulgares, isola a máquina afetada e, acima de tudo, procede a rotar todas as credenciais e tokens que poderiam ter estado acessíveis a partir desse equipamento (tokens de repositórios, chaves SSH, credenciais de serviços na nuvem, chaves de API e carteiras). Socket publicou a lista completa de extensões identificadas e é o ponto de partida para identificar instalações afetadas: Socket — 73 Open VSX sleeper extensions.

Para além da resposta imediata, há medidas práticas para mitigar este tipo de risco no futuro: aplicar controlos de egress (filtrado de saídas) para bloquear descargas automáticas de URLs não confiáveis, evitar instalar extensões de repositórios não verificados em ambientes de produção ou CI, e usar ambientes isolados (máquinas virtuais ou contentores efêmeros) para testar novas extensões antes de as incorporar no fluxo de trabalho. Também é aconselhável que as organizações implementem políticas de gestão de segredos e rotatividade automática, e que vigilem a assinatura e permissões das contas que publicam extensões.

Para operadores e mantenedores de ecossistemas como OpenVSX e marketplaces de extensões, o caso volta a sublinhar a necessidade de mecanismos mais rigorosos de verificação de publicadores e detecção de clones: assinado de pacotes, validação do publisher ID e detecção de similaridade visual Devem ser requisitos mínimos, juntamente com análises automatizadas que detecte comportamentos “durmentes” ou padrões de descarga em tempo de execução. Você pode consultar a plataforma OpenVSX para verificar detalhes e políticas do repositório: OpenVSX.

A partir da perspectiva de cumprimento e risco, as campanhas como o GlassWorm exigem que os equipamentos de segurança integrem a revisão da cadeia de fornecimento de software nos processos de implantação: auditorias de dependências, digitalização de artefatos e criação de SBOMs (listas de componentes) permitem detectar mudanças não autorizadas e reduzir a janela de exposição. Para orientações gerais sobre gestão do risco em cadeias de fornecimento, a CISA oferece material útil que pode ajudar a priorizar controlos: CISA — Supply Chain Risk Management.

Se você detectar provas de compromisso, documenta e preserva logs e artefatos antes de limpar a equipe, notifica a sua equipe de segurança e os responsáveis pelo marketplace (OpenVSX e, se for caso disso, a equipe de Socket ou plataformas equivalentes), e prepare-se para uma reconstrução segura do ambiente (reinstalação limpa e restauração desde backups verificados). A contenção rápida e a rotação de segredos são as ações que mais reduzem danos a curto prazo.

GlassWorm é um exemplo de como os atacantes estão refinando táticas de fornecimento: em vez de introduzir malware diretamente, preferem entrar pela porta principal com artefatos benignos e ativar a carga maliciosa depois. Para os desenvolvedores e responsáveis pela segurança, isso obriga a mudar de uma mentalidade de confiança por defeito para uma verificação contínua — verificar o publisher ID, monitorar atualizações de extensões, limitar permissões e automatizar a rotação de segredos são passos concretos que reduzem o risco de se tornar uma vítima desta ou outras campanhas semelhantes.