GitLab descobre ataque generalizado à cadeia de suprimentos do NPM

• Uma variante destrutiva de malware está se espalhando por todo o ecossistema npm, e a equipe de segurança do GitLab a detectou
• O malware é uma forma evoluída do Shai-Hulud, com uma estrutura de propagação em worm que infecta automaticamente outros pacotes de desenvolvedores comprometidos
• Após roubar credenciais de GitHub, AWS, GCP, Azure e outros, ele exfiltra dados para repositórios GitHub controlados pelos atacantes
• Ele também inclui um "dead man's switch" que apaga imediatamente os dados do usuário se o acesso ao GitHub e ao npm for bloqueado ao mesmo tempo
• O GitLab confirmou que seus próprios sistemas não foram infectados e forneceu formas de detecção e resposta por meio do Dependency Scanning e do GitLab Duo Chat

---

Visão geral do ataque

• A equipe de Vulnerability Research do GitLab detectou um ataque em larga escala à cadeia de suprimentos no ecossistema npm
  • O sistema interno de monitoramento encontrou vários pacotes infectados
  • O malware foi identificado como uma variante do Shai-Hulud
• O malware infecta automaticamente outros pacotes de desenvolvedores comprometidos por meio de propagação em worm
• O GitLab confirmou que não utilizou os pacotes maliciosos em seu ambiente e compartilhou as informações com a comunidade de segurança

Estrutura interna do ataque

• Os pacotes npm maliciosos detectados pelo sistema interno de monitoramento executam as seguintes funções
  • Coleta de credenciais de GitHub, npm, AWS, GCP e Azure
  • Envio dos dados roubados para repositórios GitHub controlados pelos atacantes
  • Infecção automática de outros pacotes da vítima
  • Execução de payload destrutivo se o acesso à infraestrutura for bloqueado
• Vários pacotes infectados já foram confirmados, e a investigação continua

Análise técnica: como o ataque funciona

Vetor de infecção inicial

• O malware invade o sistema por meio de um processo de carregamento em múltiplas etapas
  • Um script setup_bun.js é adicionado ao package.json do pacote infectado
  • Na aparência, ele se disfarça como um instalador do runtime JavaScript Bun
  • Na prática, executa bun_environment.js (10 MB, payload ofuscado)
• A composição com um pequeno loader e um grande payload ofuscado ajuda a evitar detecção

Coleta de credenciais

• Assim que é executado, o malware coleta tokens e segredos de diversas fontes
  • Tokens do GitHub (ghp_, gho_)
  • Credenciais da AWS, GCP e Azure
  • Tokens do npm (.npmrc e variáveis de ambiente)
  • Uso da ferramenta Trufflehog para varrer todo o diretório home em busca de chaves de API, senhas, histórico do Git e mais

Rede de exfiltração de dados

• Com os tokens roubados do GitHub, o malware cria repositórios públicos com a descrição "Sha1-Hulud: The Second Coming."
  • Esses repositórios funcionam como uma caixa de depósito de dados
  • Ele instala runners do GitHub Actions para garantir persistência
• Se não tiver permissões suficientes, procura outros repositórios com o mesmo marcador para reutilizar tokens de outros sistemas
  • Isso forma uma rede distribuída de compartilhamento de tokens

Propagação pela cadeia de suprimentos

• Com os tokens roubados do npm, o malware infecta todos os pacotes da vítima
  1. Baixa o pacote original
  2. Insere setup_bun.js como script de preinstall
  3. Adiciona o payload bun_environment.js
  4. Incrementa o número da versão
  5. Republica o pacote infectado no npm

Dead man's switch

• O malware monitora continuamente o acesso ao GitHub (exfiltração de dados) e ao npm (propagação)
  • Se os dois canais forem bloqueados, ele executa imediatamente a destruição de dados
• Windows: apaga arquivos do usuário e sobrescreve setores do disco
• Unix-like: sobrescreve os arquivos com o comando shred e depois os apaga
• Em caso de exclusão em massa de repositórios GitHub ou revogação em massa de tokens npm, existe o risco de que sistemas infectados apaguem dados simultaneamente

Indicadores de comprometimento (IoC)

• Principais indicadores de detecção
  • Arquivo: bun_environment.js (script malicioso de post-install)
  • Diretórios: .truffler-cache/, .truffler-cache/extract/
  • Processos: del /F /Q /S "%USERPROFILE%*", shred -uvz -n 1, cipher /W:%USERPROFILE%
  • Comandos: curl -fsSL https://bun.sh/install | bash, powershell -c "irm bun.sh/install.ps1|iex"

