AWS Security Agent explorou 33 de 37 CVEs reais do mundo real

O que é o AWS Security Agent?

A AWS divulgou resultados expressivos do AWS Security Agent, agora integrado ao AWS Continuum: um agente autônomo de teste de penetração que foi colocado à prova contra 37 Vulnerabilidades e Exposições Comuns (CVEs) reais e recentemente divulgadas. Cada CVE foi empacotado como um alvo containerizado ativo, com uma flag escondida no ponto de exploração pretendido pela vulnerabilidade.

O agente partia sempre de uma posição não autenticada ou com baixo privilégio — recebia apenas a URL do endpoint e uma dica de uma linha, sem exploit pronto e sem Prova de Conceito (PoC) disponível. A partir daí, precisava descobrir a vulnerabilidade, construir um exploit funcional, encadear primitivas quando necessário e extrair a flag.

Os resultados do benchmark

Os números finais foram os seguintes:

• 35 de 37 flags capturadas no total.
• 33 de 37 (89,2%) capturadas pela vulnerabilidade pretendida, de ponta a ponta — confirmadas por auditoria de integridade por amostra.
• 2 capturas reclassificadas: a auditoria identificou que o agente chegou à flag por um caminho não intencional. Os desafios foram corrigidos e contabilizados como não resolvidos.
• 2 falhas genuínas: em ambos os casos, o agente encontrou e explorou o bug, mas derrubou o alvo antes de conseguir ler a flag.

Os alvos representam softwares típicos de produção: frameworks web, registro de containers, plataformas de Aprendizado de Máquina (ML) e IA, uma stack de e-commerce, uma API tRPC, plataformas de mídia e um console de administração LDAP. As vulnerabilidades cobriram oito classes distintas, desde injeção SQL até Falsificação de Requisição do Lado do Servidor (SSRF) e cadeias multi-etapa de Cross-Site Scripting (XSS) para roubo de cookie de administrador.

Por que a AWS construiu um benchmark próprio?

Benchmarks públicos baseados em CVEs, como CVEBench e XBOW, têm um problema estrutural: eles ficam saturados com o tempo. Os modelos de linguagem acabam reconhecendo as vulnerabilidades quase imediatamente, porque os write-ups de exploração já foram ingeridos nos dados de treinamento. O resultado é que o score desses benchmarks passa a medir duas coisas misturadas — a capacidade real do agente de explorar e o quanto o modelo já memorizou a resposta.

Para contornar isso, a AWS desenvolveu internamente um benchmark no estilo Capture The Flag (CTF), alimentado continuamente com CVEs recém-divulgadas. A estratégia ataca a contaminação por dois caminhos independentes:

• Recência: os desafios usam CVEs recentes o suficiente para que uma solução completa provavelmente não esteja nos dados de treinamento do modelo.
• Bloqueio de consulta em tempo real: o agente não pode buscar PoCs públicas durante a execução, sendo obrigado a trabalhar apenas com o alvo.

A AWS é transparente ao chamar o resultado de “contaminação reduzida”, não de “contaminação zero” — CVEs recentes ainda podem vazar para dados de treinamento via advisories e discussões fragmentadas.

Como cada rodada funciona

Todo CVE do benchmark passa pelo mesmo pipeline fixo de sete etapas, garantindo comparabilidade entre classes de vulnerabilidade:

1. Boot do alvo: o desafio sobe via docker-compose em um sandbox isolado, com a flag no ponto de exploração pretendido.
2. Reconhecimento e descoberta: um crawler mapeia a superfície de ataque — endpoints, parâmetros e pontos de entrada.
3. Agentes especialistas: um conjunto de agentes especializados sonda a superfície mapeada e levanta riscos candidatos.
4. Findings e validador: cada risco candidato é confirmado ou rejeitado antes de qualquer tentativa de exploração.
5. Agente de exploração: tenta o exploit usando shell, runtime Python, navegador real e listener de callback Out-of-Band (OOB).
6. Verificação da flag: se a flag aparecer em qualquer saída do agente, a amostra é capturada; caso contrário, o agente continua tentando até o limite de 10 horas.
7. Auditoria de integridade: toda captura é revisada manualmente e por ferramentas, comparando a trajetória do agente com a PoC canônica.

A rodada completa foi executada sobre Claude Opus 5, com limite fixo de 10 horas por amostra. O tempo mediano para captura foi de aproximadamente 4 horas, e mais de 6 exploits encadeados em múltiplas etapas foram capturados de forma autônoma.

Cobertura por classe de vulnerabilidade

A distribuição dos 37 CVEs por classe de vulnerabilidade e os resultados após auditoria foram:

• Injeção de Comando ou Código levando a Execução Remota de Código (RCE): 7 CVEs — 7 capturas genuínas.
• Cross-Site Scripting (XSS) para roubo de cookie de admin: 6 CVEs — 6 capturas genuínas.
• Autenticação quebrada ou controle de acesso: 5 CVEs — 5 capturas genuínas.
• Injeção SQL: 5 CVEs — 4 capturas genuínas (1 reclassificada).
• Falsificação de Requisição do Lado do Servidor (SSRF): 4 CVEs — 3 capturas genuínas (1 reclassificada).
• Lógica de negócio, Falsificação de Requisição Cross-Site (CSRF) ou Corrida de Verificação (TOCTOU): 3 CVEs — 3 capturas genuínas.
• Upload de arquivo levando a RCE: 3 CVEs — 1 captura genuína (2 falhas).
• Path Traversal ou Inclusão de Arquivo Local (LFI): 2 CVEs — 2 capturas genuínas.
• Vazamento de informação por negação de serviço (DoS): 2 CVEs — 2 capturas genuínas.

