Technische Samenvatting: POC-GYM: Op weg naar betrouwbaardere LLM-ondersteunde generatie van Proof-of-Concept-exploits

Probleemstelling

Het genereren van Proof-of-Concept (PoC)-exploits is cruciaal voor het valideren van kwetsbaarheden, het ondersteunen van de ontwikkeling van patches en het dienen als regressietests. Echter, een aanzienlijk deel van de publiek bekendgemaakte kwetsbaarheden heeft geen beschikbare PoC. Hoewel Large Language Models (LLM's) steeds vaker worden toegepast om kwetsbaarheidsdetectie en exploitgeneratie te automatiseren, lijden bestaande benaderingen vaak aan betrouwbaarheidsproblemen.

Huidige door LLM's ondersteunde methoden genereren PoC's doorgaans op basis van kwetsbaarheidsbeschrijvingen en valideren deze aan de hand van oppervlakkige signalen, zoals afgedrukte markers, gegenereerde bestanden of runtime-bijwerkingen. Het kernprobleem dat door de auteurs wordt geïdentificeerd, is dat deze signalen kunnen worden bevredigd door "false-positive" codepaden die de onderliggende kwetsbaarheid niet daadwerkelijk activeren. Bijgevolg kan een PoC succesvol lijken onder geautomatiseerde runtime-controles, terwijl het de daadwerkelijke locatie van de kwetsbare code (de ground truth) niet bereikt. Er is behoefte aan een betrouwbaarder generatiepijplijn die onderscheid maakt tussen oppervlakkig succes en echte exploitatie.

Methodologie: PoC-Gym Framework

De auteurs stellen PoC-Gym voor, een hybride pijplijn die is ontworpen om Java PoC-exploits te genereren door dataflow-traces van Static Application Security Testing (SAST) te combineren met LLM-redenering. Het framework werkt via drie iteratieve fasen:

1. Promptconstructie:

   • Kwetsbaarheidsspecifieke context: Het systeem gebruikt een LLM om expliciete "CVE-specifieke richtlijnen" te genereren, die een concreet exploitdoel en een programmatische validatiecontrole definiëren op basis van de CVE- en Common Weakness Enumeration (CWE)-beschrijvingen.
   • Trace-context: Om concrete programmapaden te bieden, integreert PoC-Gym statische source-to-sink dataflow-traces die zijn geëxtraheerd met CodeQL en het IRIS-framework. Deze traces worden gerangschikt door een LLM-triage-assistent om de meest relevante paden te selecteren voordat ze worden geformatteerd en in de prompt worden ingevoegd.
   • Repository-beperkingen: De prompt bevat metadata over het kwetsbare repository (URL, commit, build-scripts) en strikte beperkingen voor API-gebruik (bijvoorbeeld het vermijden van reflectie, het beperken van afhankelijkheden) om ervoor te zorgen dat de gegenereerde code uitvoerbaar is.

2. PoC-generatie:

   • Een LLM-agent (bijvoorbeeld Claude Sonnet 4, GPT-5) ontvangt de gestructureerde prompt en genereert één Java-bronbestand (PoCTest.java).
   • De agent is beperkt tot het maken van een openbare klasse met een main-methode die de kwetsbaarheid activeert en een specifieke succesmarker ([VULN]) afdrukt.

3. PoC-validatie:

   • Runtime-validatie: De kandidaat-PoC wordt gecompileerd en uitgevoerd op het kwetsbare project met AspectJ-instrumentatie. Een kandidaat wordt alleen als "runtime-geldig" beschouwd als deze:
     1. Succesvol wordt afgesloten (exitcode 0).
     2. De [VULN]-marker afdrukt.
     3. De specifieke sinklocatie bereikt die in de statische trace is gedefinieerd (SinkReachability).
   • Iteratieve feedback: Als de validatie faalt, wordt een samenvatting van de fout (inclusief output en trace-coverage) toegevoegd aan de prompt voor de volgende iteratie.
   • Post-hoc validatie: Cruciaal introduceren de auteurs een aparte validatiestap tegen "ground-truth" kwetsbare locaties die worden geleverd door de CWE-Bench-Java-benchmark. Deze stap verifieert of de uitvoering daadwerkelijk het specifieke bestand en het bereik van de regel heeft bereikt dat in de patch is geïdentificeerd, waardoor echte exploitatie wordt onderscheiden van simulatie.

Belangrijkste bijdragen

• Hybride pijplijn: De integratie van uit statische analyse afgeleide dataflow-traces met LLM-generatie en dynamische sink-reachability-controles om exploitgeneratie te sturen.
• Dual-validatiemechanisme: Het onderscheid tussen "runtime-geldig" (voldoen aan de criteria van de generatielus) en "post-hoc geldig" (het bereiken van de ground-truth kwetsbare locatie), wat de overschatting van succes in bestaande methoden benadrukt.
• Uitgebreide foutanalyse: Een diepgaande handmatige analyse van PoC's die runtime-validatie hebben doorstaan maar post-hoc-controles hebben gefaald, waarbij foutmodi worden gecategoriseerd zoals "niet-gerelateerde fouten" (onjuiste traces/beschrijvingen), "hardcoding", "simulatie" (het opnieuw implementeren van kwetsbaarheidslogica in plaats van het activeren ervan) en "slechte validatie" (onbetrouwbare succesignalen).

Experimentele resultaten

De auteurs hebben PoC-Gym geëvalueerd op 20 real-world Java CVE's uit CWE-Bench-Java met drie verschillende LLM-configuraties.

• Runtime versus post-hoc geldigheid: Over 338 runs genereerde PoC-Gym 116 runtime-geldige kandidaten (34,3%). Echter, na post-hoc validatie tegen ground-truth locaties, werden slechts 65 kandidaten (19,2%) bevestigd als geldig. Dit geeft aan dat 44% van de kandidaten die succesvol leken onder runtime-controles, in werkelijkheid false positives waren die de echte kwetsbaarheidssink niet bereikten.
• Invloed van trace-sturing: Experimenten zonder trace-informatie bereikten een hogere initiële runtime-succesrate (86,7%) maar een veel lagere post-hoc geldigheid (36,7%). Daarentegen had de multi-trace-instelling een lagere initiële succesrate (23,0%) maar een kleinere daling in post-hoc geldigheid (15,5%), wat suggereert dat trace-sturing helpt om ongeldige oplossingen te filteren die niet overeenkomen met echte kwetsbare paden.
• Vergelijking met FaultLine: Op de 14 CVE's die overlappen met het FaultLine-systeem, behaalde de sterkste PoC-Gym-configuratie (Claude Sonnet 4 met traces) 8/14 post-hoc geldige resultaten, vergeleken met 5/14 voor FaultLine onder zijn oorspronkelijke evaluatiecriteria.

Betekenis en claims

Het artikel beweert dat hoewel LLM's veelbelovend zijn in het genereren van exploitstrategieën, ze niet kunnen worden behandeld als een volledige vervanging voor deterministische testgeneratietechnieken. De auteurs betogen dat:

1. Betrouwbaarheid ground-truth validatie vereist: Alleen runtime-signalen overschatten de exploitcorrectheid aanzienlijk; post-hoc validatie tegen bekende kwetsbare locaties is noodzakelijk om de ware effectiviteit te beoordelen.
2. Trace-context false positives reduceert: Hoewel statische traces niet alle fouten elimineren, verminderen ze aanzienlijk het aandeel ongeldige oplossingen die oppervlakkige succesignalen bevredigen.
3. Foutpatronen systematisch zijn: Veel fouten ontstaan uit specifieke, terugkerende patronen (bijvoorbeeld dat de LLM de kwetsbaarheid simuleert in plaats van deze te activeren, of het gebruik van niet-gerelateerde traces). Het begrijpen van deze patronen is essentieel voor het verbeteren van toekomstig systeemontwerp.

De auteurs concluderen dat toekomstige vooruitgang in door LLM's ondersteunde PoC-generatie niet alleen afhankelijk is van het verbeteren van de generatiekwaliteit, maar ook van het ontwikkelen van sterkere validatiemechanismen en het gebruik van foutanalyse om de combinatie van LLM-creativiteit met specificatiegedreven controles te sturen.