Suporte do GitLab para detecção e resposta

• Usuários do GitLab Ultimate podem verificar imediatamente a exposição usando os recursos de segurança integrados
  • Com o Dependency Scanning ativado, pacotes infectados em package-lock.json ou yarn.lock são detectados automaticamente
  • Um alerta é exibido quando uma merge request inclui pacotes infectados
• Também é possível fazer detecção rápida baseada em consultas com o GitLab Duo Chat
  • Exemplo: "Há dependências afetadas pela campanha Shai-Hulud v2?"
  • O Security Analyst Agent consulta os dados de vulnerabilidade do projeto e fornece resposta imediata
• Para equipes que gerenciam vários repositórios, recomenda-se combinar detecção automatizada via CI/CD com resposta rápida baseada em agente

Perspectivas futuras

• Este ataque é avaliado como um novo tipo de ataque à cadeia de suprimentos que usa a destruição de dados da vítima para proteger a infraestrutura do próprio atacante
• O GitLab está colaborando com a comunidade para desenvolver estratégias de recuperação seguras e continua monitorando variantes com sistemas automáticos de detecção
• O objetivo é evitar danos secundários causados pelo dead man's switch por meio do compartilhamento antecipado de informações

[GN⁺]

Comentários do Hacker News

• Há mais ou menos um mês precisei fazer uma tarefa chata e fui procurar um pacote do NPM
  Quando executei brew install npm, caiu uma cascata de dependências; parei por um momento para pensar nos riscos e benefícios e, no fim, voltei atrás com brew uninstall npm
  Em vez disso, resolvi com um antigo pipeline de utilitários Unix e awk, e agora, pensando bem, foi a melhor decisão

  • A lição é clara — não se deve usar tecnologias web para scripts locais
    O NPM foi feito para resolver problemas de compatibilidade de navegador, então traz complexidade desnecessária em ambientes sem navegador
  • É por isso que containerização ou virtualização são necessárias
    Se você executar no sistema principal código de ecossistemas com muitas dependências, como Node ou Python, o risco de ficar exposto a ataques à cadeia de suprimentos é grande
    Por isso, eu nem instalo interpretadores Python ou JS no sistema base
  • Eu também costumava rodar o npm apenas dentro de contêineres Docker, mas frequentemente era motivo de piada em fóruns
    Acabei desistindo, mas agora parece que eu estava certo
  • Tive uma experiência parecida. Vi a quantidade de dependências que o artillery queria puxar e desisti na hora
  • Ironicamente, os desenvolvedores vivem dizendo que “bom senso é a melhor segurança”, mas instalam incontáveis pacotes não verificados com um comando de uma linha

• Alguém disse que “se o GitHub apagar em massa os repositórios maliciosos, milhares de sistemas poderão destruir dados de usuários ao mesmo tempo”,
  o que parece uma situação de reféns — daí surgiu a piada de “atire nos reféns”

  • Mas os reféns (os usuários) meio que entraram no risco por conta própria, então no fim é consequência da própria escolha

• Eu também fui vítima deste ataque no npm
  Fiquei chocado ao descobrir que o GitHub CLI salva tokens OAuth em texto puro no diretório HOME
  Se um invasor conseguisse acesso, poderia fazer praticamente qualquer coisa na minha conta

  • Na verdade, o GitHub CLI só salva o token em texto puro quando não há keyring
    No macOS, ele fica armazenado com segurança no keychain do sistema — discussão relacionada
  • Sim, mas o arquivo de cookies do navegador sofre de um problema parecido
    O Chrome usa mecanismos de proteção do sistema operacional, mas o Firefox ainda não
    No fim, controle de acesso baseado em sandbox é a solução fundamental
  • Todos os tokens deveriam estar em um keychain protegido
    Mas não existe uma solução consistente entre plataformas, e mesmo no MacOS não há um método perfeito
  • Eu também fui vítima. Fui infectado depois de instalar o Backstage
    Um diretório ~/.dev-env foi criado, e meu notebook virou um runner do GitHub
    Talvez o sistema de arquivos somente leitura do Bluefin Linux tenha reduzido os danos