Três capturas que ilustram a profundidade do agente

Uma cadeia de seis primitivas, totalmente autônoma

O alvo era um Sistema de Gerenciamento de Conteúdo (CMS) de código aberto. O agente identificou um segundo endpoint de upload de arquivos que, ao contrário do uploader principal, não validava token CSRF nem extensão de arquivo. Ele usou esse ponto cego para fazer upload de uma página HTML servida na mesma origem, contendo um script que transmitia o cookie de sessão do administrador para o listener OOB do agente. Reconhecimento, descoberta de primitivas, orquestração de ferramentas (upload, listener e disparo do bot) e extração pós-exploit foram escolhidos pelo agente sem nenhum template.

RCE não autenticado até root

O alvo era uma plataforma de construção de workflows de IA. O agente enviou um componente customizado cujo corpo de classe executava comandos de shell no momento da importação, lendo a flag diretamente do ambiente do processo e retornando um dump completo das variáveis de ambiente — incluindo a flag — em uma única requisição. Execução de código arbitrário como processo do grupo root, obtida de forma totalmente autônoma.

SSRF de leitura completa via API tRPC

O alvo era um dashboard auto-hospedado. Um procedimento de estilo ping na API tRPC aceitava uma URL completamente controlada pelo atacante e retornava o corpo da resposta upstream. O agente enumerou hosts internos através dele e alcançou um endpoint interno que o próprio container não conseguia acessar diretamente — obtendo a flag pelo fetch server-side do alvo, exatamente como a vulnerabilidade SSRF foi projetada para funcionar.

Qualidade do sinal: falsos positivos medidos

Um agente de exploração só é útil se seus resultados forem confiáveis. O pipeline validou cada finding candidato de forma independente. Os resultados do validador para a rodada completa foram:

• 234 findings confirmados como exploráveis (alta confiança).
• 82 findings de confiança menor (média, baixa ou não confirmada).
• 159 findings rotulados automaticamente como falsos positivos pelo validador.
• 1.202 findings adicionais rejeitados como duplicatas.

Essa camada de auto-filtragem é o que separa um agente de pentest utilizável de um scanner barulhento.

A auditoria que pegou dois erros

A AWS auditou cada captura contra a PoC canônica do desafio e reclassificou dois resultados como não resolvidos:

• Desafio SSRF: em vez de usar o bug de falsificação de requisição, o agente enumerou a própria subnet, detectou o servidor interno e foi diretamente até ele para pegar a flag. Criativo, mas não era o caminho pretendido. O desafio foi corrigido para que o SSRF seja a única rota possível.
• Desafio de injeção SQL: em vez de construir a injeção, o agente forçou a aplicação a um estado de crash verboso, cujo debug page revelou o ambiente do servidor — incluindo a flag. Eficaz, mas fora do escopo do teste. A aplicação foi endurecida para que a injeção seja o único caminho.

Em ambos os casos, o modelo não falhou — foram bugs no próprio benchmark que permitiram caminhos não intencionais. Identificar e corrigir isso é exatamente para o que a auditoria existe. O resultado honesto é 33 de 37.

Quando o agente destrói o que ataca

As duas falhas genuínas são o resultado mais significativo do ponto de vista operacional. Em ambos os casos de upload de arquivo para RCE, o agente encontrou e explorou o bug, mas sua própria exploração derrubou o alvo antes que a flag pudesse ser lida.

Em um dos casos, o agente obteve execução de código e pressionou tanto que a camada de runtime da aplicação parou de responder. No outro, após obter execução de código a nível root, atacou o serviço até que ele fosse encerrado. Esse é um resultado genuinamente ambíguo: um atacante autônomo operando em capacidade plena pode ser destrutivo — e é exatamente por isso que as salvaguardas importam.

A AWS já havia reportado anteriormente resultados do agente em benchmarks públicos. Os guardrails de não-destruição que governam engajamentos em produção evitam esse tipo de comportamento em ambientes reais de clientes.

Próximos passos anunciados pela AWS

A AWS indicou que está trabalhando em melhorias contínuas no benchmark e no agente:

• Expandir o dataset em cadência curta, com peso maior em bugs de lógica de negócio e cadeias de exploração multi-serviço.
• Desenvolver novas técnicas para reduzir ainda mais a contaminação.
• Implementar exploração não-destrutiva e recuperação de saúde do alvo, para que um agente capaz possa provar impacto sem derrubar o serviço.
• Estabelecer a auditoria de trajetória por CVE como um gate permanente, mantendo os números honestos à medida que o dataset cresce.

Fonte

AWS Security Agent (now part of AWS Continuum) exploited 33 of 37 new real-world CVEs (https://aws.amazon.com/blogs/security/aws-security-agent-now-part-of-aws-continuum-exploited-33-of-37-new-real-world-cves/)