GitHub sob ataque: 4.837 contas comprometidas expõem segredos em pipelines de desenvolvimento

O ataque wfx-loot usou contas legítimas de desenvolvedores para colocar pipelines de automação sob pressão. O alvo eram segredos que conectam código, publicações de pacotes e contas de nuvem. E a escala da operação expõe um velho problema disfarçado de conveniência: permissões demais no lugar errado.

O ataque não começou com um commit espetacular

A nova campanha batizada de wfx-loot ilustra uma das situações mais perigosas para quem depende de código hospedado no GitHub: o invasor não precisa controlar o serviço inteiro quando consegue usar credenciais legítimas de desenvolvedores. Segundo a investigação da Aikido, os operadores reuniram acesso a 4.837 contas e passaram a testar permissões em 61.764 repositórios. O volume impressiona, mas a técnica importa mais que o número: a confiança foi usada como arma contra os próprios mecanismos de automação.

Em vez de um pacote com nome obviamente suspeito, surgiam pull requests aparentemente banais, apresentados como notas de auditoria de dependências. O título era genérico o suficiente para passar despercebido entre dezenas de tarefas comuns de manutenção. O objetivo real, porém, era encontrar locais onde uma mudança pudesse executar código durante um workflow, sem precisar comprometer diretamente cada servidor de produção.

Por que o GitHub Actions se tornou o alvo

O GitHub Actions é a ferramenta de automação que permite testar aplicações, compilar projetos, publicar pacotes e realizar implantações. Por definição, esses processos muitas vezes recebem credenciais para acessar outros serviços. Um job que precisa publicar uma imagem Docker ou atualizar um ambiente de nuvem trabalha perto de chaves, tokens e permissões que seriam valiosos para qualquer invasor.

Os pesquisadores descrevem um script de aproximadamente 1.500 linhas destinado a buscar segredos em variáveis de ambiente, arquivos de configuração, tokens de execução e credenciais usadas por ferramentas de desenvolvimento. Não se limitava a uma conta de GitHub: o alvo potencial incluía AWS, Azure, Google Cloud, registries de pacotes, ambientes Kubernetes e ferramentas de infraestrutura. Também foram procurados segredos de serviços de inteligência artificial, o que mostra como a superfície de exposição cresceu com as integrações de desenvolvimento.

Quase cinco mil contas não significam cinco mil empresas invadidas

É importante separar as métricas. As 4.837 contas foram usadas para sondar 61.764 repositórios, enquanto a pesquisa reporta roubo de segredos em pelo menos 1.835 alvos. Não há base para concluir que todos os repositórios examinados executaram o payload ou que cada conta comprometida representa uma organização diferente. A campanha combinou escala de varredura com execução oportunista.

Algumas contas associadas a organizações grandes apareceram entre as comprometidas, mas isso não comprova comprometimento completo dessas organizações. O risco aumenta quando identidades individuais têm acesso amplo a repositórios, permissões de publicação ou serviços que aceitam tokens obtidos durante a automação. A confiança depositada em uma conta também precisa ser proporcional ao que ela realmente precisa fazer.

A operação foi pensada para desaparecer

Segundo os pesquisadores, os invasores injetavam etapas em workflows existentes, criavam workflows temporários ou exploravam ganchos de instalação npm. Quando a execução produzia credenciais, o material era compactado e enviado a destinos controlados pelos atacantes. Depois, parte das alterações e registros era apagada rapidamente, em uma tentativa de reduzir os rastros visíveis.

É o tipo de incidente que não se resolve apenas pesquisando commits suspeitos na branch principal. Uma inspeção séria envolve o histórico de pull requests, eventos de workflow, permissões de tokens, logs de provedores externos e possíveis alterações nas políticas de identidade. Em casos assim, a ausência de um arquivo malicioso atual não prova que uma credencial não tenha sido copiada horas antes.

Como reduzir a exposição sem paralisar o desenvolvimento

A resposta começa com a revisão das contas afetadas e das sessões autorizadas. Tokens potencialmente alcançados por workflows suspeitos precisam ser revogados ou rotacionados, incluindo credenciais de nuvem, registries e automações. É necessário analisar a origem das mudanças executadas, restringir a execução de código vindo de contribuições externas e aplicar o princípio de menor privilégio aos GITHUB_TOKEN e às identidades federadas.

Também vale revisar regras de aprovação de pull requests, ambientes protegidos e a diferença entre jobs que apenas testam código e jobs que publicam pacotes. Segredos de produção não devem circular em tarefas que só precisam executar testes. Em runners autogerenciados, o cuidado deve ser maior: a máquina pode ter acesso a credenciais e metadados que não aparecem nos arquivos do repositório.

Para equipes pequenas, a tentação costuma ser deixar uma credencial poderosa resolver tudo. Funciona até o dia em que a automação executa código não confiável. O custo operacional de dividir permissões é menor que o de descobrir tarde demais que um token usado para compilar uma biblioteca também podia administrar recursos de nuvem.

O risco para o ecossistema open source

O relatório cita publicações de pacotes afetadas por mecanismos de publicação automática. Esse detalhe é especialmente preocupante porque o incidente pode ultrapassar o repositório de origem: se uma automação comprometida distribui um artefato, usuários de outros projetos podem baixar algo que jamais avaliaram. A cadeia de suprimentos depende de muitos elos silenciosos, e uma assinatura conhecida no GitHub não garante sozinha que o processo de build tenha sido seguro.

Há uma diferença entre uma falha de segurança no GitHub como plataforma e o abuso de contas e automações dentro dele. O caso relatado é do segundo tipo. Culpar apenas o serviço de hospedagem obscurece as decisões de projeto, as permissões exageradas e os segredos que precisam de controles em camadas.