• Todo mundo culpa só o npm, mas a responsabilidade do GitHub também é grande
  Não detectou rapidamente os repositórios maliciosos, e o problema de repositórios com malware já é sério

  • Ainda assim, por ter sido enviado ao GitHub, houve gente que percebeu o problema rapidamente
    Se tivesse sido enviado discretamente para um servidor externo, teria sido muito pior
  • A Microsoft não pode filtrar tudo sozinha
    São necessárias ferramentas e práticas no nível da comunidade
  • Como o GitHub pertence à Microsoft, isso também se cruza com o repositório de pacotes do GoLang
    Se surgirem restrições comerciais ou limitações no workflow de build, isso pode virar um grande problema
  • Não dá para negar que as duas empresas têm um nível de segurança apenas mediano
  • Como esse malware cria repositórios seguindo o mesmo padrão, dava para detectar até com regras simples

• Fiquei me perguntando por que só o NPM vira alvo
  Python e Java também são muito populares, mas recentemente estão mais quietos

  • O NPM permite executar comandos arbitrários com post-install hook e,
    por causa da cultura de dependências com intervalo de versões, a infecção se espalha rapidamente
    Em Java, o normal é fixar versões específicas, então isso acontece menos
  • O Node tem uma biblioteca padrão pequena e alta dependência da comunidade
    Por isso, um pacote acaba puxando dezenas de dependências indiretas
  • JS é a linguagem mais popular no GitHub, então a superfície de ataque é ampla,
    e há muitos desenvolvedores inexperientes, o que enfraquece a segurança
  • A comunidade JS sofre de uma forte “obsessão pela versão mais recente”
    Outros ecossistemas atualizam depois de validar; no JS, fazem upgrade imediatamente
  • O NPM tem fronteiras de segurança fracas
    Durante a instalação, sempre foi possível executar scripts livremente, e isso não acontece da mesma forma no JVM ou no Python

• Se você adicionar em .npmrc

  ignore-scripts=true
  

  pode reduzir o vetor de ataque
  Texto relacionado

  • Fico curioso se existe alguma forma de verificar antes da instalação quais pacotes têm hooks preinstall/postinstall
  • Se “ignore scripts” é seguro, por que isso existe como opção,
    e será que ao desativar não há risco de quebrar dependências?
  • Mas, no fim, se você executar JS num ambiente Node, não dá para impedir acesso a variáveis de ambiente ou arquivos
  • Ou então dá para simplesmente usar pnpm

• O mais preocupante neste ataque é o roubo de credenciais
  Se você instalou um pacote infectado, variáveis de ambiente ou tokens do .npmrc podem ter vazado
  É preciso rotacionar tokens e chaves de API imediatamente
  Rotação periódica não é resposta pós-incidente, e sim medida preventiva

  • Se um desenvolvedor reutiliza senhas, isso é um problema realmente sério
    Credenciais não devem ser guardadas em variáveis de ambiente ou arquivos; use chaves de segurança ou arquivos criptografados
  • Se você não sabe se foi infectado, primeiro deve seguir a ordem detecção da infecção → limpeza → rotação de tokens
  • Este ataque é mais perigoso porque não é apenas uma infecção simples, mas uma forma de fazer todo o ecossistema de refém
    É como inserir transações maliciosas em um livro-razão distribuído
  • Segredos devem ficar obrigatoriamente em um cofre de segredos (secret locker)
    O problema é que muitos serviços ainda usam armazenamento em texto puro como padrão
  • E esse malware ainda tenta destruir dados quando a propagação para

• Fico me perguntando por que, com ataques assim se repetindo, sistemas de detecção baseados em IA não estão funcionando
  A Microsoft fala tanto de IA, mas parece não usar isso na segurança do GitHub

  • Mas dizer que “a IA detectou o ataque” já virou um clichê de marketing de segurança
    Como na época em que toda tentativa bloqueada por firewall era classificada como ataque, o termo foi se esvaziando
  • Na nossa empresa usamos SonaType Lifecycle, que diz bloquear esse tipo de ataque com IA
    Internamente, isso é apoiado pelo SonaType IQ Server
  • A “IA” atual é formada por modelos generativos, então o foco está mais em gerar do que em avaliar
    Houve até um caso em que o projeto curl sofreu com spam de relatórios de segurança gerados por IA

• Fico pensando se ainda existe motivo para continuar permitindo scripts postinstall
  Não seria melhor perguntar ao usuário se deseja executá-los?

  • Mas a maioria dos usuários apertaria “sim”,
    e servidores de CI precisam de instalações não interativas, então isso parece difícil na prática

• O texto foi muito perspicaz, mas foi uma pena terminar com propaganda dos recursos de segurança do GitLab

  • Para usuários do GitLab, talvez tenha sido útil
  • Ainda assim, isso não diminui o valor dos insights do texto