Gheist: mascarar logs não substitui controlar quem acessa segredos no CI

A Wiz acompanha uma campanha que usa tokens GitHub roubados para criar branches ci-sync- seguidas por seis caracteres e incluir o workflow .github/workflows/sync-check.yml.[2] A análise recuperou mais de 13.500 branches em mais de 850 contas comprometidas e registrou execução bem-sucedida em repositórios privados e ambientes GitHub Enterprise.[2]

O detalhe importante para desenvolvimento é a fronteira entre escrever código de automação e receber segredos. Tratar um workflow como arquivo comum do repositório ignora que ele pode definir o que um processo privilegiado fará.

O que muda para quem desenvolve

O workflow converte segredos em base32, imprime o resultado nos logs e permite que o atacante os baixe pela API do GitHub antes de apagar as execuções.[2] A transformação contorna o mascaramento por correspondência literal, sem exigir um servidor externo de exfiltração.[2] Um bloco de permissões vazio restringe o GITHUB_TOKEN do job, mas não impede a leitura de segredos entregues ao workflow.[2]

A conclusão de arquitetura é direta: reduzir uma credencial não equivale a reduzir todas as capacidades do processo. A revisão deve separar permissões do token do job, segredos disponibilizados, identidades cloud e acesso do runner. Uma configuração restritiva em um desses planos não comprova proteção nos demais.

Como aplicar

Monte uma matriz para cada pipeline de implantação: quem pode alterar o workflow, quem aprova sua execução, quais segredos ele recebe e quais recursos externos pode alcançar. Priorize os pontos em que a mesma identidade consegue modificar a automação e liberar credenciais de produção.

Para um exercício verificável, use um repositório de demonstração e um valor fictício, sem conexão com produção. Compare dois jobs: um sem acesso ao valor e outro que o recebe explicitamente. Observe o que cada processo consegue ler e registre a decisão de autorização. O objetivo não é desenvolver novas formas de esconder dados, mas comprovar que a restrição está na entrega do segredo.

Inclua na revisão regras OIDC por origem e branch, aprovação dos ambientes críticos e descarte do runner após o trabalho. São recomendações de contenção, não evidência de que um repositório específico esteja comprometido.

Cuidados e limites

Todos os exemplos públicos examinados pela Wiz ficaram retidos por aprovação de execuções suspeitas; a reportagem ressalta que essa cobertura não se estende a repositórios privados nem ao GitHub Enterprise Server.[2] A variante que procura credenciais em runners próprios foi descrita como defeituosa, sem execução bem-sucedida relatada nessa etapa.[2]

A quantidade de contas e branches não informa quantas organizações tiveram segredos efetivamente expostos.[2] Havendo comprometimento, a orientação reportada inclui revogar o token de origem, rotacionar segredos acessíveis e avaliar o runner.[2] Apagar o YAML não deve ser confundido com encerrar a resposta ao incidente.

Fonte

[2] Fonte: The Hacker News