Ataque Gheist Rouba Tokens do GitHub: Proteja Seu Repo
Ataque Gheist GitHub usa tokens roubados para furtar credenciais de repositorios. Veja os indicadores e como o dev indie protege o projeto e os secrets.
Pesquisadores da Wiz identificaram uma campanha de ataque chamada Gheist que usa tokens roubados do GitHub para comprometer repositorios e furtar credenciais. A operacao nao explora uma falha nova da plataforma: ela entra com um token que ja foi vazado e, de dentro, injeta um workflow malicioso do GitHub Actions chamado "sync-check" que extrai dados usando a propria API do GitHub. Ate agora a campanha ja criou mais de 13.500 branches maliciosas em mais de 850 contas comprometidas.
O ponto mais importante para quem usa o GitHub todo dia e entender que o Gheist nao precisa invadir a plataforma. Ele se aproveita de um token que vazou em algum lugar (um commit antigo, um arquivo de configuracao esquecido, uma variavel de ambiente exposta) e usa esse acesso legitimo para agir. Para o GitHub, as acoes parecem vir de voce, porque tecnicamente estao usando a sua credencial.
Como o ataque funciona na pratica
O fluxo e direto. Com o token em maos, o atacante cria uma branch nova no seu repositorio e coloca nela o arquivo .github/workflows/sync-check.yml. Esse arquivo e um workflow do GitHub Actions, ou seja, um script que o proprio GitHub executa automaticamente quando certas condicoes acontecem. O workflow entao usa a API do GitHub para ler e exfiltrar o que encontrar: outros secrets, chaves e dados do repositorio.
Repare no detalhe perverso. O GitHub Actions existe para automatizar tarefas boas, como rodar testes ou publicar um build. O Gheist sequestra esse mesmo mecanismo para automatizar o roubo. Nao e um malware que voce baixou, e uma automacao rodando dentro da infraestrutura confiavel do GitHub, com a sua assinatura.
Os indicadores que entregam a presenca do Gheist
Se voce quer checar se foi atingido, a campanha deixa rastros especificos. Vale olhar com calma:
- Branches com o prefixo
ci-sync-seguido de 6 caracteres. Se aparecer uma branch com esse padrao que voce nao criou, acenda o alerta. - O arquivo
.github/workflows/sync-check.ymlno repositorio. Se ele existe e nao foi voce quem colocou, e sinal claro. - Atividade ligada ao identificador de cliente "gheist" nos registros de acesso.
Esses tres sinais juntos nao deixam duvida. Mas o passo seguinte e onde muita gente erra, e e justamente o que mais importa.
Apagar a branch nao resolve
O instinto de todo mundo ao ver uma branch estranha e apagar a branch e o workflow e seguir a vida. Com o Gheist isso e um erro. Apagar a branch ou o workflow malicioso NAO reverte a exposicao. No momento em que o workflow rodou, os seus secrets ja foram lidos e enviados para fora. A branch e so o veiculo, nao o estrago.
A protecao recomendada pela Wiz tem duas partes obrigatorias. Primeiro, revogar os tokens comprometidos, para cortar o acesso que originou tudo. Segundo, e isso e inegociavel, trocar TODOS os secrets do repositorio: chaves de API, senhas, tokens de servicos integrados. Qualquer segredo que estava la precisa ser considerado vazado e substituido. Se voce so apaga a branch, o atacante continua com as chaves que ja copiou.
Por que isso importa para quem faz jogo indie no Brasil
Talvez voce esteja pensando que isso e assunto de empresa grande, de time de seguranca. Nao e. Muito dev de jogo indie guarda o projeto inteiro no GitHub: o repositorio Godot ou Unity, os assets, e, com frequencia, chaves de API de servicos que o jogo usa (um backend de ranking, uma integracao de analytics, uma credencial de loja). Se um token seu vazar, um ataque como o Gheist nao diferencia um estudio grande de um dev solo. Ele vai atras de qualquer repositorio ao alcance daquele token.
A boa noticia e que as medidas de reducao de risco sao simples e voce aplica hoje, sem ser especialista:
- Nao commite secrets. Chave de API, senha ou token nunca vai dentro do codigo nem de um arquivo versionado. Use o
.gitignorepara manter arquivos sensiveis fora dos commits. - Use os Secrets do GitHub. Para o que o seu workflow precisa acessar, guarde nos Secrets do proprio repositorio, que ficam criptografados e nao aparecem no codigo.
- Revise Actions de terceiros. Antes de adicionar um workflow que voce copiou de algum lugar, leia o que ele faz. Um
.ymlque voce nao entende e um risco que voce aceitou sem saber. - Ative o 2FA. A autenticacao em dois fatores dificulta o sequestro da sua conta mesmo que uma senha vaze.
- Tokens de escopo minimo. Quando criar um token de acesso pessoal, de a ele so as permissoes que a tarefa exige e um prazo de validade curto. Token de poder total e vida eterna e exatamente o que o Gheist adora encontrar.
Se voce esta montando agora o seu fluxo de versionamento, o momento de acertar a mao e esse. Vale seguir um passo a passo de como subir o seu projeto Godot no GitHub com o .gitignore configurado desde o primeiro commit, porque evitar que o segredo entre no repositorio e muito mais barato do que limpar a bagunca depois.
Seguranca de repositorio nao e paranoia, e higiene. O Gheist mostra que basta um token esquecido para transformar o backup do seu jogo em porta de entrada. Guardar o projeto na nuvem continua sendo a decisao certa. Guardar com secrets soltos no meio do codigo e que nao e.
