Uma campanha automatizada atingiu 61 repositórios públicos do GitHub em menos de uma hora. O levantamento é da empresa de segurança Radware, que contou pelo menos 83 investidas contra projetos usados por milhares de organizações. O alvo foram os fluxos de automação desses projetos, e não o código principal.
Quase tudo aconteceu numa janela de 43 minutos, em 1º de setembro. Nesse intervalo, os invasores publicaram 67 itens maliciosos, e outros seis apareceram logo depois. Esse volume, num prazo tão curto, é sinal de ataque disparado por script, sem ninguém digitando manualmente.
Como o ataque funcionava
Os criminosos abriam issues e pull requests, ou deixavam comentários, em projetos de terceiros. Dentro desses textos havia comandos maliciosos escondidos em marcações de comentário HTML. Na página do GitHub, quem lia não via nada de estranho, porque esse tipo de marcação não aparece na renderização. As ferramentas que processam o texto bruto da contribuição, porém, recebiam o conteúdo inteiro, com os comandos.
O risco está nos workflows que reagem sozinhos a novas issues ou pull requests. Muitos projetos usam automações para classificar contribuições, rodar testes ou responder a quem abriu o pedido. Se uma dessas rotinas usar o texto enviado por um desconhecido sem filtro, o atacante consegue executar instruções no ambiente do projeto. Em alguns casos, esse ambiente tem acesso a tokens e chaves de publicação.
O que os pesquisadores recomendam
Babo, um dos pesquisadores ouvidos sobre o caso, defende que todo conteúdo vindo de fora seja tratado como não confiável e que o acesso a segredos e variáveis sensíveis seja restrito ao mínimo necessário. Gabi Nakibly vai além: para ele, a única defesa real é escrever o código dos workflows de forma que esse tipo de entrada não consiga alterar o comportamento deles.
Na prática, a revisão é trabalho de quem mantém o projeto. Esconder issues suspeitas depois que o workflow já rodou não adianta. O ponto de correção é a configuração das automações.
Por que isso afeta quem está no Brasil
Startups, bancos, órgãos públicos e desenvolvedores independentes no país dependem de bibliotecas abertas hospedadas no GitHub. Quando um projeto popular tem seus segredos expostos, o invasor pode publicar uma versão adulterada do pacote, e essa versão chega a quem só rodou uma atualização de dependências. Quem mantém repositório público com GitHub Actions deve revisar hoje quais workflows são acionados por issues, pull requests e comentários de terceiros e quais segredos ficam disponíveis nessas execuções.
A Radware não divulgou a lista dos 61 repositórios afetados nem informou se algum segredo chegou a vazar. O ataque principal ocorreu em 1º de setembro e durou 43 minutos.
