stnkv-it 34 minutos atrás Ataque aos Repositórios GitHub da Grafana Labs: Como um Ataque à Cadeia de Suprimentos npm Levou ao Roubo da Base de Código e Extorsão Médio 7 min 1.5K DevOps * Segurança da Informação * GitHub * Visão Geral A Cadeia de Suprimentos como Vetor de Ataque Em 11 de maio de 2026, entre 19:20 e 19:26 UTC , ocorreu um dos eventos tecnicamente mais sofisticados na história dos ataques à cadeia de suprimentos npm. O grupo TeamPCP publicou 84 versões maliciosas de pacotes em 42 pacotes do espaço de nomes @tanstack/*
- e tudo isso em seis minutos. A campanha foi chamada de Mini Shai-Hulud
- uma referência aos gigantescos vermes de areia do universo "Duna" de Frank Herbert. Esta não é a primeira onda de atividade do TeamPCP: antes disso, eles comprometeram o scanner Trivy da Aqua Security em março de 2026 e o pacote npm Bitwarden CLI em abril de 2026. Cada onda subsequente é tecnicamente mais complexa que a anterior. Como o ataque funcionou: três vulnerabilidades em uma cadeia O ataque combinou três vulnerabilidades, cada uma das quais, por si só, seria insuficiente. O invasor criou um fork do repositório TanStack/router, abriu um pull request, que iniciou um workflow com o gatilho pull_request_target , e envenenou o cache do GitHub Actions através da fronteira de confiança fork↔base. Quando o workflow legítimo foi executado, o cache envenenado foi restaurado, e o código malicioso extraiu o token OIDC diretamente da memória do processo runner. O ponto-chave: os invasores não roubaram tokens npm estáticos. Em vez disso, eles extraíram tokens OIDC de tempo de execução diretamente da memória do processo runner, o que lhes permitiu autenticar de forma legítima através de trusted publisher bindings e publicar atualizações comprometidas no registro npm. A escala da infecção Até o final do dia, mais de 170 pacotes comprometidos foram documentados em npm e PyPI, incluindo Mistral AI, UiPath, OpenSearch e Guardrails AI. Uma arquitetura tripla de C2 foi usada para exfiltração: o domínio typosquatting git-tanstack.com, a rede descentralizada Session messenger e os dead drops da API do GitHub, onde os tokens roubados criaram repositórios com nomes do universo "Duna". É notável que este seja o primeiro caso documentado em que pacotes npm maliciosos continham proveniência SLSA válida - um certificado criptográfico gerado pelo Sigstore e projetado para confirmar que o pacote foi compilado de uma fonte confiável. Em outras palavras, as ferramentas de verificação de autenticidade provaram ser inúteis. Abaixo, apresento a mensagem oficial da equipe Grafana Labs, publicada hoje (19 de maio de 2026). Ela é reproduzida na íntegra, pois é um exemplo exemplar de comunicação transparente com a comunidade em uma situação de crise. Se alguém estiver interessado, você pode se familiarizar com sua mensagem no link: https://grafana.com/blog/grafana-labs-security-update-latest-on-tanstack-npm-supply-chain-ransomware-incident/?pg=blog Em 16 de maio de 2026, a Grafana Labs confirmou um ataque direcionado de um grupo de cibercriminosos que obteve acesso não autorizado aos nossos repositórios GitHub e baixou nossa base de código. Os invasores então exigiram um resgate, ameaçando publicar os dados. Desde a publicação de nossas descobertas iniciais, a investigação continuou, e estamos publicando este material para compartilhar informações mais detalhadas sobre as medidas de resposta e as etapas tomadas para mitigar as consequências. Um relatório completo sobre os resultados da investigação será publicado após sua conclusão. Até o momento, a investigação não revelou nenhuma evidência de comprometimento dos sistemas de produção ou das operações dos clientes. O incidente foi estritamente limitado ao ambiente GitHub da Grafana Labs e não afetou nossos sistemas de produção ou a plataforma Grafana Cloud. Após a avaliação inicial, descobrimos que, além do código-fonte, o conteúdo baixado incluía repositórios GitHub que algumas equipes da Grafana Labs usam para colaboração e armazenamento de informações operacionais internas e outros detalhes sobre nossas atividades. Isso inclui nomes de contato comercial e endereços de e-mail que teriam sido transmitidos no contexto de relacionamentos profissionais - mas não informações obtidas de sistemas de produção ou processadas através da plataforma Grafana Cloud. Para usuários de projetos de código aberto da Grafana Labs e da plataforma Grafana Cloud: nossa base de código foi baixada, mas não foi alterada. Nenhuma ação é atualmente necessária de nossos clientes ou usuários de soluções de código aberto. A investigação continua: continuamos a examinar logs, telemetria e todos os dados disponíveis nos repositórios GitHub da empresa. Se alguma vez determinarmos que os sistemas ou operações de qualquer cliente foram afetados, notificaremos o cliente diretamente. Na Grafana Labs, conquistar e manter a confiança da comunidade é a base de tudo o que fazemos. Entendemos que os clientes confiam em nós como um parceiro confiável, e não levamos essa responsabilidade levianamente. Estamos publicando esta atualização em um espírito de transparência, porque entendemos que você pode ter perguntas, e levamos esta situação a sério. Resumo e histórico O incidente se originou em um ataque à cadeia de suprimentos npm TanStack como parte da campanha Mini Shai-Hulud. Detectamos atividade maliciosa em 11 de maio e iniciamos imediatamente um plano de resposta a incidentes. Realizamos uma análise e rotacionamos rapidamente um número significativo de tokens de workflow do GitHub, mas um token perdido permitiu que os invasores acessassem nossos repositórios GitHub. Uma verificação subsequente confirmou que um workflow específico do GitHub, que inicialmente pensávamos não ter sido afetado, foi de fato comprometido. Em 16 de maio, recebemos uma demanda de resgate dos invasores em troca da não divulgação de nossa base de código. A Grafana Labs decidiu não pagar o resgate. Esta decisão está de acordo com a posição oficial do FBI: o pagamento de resgate não garante segurança e apenas estimula atividades criminosas adicionais. Assim que recebemos contato dos extorsionários, começamos imediatamente a tomar medidas para mitigar as consequências, que incluíram a rotação de tokens de automação, a implementação de monitoramento aprimorado, a auditoria de todos os commits desde o incidente de 11 de maio e um fortalecimento significativo da proteção do GitHub. Também notificamos as autoridades federais e manteremos um diálogo constante com elas sobre esta situação. A escala do incidente e as medidas tomadas As descobertas atuais indicam que a escala do incidente é limitada aos repositórios GitHub da Grafana Labs, que incluem código-fonte público e privado, bem como repositórios GitHub internos. Não há evidências de comprometimento dos sistemas de produção ou das operações dos clientes. Como parte de nossas práticas de segurança padrão, compartilharemos informações adicionais de nossa revisão pós-incidente após a conclusão da investigação. A Grafana Labs também está tomando medidas para fortalecer a segurança para proteger nossos sistemas. Atualmente, estamos implementando medidas em larga escala para proteger ainda mais nossos pipelines CI/CD (integração contínua e implantação contínua) e evitar a repetição de incidentes semelhantes. Nossas equipes estão focadas em continuar a investigação e implementar controles de segurança aprimorados Etapa 1: Fork e Inserção de Código Malicioso O ataque começou de forma padrão para o ecossistema de código aberto: o invasor criou um fork do repositório público da Grafana - uma ação que parece completamente inofensiva. Em seguida, uma solicitação maliciosa curl foi inserida no fork. Quando um workflow vulnerável com o gatilho pull_request_target foi executado, ele executou um comando dentro do ambiente CI confiável - isso permitiu que o invasor despejasse variáveis de ambiente e extraísse um token GitHub privilegiado. Etapa 2: Token Canary como Detector de Intrusão A intrusão foi detectada porque um dos milhares de tokens canary que a Grafana espalhou por todo o seu ambiente foi ativado - esta é uma credencial falsa intencionalmente inserida, projetada para emitir um sinal de alarme no momento em que alguém a toca. Esta solução provou ser fundamental. Quando o invasor estava coletando segredos do ambiente de build comprometido, ele pegou uma dessas "iscas", e o sinal disparou. A comunidade reagiu com uma pitada de ironia: a empresa que vende ferramentas de observabilidade para o mundo inteiro se salvou graças à técnica de observabilidade. Etapa 3: Exfiltração e Extorsão Após baixar o código, o invasor passou para a extorsão, exigindo pagamento em troca da não divulgação dos repositórios. O grupo CoinbaseCartel, supostamente uma ramificação dos ecossistemas ShinyHunters, Scattered Spider e LAPSUS$, colocou a Grafana em seu site de vazamento na dark web - mas, no momento da publicação, o código roubado não foi publicado. "Pwn Request" - uma vulnerabilidade que não foi embora A causa raiz foi rastreada até uma GitHub Action recém-habilitada, contendo uma vulnerabilidade do tipo "Pwn Request" - uma configuração incorreta no workflow, executada pelo evento pull_request_target , que fornecia aos contribuidores externos acesso a segredos de produção durante as execuções de CI. Este padrão foi documentado pelo GitHub Security Lab por anos. Uma campanha, rastreada pela Wiz Research entre março e abril de 2026, usou pull requests gerados por IA para abrir mais de 500 envios maliciosos em centenas de repositórios, visando a mesma vulnerabilidade. O que você precisa verificar agora Se você mantém repositórios GitHub públicos ou privados com pipelines CI/CD, aqui está uma lista de verificação mínima:
- Auditoria de arquivos de workflow: Abra o diretório .github/workflows e encontre todos os arquivos que usam pull_request_target . Certifique-se de que o workflow não faça checkout e não execute código do pull request diretamente.
- Rotação de tokens: Se sua equipe instalou alguma das versões afetadas @tanstack/* em 11 de maio, gire as credenciais AWS, GCP, Kubernetes, Vault, GitHub, npm e SSH disponíveis no host de instalação.
- Verificação de persistência: Verifique a presença do daemon de persistência no caminho ~/Library/LaunchAgents/ com.user.gh -token-monitor.plist no macOS ou ~/.config/systemd/user/gh-token-monitor.service no Linux e exclua-o antes de revogar quaisquer tokens.
- Bloqueio da infraestrutura C2: No nível DNS ou proxy, bloqueie git-tanstack.com , *. getsession.org e 83.142.209.194 .
- Implemente tokens canary: Se você gerencia uma organização privada, considere colocar seus próprios tokens canary em ambientes de build: é para este cenário que eles existem - e o incidente com a Grafana mostra que eles funcionam. Parte V: Lições e Conclusões Transparência como um ativo estratégico A Grafana Labs fez algo raro: a divulgação pública foi lançada no mesmo dia da demanda de resgate - este é um sinal intencional da relutância da empresa em entrar em negociações. A maioria das empresas prefere pagar silenciosamente ou ganhar tempo. A Grafana escolheu outro caminho - e isso fortaleceu, em vez de minar, a confiança da comunidade. A recusa em pagar o resgate é a única decisão correta A posição da Grafana Labs está de acordo com a posição do FBI e da maioria dos reguladores: o pagamento do resgate não garante a recuperação dos dados e apenas financia os próximos ataques. O CoinbaseCartel, desde setembro de 2025, já tem mais de 170 vítimas nos setores de tecnologia, saúde, manufatura e transporte. Cada pagamento é uma contribuição para a expansão dessa infraestrutura. Conclusão O incidente com a Grafana Labs não é uma história sobre a falha de uma empresa. É uma história sobre uma vulnerabilidade sistêmica que está presente em milhares de repositórios agora mesmo. Os invasores não quebraram senhas nem fizeram phishing com funcionários - eles usaram um padrão documentado, publicamente conhecido, no GitHub Actions, que a maioria das equipes simplesmente não verificou. A Grafana Labs respondeu corretamente: detectou rapidamente (tokens canary), divulgou rapidamente (no mesmo dia), se recusou a pagar (a decisão correta) e entrou em diálogo com as autoridades policiais. Este é um exemplo de comunicação de crise em segurança cibernética. A questão não é se algo semelhante acontecerá com sua organização. A questão é se você o descobrirá antes que os invasores terminem de baixar seus dados. Tags: devsecops devops grafana github segurança da informação github actions cibersegurança npm ransomware cadeia de suprimentos
Hubs: DevOps Segurança da Informação GitHub +1 3 0 16K+ Alcance em 30 dias 1 Karma Nikita Sotnikov @stnkv-it Usuário Assinar Fluxo Segurança da Informação disponível 24 horas por dia, 7 dias por semana, graças ao apoio de amigos do Habr Habr Cursos para todos PUBLICIDADE Prática, Hexlet, SkyPro, cursos do autor - reunimos todos e pedimos descontos. Resta escolher! Ir Ir para o fluxo Segurança da Informação Comentar Melhor do dia Semelhante Mostrar o melhor de todos os tempos
