Amazon corrige falha crítica que poderia ter comprometido 66% dos ambientes cloud do mundo

Uma vulnerabilidade crítica no serviço CodeBuild da Amazon Web Services (AWS) colocou em risco 66% de todos os ambientes cloud do mundo. A falha, descoberta pela empresa de segurança Wiz e batizada de “CodeBreach”, foi corrigida em setembro de 2024, antes que criminosos ou agências governamentais pudessem explorá-la para desencadear um ataque à cadeia de suprimentos potencialmente maior que o infame incidente SolarWinds de 2020.

A diferença entre segurança digital e catástrofe global? Apenas dois caracteres faltando em uma expressão regular: “^” e “$”.

Como a vulnerabilidade foi descoberta

A equipe de pesquisadores da Wiz começou a investigar o pipeline de integração contínua da AWS após detectar uma tentativa de ataque à cadeia de suprimentos na extensão Amazon Q para VS Code.

Os pesquisadores identificaram que o CodeBuild, serviço de integração contínua da AWS que se conecta a repositórios GitHub, usava filtros de webhook para controlar quem poderia acionar compilações automáticas. Um desses filtros, chamado ACTOR_ID, funcionava como lista de permissões com IDs de usuários GitHub confiáveis.

O problema crítico estava nas expressões regulares usadas para validar esses IDs – elas não tinham “âncoras”, ou seja, faltavam os símbolos ^ (início) e $ (fim) que garantem correspondência exata. Na prática, isso significava que qualquer ID que contivesse um ID aprovado passava pelo filtro de segurança.

Ataque provou ser surpreendentemente simples

A equipe da Wiz não apenas descobriu a vulnerabilidade, eles provaram que poderia ser explorada com relativa facilidade. Os pesquisadores automatizaram a criação de 200 aplicativos de automação no GitHub, cada um gerando um ID único atribuído sequencialmente pela plataforma.

Era uma questão de probabilidade: eventualmente, um desses IDs conteria o ID de um mantenedor confiável da AWS. E funcionou. Em questão de horas, eles tinham um ID malicioso que passava pelos filtros de segurança.

O próximo passo foi criar uma proposta de mudança no código aparentemente legítima para corrigir um problema menor no repositório. Escondido nas dependências havia um pacote projetado para executar durante o processo de compilação e extrair credenciais GitHub.

O CodeBuild detectou o pull request, verificou o ACTOR_ID, que passou no filtro vulnerável, iniciou a compilação automaticamente e executou o script malicioso – que roubou as credenciais GitHub com privilégios administrativos.

Repositórios críticos estavam vulneráveis

A falha afetava quatro repositórios essenciais da AWS, sendo o mais preocupante o AWS SDK for JavaScript (aws-sdk-js-v3). Com aproximadamente 15 milhões de downloads semanais e presente em 66% de todos os ambientes cloud globalmente, esse SDK é usado por praticamente todo serviço AWS que roda JavaScript.

Os outros repositórios comprometidos eram AWS Libcrypto (biblioteca de criptografia), Amazon Corretto Crypto Provider e Registry of Open Data on AWS.

O SDK JavaScript é especialmente crítico porque está presente até mesmo no AWS Console – a interface de gerenciamento que administradores usam para controlar infraestruturas inteiras. Se o SDK fosse comprometido em um ataque real, criminosos teriam acesso ao “sistema nervoso central da nuvem”.

Impacto seria maior que SolarWinds

Em 2020, o SolarWinds comprometeu cerca de 18.000 clientes corporativos através do software Orion, dando a atacantes acesso a redes internas de empresas e agências governamentais. O ataque levou quase 9 meses para ser descoberto e causou danos estimados em bilhões de dólares — incluindo à Casa Branca, Pentágono e até mesmo a Microsoft.

Cenário do ataque

Especialistas traçaram o que poderia ter acontecido se criminosos ou agências de inteligência estrangeiras tivessem descoberto a vulnerabilidade primeiro.

Atacantes criariam centenas de GitHub Apps até obter um ID malicioso que passa pelos filtros. Em seguida, submeteriam um pull request aparentemente legítimo – o código seria revisado, os testes passariam, tudo pareceria normal. Durante a compilação automática, credenciais seriam extraídas silenciosamente.

Usando as credenciais roubadas, os criminosos ganhariam privilégios de administrador no repositório e aguardariam o momento perfeito: o release semanal do SDK. Minutos antes da publicação oficial, injetariam um commit malicioso com código muito sutil – apenas algumas linhas disfarçadas como “analytics” ou “telemetria”.

Horas depois, milhões de aplicações baixariam o SDK comprometido. O backdoor começaria a coletar credenciais AWS, tokens de sessão e dados de aplicações. Em semanas ou meses, atacantes teriam acesso silencioso a bancos de dados (RDS), armazenamento de arquivos (S3), funções serverless (Lambda), redes privadas virtuais (VPC) e sistemas de identidade (IAM).

AWS corrigiu vulnerabilidade em 48 horas

Quando a equipe da Wiz percebeu a magnitude da descoberta, reportou imediatamente à AWS através do programa de recompensas por bugs da empresa em agosto de 2024.

Quarenta e oito horas depois, a AWS havia corrigido o problema crítico – as expressões regulares agora incluíam as âncoras necessárias. Em setembro, um conjunto completo de medidas de segurança adicional foi implementado.

A AWS conduziu auditoria extensiva de logs do CloudTrail e de todos os repositórios públicos, concluindo que não havia evidência de que qualquer outro ator além da Wiz explorou a vulnerabilidade.

A empresa também implementou proteções adicionais em todos os processos de build que contêm tokens GitHub ou outras credenciais na memória.