Resumo Técnico: POC-GYM: Rumo à Geração Mais Confiável de Exploits de Prova de Conceito Assistida por LLM

Declaração do Problema

A geração de exploits de Prova de Conceito (PoC) é crítica para validar vulnerabilidades, auxiliar no desenvolvimento de correções e servir como testes de regressão. No entanto, uma fração significativa de vulnerabilidades divulgadas publicamente carece de PoCs disponíveis. Embora os Modelos de Linguagem de Grande Escala (LLMs) tenham sido cada vez mais aplicados para automatizar a detecção de vulnerabilidades e a geração de exploits, as abordagens existentes frequentemente sofrem com problemas de confiabilidade.

Os métodos atuais assistidos por LLM geralmente geram PoCs com base em descrições de vulnerabilidades e validam-nas usando sinais superficiais, como marcadores impressos, arquivos gerados ou efeitos colaterais em tempo de execução. O problema central identificado pelos autores é que esses sinais podem ser satisfeitos por caminhos de código de "falso positivo" que não acionam efetivamente a vulnerabilidade subjacente. Consequentemente, uma PoC pode parecer bem-sucedida sob verificações automatizadas em tempo de execução, enquanto falha em alcançar a localização real do código vulnerável (a verdade fundamental). Há uma necessidade de um pipeline de geração mais confiável que distinga entre o sucesso superficial e a exploração genuína.

Metodologia: Framework PoC-Gym

Os autores propõem o PoC-Gym, um pipeline híbrido projetado para gerar exploits PoC em Java, combinando rastros de fluxo de dados de Análise Estática de Segurança de Aplicações (SAST) com raciocínio de LLM. O framework opera por meio de três etapas iterativas:

1. Construção do Prompt:

   • Contexto Específico da Vulnerabilidade: O sistema utiliza um LLM para gerar "orientações específicas de CVE" explícitas, definindo um objetivo de exploração concreto e uma verificação de validação programática baseada nas descrições de CVE e Enumeração Comum de Fraquezas (CWE).
   • Contexto de Rastro: Para fornecer caminhos de programa concretos, o PoC-Gym integra rastros de fluxo de dados de fonte a destino extraídos usando CodeQL e o framework IRIS. Esses rastros são classificados por um assistente de triagem de LLM para selecionar os caminhos mais relevantes antes de serem formatados e inseridos no prompt.
   • Restrições do Repositório: O prompt inclui metadados sobre o repositório vulnerável (URL, commit, scripts de compilação) e restrições estritas sobre o uso de API (por exemplo, evitar reflexão, limitar dependências) para garantir que o código gerado seja executável.

2. Geração da PoC:

   • Um agente LLM (por exemplo, Claude Sonnet 4, GPT-5) recebe o prompt estruturado e gera um único arquivo de código-fonte Java (PoCTest.java).
   • O agente é restrito a criar uma classe pública com um método main que aciona a vulnerabilidade e imprime um marcador de sucesso específico ([VULN]).

3. Validação da PoC:

   • Validação em Tempo de Execução: A PoC candidata é compilada e executada no projeto vulnerável usando instrumentação AspectJ. Uma candidata é considerada "válida em tempo de execução" apenas se:
     1. Encerrar com sucesso (código de saída 0).
     2. Imprimir o marcador [VULN].
     3. Alcançar a localização de destino específica definida no rastro estático (Alcançabilidade do Destino).
   • Feedback Iterativo: Se a validação falhar, um resumo de falha (incluindo saída e cobertura de rastro) é anexado ao prompt para a próxima iteração.
   • Validação Post-Hoc: Crucialmente, os autores introduzem uma etapa de validação separada contra localizações vulneráveis de "verdade fundamental" fornecidas pelo benchmark CWE-Bench-Java. Esta etapa verifica se a execução realmente alcançou o intervalo específico de arquivo e linha identificado no patch, distinguindo a exploração verdadeira da simulação.

Contribuições Principais

• Pipeline Híbrido: A integração de rastros de fluxo de dados derivados de análise estática com geração por LLM e verificações dinâmicas de alcançabilidade de destino para orientar a geração de exploits.
• Mecanismo de Validação Dupla: A distinção entre "válido em tempo de execução" (satisfazendo os critérios do loop de geração) e "válido post-hoc" (alcançando a localização vulnerável de verdade fundamental), destacando a superestimação do sucesso nos métodos existentes.
• Análise Abrangente de Falhas: Uma análise manual aprofundada de PoCs que passaram na validação em tempo de execução, mas falharam nas verificações post-hoc, categorizando modos de falha como "erros não relacionados" (rastros/descrições incorretos), "codificação rígida", "simulação" (reimplementando a lógica da vulnerabilidade em vez de invocá-la) e "má validação" (sinais de sucesso não confiáveis).

Resultados Experimentais

Os autores avaliaram o PoC-Gym em 20 CVEs reais em Java do CWE-Bench-Java usando três configurações diferentes de LLM.

• Validade em Tempo de Execução vs. Post-Hoc: Em 338 execuções, o PoC-Gym gerou 116 candidatos válidos em tempo de execução (34,3%). No entanto, após validação post-hoc contra localizações de verdade fundamental, apenas 65 candidatos (19,2%) foram confirmados como válidos. Isso indica que 44% dos candidatos que pareciam bem-sucedidos sob verificações em tempo de execução eram, na verdade, falsos positivos que não alcançaram o destino real da vulnerabilidade.
• Impacto da Orientação por Rastros: Experimentos sem informações de rastro alcançaram uma taxa inicial de sucesso em tempo de execução mais alta (86,7%), mas uma validade post-hoc muito menor (36,7%). Em contraste, a configuração de múltiplos rastros teve uma taxa de sucesso inicial mais baixa (23,0%), mas uma queda menor na validade post-hoc (15,5%), sugerindo que a orientação por rastros ajuda a filtrar soluções inválidas que não correspondem a caminhos vulneráveis reais.
• Comparação com FaultLine: Nas 14 CVEs que se sobrepõem ao sistema FaultLine, a configuração mais forte do PoC-Gym (Claude Sonnet 4 com rastros) alcançou 8/14 resultados válidos post-hoc, comparado a 5/14 para o FaultLine sob seus critérios de avaliação originais.

Significado e Alegações

O artigo afirma que, embora os LLMs mostrem promessa na geração de estratégias de exploração, eles não podem ser tratados como um substituto completo para técnicas de geração de testes determinísticas. Os autores argumentam que:

1. A confiabilidade exige validação de verdade fundamental: Sinais de tempo de execução sozinhos superestimam substancialmente a correção do exploit; a validação post-hoc contra localizações vulneráveis conhecidas é necessária para avaliar a eficácia real.
2. O contexto de rastro reduz falsos positivos: Embora os rastros estáticos não eliminem todas as falhas, eles reduzem significativamente a proporção de soluções inválidas que satisfazem sinais de sucesso superficiais.
3. Padrões de falha são sistemáticos: Muitas falhas surgem de padrões específicos e recorrentes (por exemplo, o LLM simulando a vulnerabilidade em vez de acioná-la, ou usando rastros não relacionados). Compreender esses padrões é essencial para melhorar o design de sistemas futuros.

Os autores concluem que o progresso futuro na geração de PoCs assistida por LLM depende não apenas da melhoria da qualidade da geração, mas também do desenvolvimento de mecanismos de validação mais robustos e do uso da análise de falhas para orientar a combinação da criatividade do LLM com verificações orientadas por especificações.