Uma vulnerabilidade recentemente descoberta no mercado do Visual Studio Code (VS Code) permitiu que atores maliciosos sequestrassem nomes de extensão descontinuados e deslizassem malware passado desenvolvedores desavisados.
Em junho, pesquisadores de reversor (RL) descoberto Uma nova extensão maliciosa, ahbanc.shiba, que tinha o mesmo identificador “shiba” que uma extensão compatível com ransomware removida em março-apesar da documentação oficial que afirma nomes de extensão deve ser única.
Essa anomalia expôs uma brecha que permite reutilizar nomes de extensões removidas, abrindo a porta para cadeia de mantimentos Ataques direcionados ao IDES dos desenvolvedores.
Historicamente, a maioria das ameaças de código vs reembalou pacotes de NPM maliciosos. No entanto, a inteligência de ameaças da RL mostra uma mudança: as extensões maliciosas de hoje estão sendo criadas especificamente para o código VS, com downloaders personalizados e cargas úteis em segunda etapa.
Em março, a RL identificou duas extensões – ahban.shiba e ahban.cychelloworld – que baixaram e executaram um módulo de ransomware nascente, criptografando arquivos em uma pasta de teste e exigindo pagamento em Shiba Inu Cryptocurrency.
Essas extensões foram prontamente removidas do mercado.
Em junho, os pesquisadores da RL avistaram Ahbanc.shiba, que funcionava de forma idêntica aos seus antecessores, exceto pelo nome do editor (ahbanC vs. ahban).
A extensão registrou um único comando (shiba.aowoo) que, quando invocado, baixou um Powershell Script de um servidor remoto para criptografar arquivos na pasta de teste da área de trabalho da vítima.
Apesar de compartilhar o identificador de “Shiba”, a extensão deveria ter sido bloqueada pelas verificações de singularidade do VS Code Marketplace – até que o RL se aprofundou mais.
Depois de publicar a extensão, tentamos publicar uma “nova” extensão com o mesmo nome usando os dois autores,Testrl777eTestrl778.
Como funciona a brecha de relevância
VS Extensões de código declaram um ID exclusivo composto de . em seus package.json manifesto.
As orientações oficiais afirmam que os nomes de extensão devem ser minúsculos, sem espaço e em toda a plataforma.
Na prática, os pesquisadores de RL descobriram que o mercado aplica a singularidade apenas para não publicado Extensões: os editores não podem reutilizar nomes de extensões que foram apenas não publicadas (as estatísticas permanecem), mas os nomes das extensões removidas (estatísticas apagadas) se tornam um jogo justo.
Para confirmar isso, RL criou uma extensão de teste, testrl777.myextensionteste observou que a publicação de uma segunda extensão com o mesmo nome falhou quando o original permaneceu não publicado, independentemente da editora.
No entanto, uma vez que a extensão original foi removida, a RL publicou com sucesso novas extensões nomeadas myextensiontest sob diferentes editores.
O mesmo experimento com o nome malicioso “Solity-Ethereum” confirmou que os atores de ameaças poderiam reivindicar livremente nomes de pacotes maliciosos removidos anteriormente.
Implicações mais amplas e cronograma
Essa brecha reflete vulnerabilidades semelhantes em outras plataformas de código aberto. Em 2023, RL relatou que excluiu Pacote Pypi Os nomes também podem ser reaproveitados, permitindo que atores maliciosos publiquem pacotes de Python trojanizados em nomes de aparência legítima.
A plataforma de código aberto e sem fonte aberto fornece avaliações gratuitas de segurança e risco para repositórios públicos, como NPM, Pypi, Rubygems e Nuget. Recentemente, a RL introduziu a adição do VS Code Marketplace à plataforma.
Ao contrário do Pypi, no entanto, o VS Code Marketplace não fornece mecanismo para reservar permanentemente os nomes da lista negra uma vez removidos.
A linha do tempo da RL indica que as extensões originais do AHBAN.SHIBA foram publicadas em outubro de 2024 e removidas até março de 2025.
O novo Ahbanc.shiba apareceu em 24 de março de 2025, com versões atualizadas em junho de 2025, antes de não ser publicado por volta de 17 de junho. Por ser não publicado em vez de remover, seu nome permanece reservado – mas qualquer identificador de qualquer extensão removido é vulnerável.
Com o mercado de código VS crescendo em popularidade, os desenvolvedores devem permanecer vigilantes. RL recomenda:
- Monitore as origens da extensão: verificar os editores e revisar os históricos de extensão antes da instalação.
- Ativar assinatura e revisões de código: favorece extensões com assinatura de código mantida e auditorias da comunidade.
- Aproveite as ferramentas de segurança: use plataformas como o Spectra Aferece da RL, que agora suporta o mercado de código vs, para digitalizar e avaliar o risco de repositório.
A brecha de reuse-nomes destaca um risco crítico da cadeia de suprimentos: qualquer extensão removida-legitimada ou maliciosa-pode ser ressuscitada por novos atores que buscam distribuir malware com um nome confiável.
À medida que os repositórios de código aberto continuam sendo armados, a defesa deve se estender além do código para incluir políticas de gerenciamento de identificador e monitoramento proativo dos ecossistemas de extensão.
Encontre esta história interessante! Siga -nosLinkedIneXPara obter mais atualizações instantâneas.