Ataque Megalodon Compromete 5.561 Repositórios do GitHub em Seis Horas
Um ataque à cadeia de suprimentos de CI/CD do GitHub chamado Megalodon estabeleceu um novo parâmetro para comprometimento automatizado e em larga escala de repositórios. Em uma única janela de seis horas, os atacantes enviaram 5.718 atualizações maliciosas de código em 5.561 repositórios do GitHub, usando identidades falsas para injetar arquivos de workflow projetados para extrair silenciosamente credenciais de nuvem, chaves SSH e segredos do código-fonte. A velocidade e o volume do ataque sinalizam uma mudança em direção a ataques industrializados de pipeline que superam a capacidade da maioria das equipes de detectar ou responder em tempo real.
Como o Ataque Megalodon Funcionou: Identidades Falsas e Injeção Automatizada de Workflow
Os atacantes por trás do Megalodon não recorreram a exploits de dia zero nem a malwares sofisticados entregues às máquinas dos usuários finais. Em vez disso, exploraram a natureza confiável da própria infraestrutura de CI/CD do GitHub. Ao construir identidades falsas de contribuidores, eles enviaram pull requests ou modificaram diretamente arquivos de configuração de workflow — especificamente os arquivos YAML que o GitHub Actions utiliza para definir pipelines automatizados de build e implantação.
Quando um arquivo de workflow malicioso é inserido em um repositório, ele é executado automaticamente sempre que o pipeline é acionado, geralmente em eventos de push ou merges de pull requests. Essa execução ocorre dentro do próprio ambiente de runner do GitHub, que frequentemente tem acesso a segredos do repositório, variáveis de ambiente e tokens com escopo para provedores de nuvem. Os workflows do Megalodon usaram essa janela de acesso para exfiltrar dados para fora, provavelmente para uma infraestrutura controlada pelos atacantes, antes que qualquer mantenedor do repositório tivesse motivo para revisar a alteração.
A característica definidora da campanha é sua automação. Executar quase 5.720 envios de código distintos em mais de 5.500 repositórios em seis horas não é um esforço manual. Requer ferramentas com scripts capazes de identificar alvos, autenticar com identidades falsas, criar modificações de workflow com aparência plausível e enviá-las em paralelo. Esse nível de automação significa que a superfície de ataque se expandiu mais rapidamente do que qualquer equipe de monitoramento humano poderia acompanhar.
Quais Credenciais Foram Roubadas e Por Que Isso Importa para os Desenvolvedores
O payload de cada workflow malicioso era a coleta de credenciais. Os alvos incluíam credenciais de provedores de nuvem — mais comumente chaves de acesso da AWS, GCP e Azure armazenadas como GitHub Secrets ou referenciadas dentro de variáveis de ambiente de workflow. Chaves privadas SSH usadas para acesso a servidores ou autenticação entre serviços também estavam no escopo, juntamente com quaisquer segredos em texto simples incorporados no código-fonte ou em arquivos de configuração.
Esses tipos de credenciais carregam riscos em cascata. Uma chave de acesso AWS roubada vinculada a uma função IAM com permissões amplas pode permitir que um atacante inicialize infraestrutura, exfiltre armazenamentos de dados ou se mova lateralmente para serviços conectados em minutos. Chaves SSH podem fornecer acesso persistente a servidores de produção muito tempo depois que a violação original for detectada e o repositório do GitHub for limpo. O valor desses dados vai muito além dos próprios repositórios.
Esse não é um padrão de risco hipotético. No início deste ano, um contratado da CISA expôs chaves AWS e senhas em texto simples em um repositório público do GitHub, demonstrando que o gerenciamento inadequado de credenciais em ambientes de desenvolvimento afeta até organizações com mandatos de segurança dedicados. O Megalodon simplesmente industrializou o mesmo caminho de exploração que erros humanos individuais já demonstraram repetidamente.
Também vale notar que as próprias ferramentas e pipelines de roubo de credenciais são alvos. O recente ataque à cadeia de suprimentos do Bitwarden CLI mostrou que até as ferramentas que os desenvolvedores usam para gerenciar segredos podem ser comprometidas upstream, o que significa que a cadeia de confiança se estende além de qualquer repositório ou configuração de pipeline individual.
Defesa em Profundidade para Equipes de Desenvolvimento: Gerenciamento de Segredos, Comunicações Criptografadas e Controles de Acesso
O Megalodon explorou várias fraquezas comuns tanto em repositórios de código aberto quanto em repositórios privados. Abordá-las requer uma abordagem em camadas, e não um único controle.
Primeiro, segredos nunca devem ser armazenados como texto simples dentro de arquivos de workflow, arquivos de configuração de ambiente ou código-fonte. O recurso de Secrets criptografados do GitHub fornece uma linha de base, mas esses segredos também devem seguir o princípio do menor privilégio. Um workflow que implanta em um ambiente de staging não precisa de credenciais do banco de dados de produção. Limitar o escopo dos segredos reduz o raio de impacto quando um workflow é comprometido.
Segundo, regras de proteção de branch e revisores obrigatórios para alterações em arquivos de workflow criam um ponto de verificação humano que ataques automatizados precisam contornar. Exigir pelo menos uma revisão aprovada antes de qualquer modificação nos arquivos .github/workflows/ pode retardar ou bloquear o tipo de injeção automatizada rápida em que o Megalodon se baseou.
Terceiro, fixar GitHub Actions de terceiros a SHAs de commits específicos, em vez de tags flutuantes, evita um vetor de ataque separado, mas relacionado, no qual publicadores de actions comprometidos atualizam silenciosamente uma tag para apontar para código malicioso. Esse tem sido o mecanismo em vários incidentes recentes na cadeia de suprimentos do GitHub Actions.
Por fim, o registro de auditoria e a detecção de anomalias nas execuções de workflow podem identificar conexões de rede de saída inesperadas ou padrões incomuns de acesso a segredos. A API de log de auditoria do GitHub e ferramentas de segurança de CI/CD de terceiros podem ajudar a identificar esses sinais.
Como Auditar Seus Repositórios do GitHub e Pipelines de CI/CD Agora
Se sua organização mantém repositórios do GitHub com pipelines de CI/CD ativos, algumas etapas imediatas merecem prioridade.
Revise todos os arquivos em .github/workflows/ em busca de entradas adicionadas ou modificadas recentemente, especialmente aquelas adicionadas por contribuidores que você não reconhece. Verifique o histórico de commits especificamente para arquivos de workflow, não apenas a visualização padrão do branch.
Rotacione quaisquer segredos que estavam ativos durante o período do ataque ou que você não pode confirmar com segurança que não foram expostos. Para credenciais de nuvem, revise os logs de acesso do lado do provedor em busca de chamadas de API incomuns durante o mesmo período.
Audite quais contribuidores e aplicações do repositório têm acesso de gravação. Ataques de identidade falsa dependem da capacidade de enviar código, portanto, restringir as permissões de contribuidores e habilitar revisões obrigatórias para alterações de workflow elimina um ponto de entrada fundamental.
Por fim, considere adotar uma ferramenta dedicada de varredura de segredos que seja executada em cada commit, detectando credenciais antes que sejam enviadas a um repositório. Várias opções de código aberto e comerciais se integram diretamente ao GitHub.
O Que Isso Significa Para Você
A campanha Megalodon é uma ilustração prática de por que os pipelines de CI/CD se tornaram uma superfície de ataque primária. Desenvolvedores e equipes de segurança que tratam a segurança de pipelines como secundária em relação à segurança de aplicações estão deixando um caminho completamente aberto para suas credenciais mais sensíveis.
Comece com uma auditoria de segredos esta semana. Revise quem pode modificar seus arquivos de workflow, rotacione credenciais que você não pode verificar como limpas e habilite a proteção de branch no seu branch padrão, caso ainda não tenha feito isso. A velocidade do ataque Megalodon significa que, quando um alerta disparar, a exfiltração pode já ter sido concluída. Prevenção e limitação de escopo de acesso são as únicas defesas confiáveis.
