1 pontos por GN⁺ 2025-04-01 | 1 comentários | Compartilhar no WhatsApp
  • Devido a uma chave secreta (Secret) pública do GitHub, o CodeQL, ferramenta de análise estática do GitHub, ficou exposto a um ataque à cadeia de suprimentos
  • A chave em questão foi válida por 1,022 segundo e, nesse intervalo, um invasor podia executar código arbitrário em workflows do GitHub Actions
  • Essa vulnerabilidade foi registrada como CVE pública: CVE-2025-24362

Principais cenários de impacto

Por meio dessa vulnerabilidade, um invasor poderia executar os seguintes ataques:

  • Vazamento do código-fonte de repositórios que usam CodeQL (violação de propriedade intelectual)
  • Roubo de chaves secretas do GitHub Actions e possibilidade de ataques secundários
  • Execução de código na infraestrutura interna por meio de workflows do CodeQL
  • Possibilidade de roubo até mesmo de chaves secretas de workflows que usam GitHub Actions Cache

Detecção do ataque e processo experimental

  • A equipe de pesquisa da Praetorian desenvolveu uma ferramenta para escanear chaves secretas incluídas em artefatos de workflow gerados no GitHub Actions
  • Foi encontrado um artifact de debug contendo chave secreta em repositórios relacionados ao CodeQL
  • Foi criado e executado o PoC artifact_racer.py, que comprovou que um invasor podia criar branch/tag e fazer push de arquivos enquanto a chave estivesse válida

Principais resultados do experimento

  • Com esse token, o invasor podia:
    • criar uma nova branch
    • fazer push de arquivos
    • adicionar tags
  • O CodeQL faz referência por padrão à tag v3, e o invasor podia sobrescrevê-la → seria possível distribuir código malicioso para todos os usuários do CodeQL

Potencial de propagação: por que isso é perigoso?

  • A maioria dos usuários não configura o CodeQL manualmente; apenas clica no botão "Enable CodeQL" nas configurações do repositório do GitHub
  • O workflow configurado automaticamente nesse momento referencia o repositório github/codeql-action e é baseado na tag v3
  • Se um invasor sobrescrever a tag v3 com um commit malicioso, código malicioso poderá ser executado automaticamente em inúmeros projetos

Possibilidade adicional de ataque: envenenamento de cache (Cache Poisoning)

  • O workflow padrão do CodeQL usa GitHub Actions Cache
  • Com isso, um invasor pode injetar cache malicioso no pipeline de build e, em workflows posteriores, roubar chaves secretas e obter acesso interno
  • Principais alvos afetados:

Resposta e patch do GitHub

  • Após o relato da vulnerabilidade em 22 de janeiro de 2025, o GitHub, em até 3 horas:
    • interrompeu os workflows vulneráveis
    • abriu um PR para impedir o upload de chaves secretas
    • lançou a versão corrigida: CodeQL Action v3.28.3
  • Aviso oficial de segurança: GHSA-vqf5-2xx6-9wfm

Medidas de resposta

  • Ao fazer upload de artefatos em workflows, restrinja os arquivos enviados
  • Tenha cuidado ao incluir variáveis de ambiente, .git/config e arquivos dentro do diretório _temp/
  • Conceda ao GITHUB_TOKEN somente permissão de leitura
  • Recomenda-se realizar varredura de chaves secretas antes do upload (usando ferramentas como Nosey Parker)

Conclusão

  • Mesmo com a configuração padrão do CodeQL, inúmeros projetos podem ficar expostos a ataques à cadeia de suprimentos
  • As vulnerabilidades de segurança no GitHub Actions continuam sendo uma ameaça séria, exigindo atenção contínua da comunidade e estratégias de defesa

Informações relacionadas

1 comentários

 
GN⁺ 2025-04-01
Comentários do Hacker News
  • Há quem diga que o lançamento de ações imutáveis do GitHub poderia resolver mais de 70% dos ataques
    • Acham que os problemas semanais do GitHub vão acabar forçando esse lançamento
  • Não há menção ao motivo de um token temporário ter permissão para criar uma nova implantação e gerar comprovação de artefato
    • Desativaram os logs de depuração para resolver o problema, mas não há resposta sobre se as permissões do token temporário foram alteradas para algo mais adequado a um mecanismo de análise de código
  • Há uma convicção crescente de que CI e CD deveriam ser ambientes totalmente separados
    • Um comprometimento no CI não deveria levar ao vazamento de tokens relacionados ao CD
  • O tempo de resposta do GitHub foi bastante impressionante
  • Há quem diga que, sendo uma pessoa de sobrenome Prater, gostaria de ser dono de praetorian.com
  • Usar ações públicas do GitHub pode causar problemas, e usá-las sem analisar os procedimentos do workflow é ainda mais arriscado
    • Em vez disso, recomendam usar o woodpecker ou outro ótimo construtor de CI (circle, travis, gitlab etc.) com hospedagem própria
  • Mencionam que usam CodeQL no PR do OpenZFS e que não houve problema no OpenZFS
    • O código do OpenZFS não é segredo
  • Há quem pergunte se o problema já foi resolvido
  • Há reclamações de que o desempenho do site está tão ruim que quase não dá para rolar a página