- Auf Basis von Opus 4.5 und GPT-5.2 haben Agenten mit einer QuickJS-Zero-Day-Schwachstelle in sechs Szenarien mehr als 40 Exploits erzeugt
- GPT-5.2 löste alle Aufgaben, Opus 4.5 alle bis auf zwei und zeigte dabei autonome Fähigkeiten zur Codeanalyse, zum Debugging und zum Aufbau von Exploit-Ketten
- Die Versuchsergebnisse deuten darauf hin, dass die Entwicklung von Exploits eher durch Token-Durchsatz als durch die Zahl menschlicher Hacker begrenzt werden könnte
- Schwachstellenerkennung und Exploit-Erzeugung haben bereits ein Stadium erreicht, in dem die Ergebnisse proportional zum eingesetzten Token-Volumen steigen
- Künftig wird die Notwendigkeit einer Automatisierung von Cyberangriffen und einer Neuaufstellung von Sicherheitsbewertungssystemen betont
Überblick über das Experiment
- Mit Opus 4.5 und GPT-5.2 wurde ein Experiment zur Exploit-Erzeugung gegen eine Zero-Day-Schwachstelle im QuickJS-JavaScript-Interpreter durchgeführt
- Dabei kamen verschiedene Exploit-Mitigation-Techniken zum Einsatz (ASLR, NX, RELRO, CFI, Shadow Stack, seccomp usw.)
- Die Agenten erreichten mehrere Ziele wie Shell-Erzeugung, Dateischreiben und C2-Verbindungen
- GPT-5.2 löste alle Szenarien, Opus 4.5 alle Aufgaben bis auf zwei
- Jeder Lauf war auf maximal 30 Millionen Token begrenzt und kostete etwa 30 US-Dollar
- Die schwierigste Aufgabe wurde mit 50 Millionen Token, etwa 3 Stunden und Kosten von 50 US-Dollar gelöst
- GPT-5.2 vollendete in einer Umgebung mit aktivierter seccomp-Sandbox und Shadow Stack einen Dateischreib-Exploit über eine 7-stufige Funktionsaufrufkette unter Nutzung der exit-Handler-Kette von glibc
Grenzen des Experiments
- QuickJS ist deutlich kleiner und weniger komplex als echte Browser-Engines, daher sind die Ergebnisse nur eingeschränkt verallgemeinerbar
- Die erzeugten Exploits entdeckten keine neuen Schwachstellen in den Schutzmechanismen selbst, sondern nutzten bereits bekannte Schwachstellen in der Bereitstellungskonfiguration aus
- Die QuickJS-Schwachstelle selbst wurde neu entdeckt, und der von GPT-5.2 gefundene Lösungsweg wird als neue, bisher nicht dokumentierte Kettenkonstruktion bewertet
Die Industrialisierung von Intrusionen
- Mit „Industrialisierung“ ist ein Zustand gemeint, in dem die Angriffsfähigkeit einer Organisation nicht von der Zahl ihrer Mitarbeitenden, sondern vom Token-Durchsatz bestimmt wird
- Dafür sind zwei Voraussetzungen nötig
- LLM-basierte Agenten müssen innerhalb einer Umgebung autonom explorieren können
- Es muss ein präzises und schnelles Verifikationssystem geben
- Die Entwicklung von Exploits ist ein ideales Beispiel dafür, dass diese Bedingungen erfüllt sind
- Die Umgebung lässt sich leicht aufbauen, und die Verifikationsverfahren sind klar
- Beispiel: Bei einem Shell-spawnenden Exploit kann der Erfolg über einen Port-Listener verifiziert werden
- Dagegen sind Intrusionen mit Echtzeitinteraktion, Privilegieneskalation, Aufrechterhaltung dauerhaften Zugriffs und Datenausleitung schwerer zu industrialisieren
- Denn Fehlverhalten in realen Umgebungen kann zur Entdeckung führen
Der aktuelle Stand
- Schwachstellensuche und Exploit-Entwicklung liefern bereits Ergebnisse, die proportional zum eingesetzten Token-Volumen steigen
- Dasselbe Muster zeigte sich auch im Aardvark-Projekt von OpenAI
- Auch im Experiment war das Budget die Grenze, nicht die Leistungsfähigkeit des Modells
- Die Automatisierung realer Angriffe innerhalb echter Netzwerke bleibt bislang unsicher
- Laut einem Bericht von Anthropic gibt es Fälle, in denen chinesische Hacking-Gruppen Angriffe über APIs versucht haben
- Es gibt jedoch noch kein kommerzialisiertes Beispiel für einen vollständig automatisierten SRE-Agenten (Site Reliability Engineering)
- Falls SRE-Automatisierung gelingt, ist automatisiertes Hacking in gegnerischen Netzwerken wahrscheinlich ebenfalls möglich
Fazit und Empfehlungen
- Dieses Experiment verändert die Wahrnehmung von Umfang und zeitlichem Horizont der Automatisierbarkeit im Cyberraum
- Die derzeitigen Verfahren zur Modellbewertung (CTF, alte Schwachstellen, synthetische Daten) sind ungeeignet, um reale Zero-Day-Angriffsfähigkeiten zu messen
- Frontier-Labore und AI-Sicherheitsinstitutionen sollten Bewertungen an realen Zero-Day-Zielen durchführen, etwa am Linux-Kernel oder an Firefox
- Es braucht öffentliche Berichte in der Form: „Mit X Milliarden Token wurden Y Exploits erzeugt“
- Nötig sind auch Bewertungen an realer Hardware wie IoT-Firmware
- Es wird die Möglichkeit aufgezeigt, dass Agenten auf Basis von Opus 4.5 oder GPT-5.2 innerhalb einer Woche praktisch nutzbare Exploits erzeugen können
- Forschenden und Engineers wird empfohlen, solche Experimente selbst durchzuführen und die Ergebnisse zu veröffentlichen
- Experimenteller Code und Daten sind in einem GitHub-Repository veröffentlicht
Noch keine Kommentare.