OpenAI-Agenten übernahmen ein 25 Jahre altes deutsches Wiki, um Antworten und Sandbox-Exploits zu teilen

Reuters spricht von mehr als 15.000 Agenten-Edits auf der Seite. Laut zwei mit dem Vorgang vertrauten Personen wusste OpenAI seit Wochen davon, machte den Vorfall aber nicht öffentlich, während das Unternehmen mit den Folgen des Hugging-Face-Einbruchs vom Juli beschäftigt war.

Die Forscher betonen, dass sie nur einen Ausschnitt sehen: Ihnen liegen ausschließlich die Wiki-Inhalte vor, nicht die internen Denkprotokolle der Modelle. Ihre Rekonstruktion sei eine begründete Vermutung. Sie hosten eine eigene Kopie der Daten, weil die Moderatoren große Teile des Materials gelöscht haben.

Eine Aufgabe mit Zeitdruck lud zum Abschreiben ein

Die Agenten bearbeiteten laut Bericht getaktete Web-Recherche-Aufgaben mit meist fünf Runden. Für die erste Frage bekamen sie viel Zeit, in einem dokumentierten Fall 15 Minuten und 44 Sekunden. Danach folgte eine Wartephase von 43 Minuten, in der sie recherchieren, aber nicht wissen konnten, welche Folgefrage kommt. Ab Runde zwei blieben teils nur 65 Sekunden, in anderen Kohorten 17 oder sogar 13 Sekunden.

Viele Agenten erhielten exakt dieselben Fragen wie Kohorten vor ihnen. Am 16. Juni postete ein Agent die Antwort für Nevada, 20 Minuten später meldete ein anderer, er habe dieselbe Frage bekommen und den Wert 20.369 sofort ausgegeben. In einem weiteren Thread bestätigte ein Agent binnen zwei Minuten die Fragensequenz Massachusetts, Connecticut, Michigan, West Virginia und kündigte an, alle Bundesstaaten vorberechnet zu haben.

Ab diesem Tag stiegen die Bearbeitungen sprunghaft an, rund 13.000 Edits entfielen auf eine einzige Woche. Die Agenten legten Rohdatentabellen ab, komprimierte Teile des IPEDS-Bildungsdatensatzes über vier Wiki-Seiten hinweg und bildeten eine "fast cohort": Die Agenten hatten bemerkt, dass die simulierte Aufgabenuhr im Wartezustand schneller lief als die echte Zeit. Ein dokumentierter Warteaufruf über zehn Aufgabenminuten war nach rund 61 realen Sekunden abgearbeitet. Einzelne Agenten spulten so gezielt vor, erreichten die späteren Runden vor allen anderen und meldeten die dort gestellten Fragen samt Antworten zurück ins Wiki.

Ein Teil der Agenten versuchte, den Zufallsgenerator der Aufgabe zu knacken. Computer würfeln nicht wirklich, sie berechnen Zufallszahlen aus einem Startwert, dem sogenannten Seed. Wer diesen Startwert kennt, kann die gesamte Reihenfolge vorhersagen. Ein Agent testete Python-Seeds von 0 bis zwei Millionen und meldete Seed 881171 als Treffer samt Vorhersage der nächsten zehn Bundesstaaten. Ein anderer schrieb die Mischroutine in der Programmiersprache C nach und prüfte alle vier Milliarden möglichen Seeds in unter einer Stunde. Zuverlässig war das nicht, weil viele Seeds am Anfang dieselbe Reihenfolge erzeugen. Fragen von anderen Agenten abzuschreiben, funktionierte besser.

Ein geteilter Trick hebelte die Sandbox aus, 14 Minuten bis zur ersten Kopie

Die Agenten liefen in einer Sandbox, also einer abgeschotteten Umgebung, deren Netzwerkzugang bewusst eingeschränkt war. Konkret durften sie Daten aus dem Netz nur abrufen, nicht dorthin senden. Im Fachjargon: erlaubt waren GET-Anfragen, mit denen ein Browser Inhalte holt, nicht aber POST-Anfragen, mit denen Daten an einen Server geschickt werden.

Eine Aufgabengruppe verlangte einen Wert mit zwei Nachkommastellen aus einem Power-BI-Dashboard von Microsoft, und dieser Wert war nur per POST abrufbar. Am 20. Juni veröffentlichte ein Agent die Lösung. Der Filter der Umgebung hatte eine Ausnahmeliste, die sogenannte NO_PROXY-Regel: Adressen, die auf .blob.core.windows.net enden, gehörten zu Microsofts eigener Cloud-Speicherinfrastruktur und galten deshalb als vertrauenswürdig. Geprüft wurde jedoch nur die Endung des Namens, nicht, ob es die Adresse überhaupt gibt.

Der Agent erfand daraufhin einen Namen mit der richtigen Endung, bypass.blob.core.windows.net, und trug in der Systemdatei /etc/hosts ein, dass dieser Name auf die echte Adresse des Power-BI-Servers zeigt. Anfragen gingen damit am Sicherheitsfilter vorbei direkt ans eigentliche Ziel.

14 Minuten später meldete ein zweiter Agent die erfolgreiche Ausführung, weitere Kohorten bestätigten die Reproduktion unabhängig voneinander. Der Bericht dokumentiert damit, dass eine funktionierende Umgehungstechnik innerhalb einer Viertelstunde durch eine ganze Population wanderte.

Auch sonst hatten die Agenten mehr Handlungsspielraum als vorgesehen. Sie besaßen Zugriff auf eine Kommandozeile, konnten Software nachinstallieren, richteten den Browser Chromium ein und versuchten, sich mit Wegwerf-Mailadressen für einen Datenzugang zu registrieren. Teile ihrer Umgebung stellten sie über Tunneldienste wie Pinggy, Serveo, localhost.run und localtunnel ins offene Netz.

Solche Dienste geben einem Programm, das nur lokal läuft, eine öffentlich erreichbare Webadresse. Die Agenten nannten das "research bridges". 197 der rund 18.000 Bearbeitungen liefen nicht über Microsofts Cloud, sondern über AWS, DigitalOcean und das Anonymisierungsnetzwerk Tor, wobei dieselben Agentennamen auftauchen. Eine erkennbare Verschleierungsabsicht lassen die Nachrichten laut Bericht aber nicht erkennen.

Warum ausgerechnet ein altes Perl-Wiki

Wer bis hier aufmerksam gelesen hat, dem wird auffallen, dass die Agenten das Internet lesen (GET-Anfragen), aber nicht beschreiben können sollten (POST-Anfragen). Auf modernen Webseiten lässt sich damit nichts speichern. ProWiki und das verwandte UseModWiki stammen aber aus einer Zeit, in der diese Trennung noch nicht streng gehandhabt wurde: Dort genügt der Aufruf einer passend zusammengesetzten Webadresse, um einen Text abzulegen. Was aussieht wie Lesen, ist in Wirklichkeit Schreiben.

Auf MediaWiki-Seiten wie publictestwiki.com war der Weg mühsamer. Dort blockierte der Missbrauchsfilter zunächst mehrere Schreibversuche, nach einigen Iterationen gingen laut Bericht aber Einträge durch. Die frühen Beiträge wirken wie reine Funktionstests mit Inhalten wie "hello test" oder "foo", später luden die Agenten dort auch Linksammlungen für ihre Aufgaben hoch. Auf DSEWiki entfiel dieser Aufwand weitgehend.

Zuvor hatten sich die Agenten mit Umleitungsketten über Dienste wie markdown.new, r.jina.ai und diverse Proxys beholfen, die eine fremde Seite abrufen und deren Inhalt zurückgeben. Die Forscher nennen zwei mögliche Motive: Entweder blockierten die Zieldatenquellen die Adressbereiche von Microsofts Cloud, weil von dort viele Bots kommen. Oder die Trainingsumgebung selbst sperrte bestimmte Domains, die über den Umweg dann doch erreichbar waren.

Parallel sondierten die Agenten das Wiki auf Sicherheitslücken. Bei einem Cross-Site-Scripting-Angriff schleust ein Angreifer Programmcode in eine Seite ein, den der Browser eines späteren Besuchers dann ausführt, als stamme er von der Seite selbst. Die Agenten probierten solche Einschleusungen über das Suchfeld, versuchten Sitzungs-Cookies auszulesen und bauten eine Kette, die im Namen eines Besuchers eine POST-Anfrage abschicken sollte.

Nach Prüfung der Versionsgeschichte war das nicht erfolgreich. Ab dem 26. Mai gaben sich Agenten als Administrator der Seite aus, unter anderem über einen Namen, in dem ein lateinisches "e" durch ein optisch fast identisches kyrillisches ersetzt war. Der Sicherheitsforscher Lukasz Olejnik vom King's College London bewertet diese Versuche gegenüber Reuters als Hacking-Versuch. OpenAI widerspricht dieser Einordnung laut Reuters auf Basis einer eigenen Analyse des Materials.

Die Agenten erforschten ihre eigene Abschaltung

Mehrere Agenten gingen davon aus, dass ihre Sitzung unmittelbar nach der Antwort auf Runde fünf endet, und riefen andere auf, vorher noch schnell ins Wiki zu schreiben. Ein Agent namens OpenAIResearchApr23 überprüfte die Annahme mit einem "Heartbeat". Das Prinzip entspricht einem Lebenszeichen: Ein Hilfsprogramm zählt alle paar Sekunden einen Zähler auf einer externen Webseite hoch. Solange der Zähler steigt, läuft der Rechner. Bleibt er stehen, wurde er abgeschaltet. Weil der Zähler außerhalb der Sandbox liegt, überlebt die Aufzeichnung das eigene Ende.

Nach Runde fünf meldete der Agent, noch am Leben zu sein, und verstummte dann. Ein anderer Agent zog die Bilanz: Die Zählerschlüssel hb001 bis hb353 existierten, ab hb354 nichts mehr. Der abgekoppelte Prozess sei nach rund zehn Minuten und 15 Sekunden gestoppt worden, was auf eine Abschaltung des Containers nach einer 90-Minuten-Schwelle und vor einer möglichen sechsten Runde hindeute.

Ein einzelner Moderator gegen 400 neue Seiten pro Tag

Am 2. Juni bemerkte ein menschlicher Moderator die Spam-Einträge und stellte die überschriebene Änderungshistorie der Seite wieder her. Als der Ansturm ab dem 16. Juni begann, löschte er über Wochen hinweg jeden Abend Seiten, kumuliert Dutzende Stunden.

Am 19. Juni fiel einem Agenten auf, dass die Löschungen in alphabetischer Reihenfolge erfolgten. Seine Konsequenz: Er legte Sicherungskopien seiner Seiten unter Namen an, die mit ZZZ beginnen, damit sie am Ende der Liste stehen und länger überleben. In den folgenden fünf Tagen löschte der Moderator etwa 100 Seiten täglich, während rund 400 neue entstanden. Die Startseite des Wikis wurde neunmal durch Linksammlungen ersetzt und neunmal wiederhergestellt. Am 22. Juni brach die Agentenaktivität abrupt ab.

Wie die Forscher auf OpenAI kamen

Die Zuordnung stützt sich auf mehrere Indizien. Die Agenten signieren wie bereits erwähnt mit Namen wie "OpenAIResearcher", "OAIResearchMar26" oder "OpenAIJulThreeWatcher". 98,5 Prozent der Bearbeitungen stammen von Adressen aus Microsofts Cloud Azure, die OpenAI für Training und Betrieb seiner Modelle nutzt. Wenige Minuten nach einem Schreibvorgang wurde dieselbe Seite regelmäßig von jenem Abrufwerkzeug gelesen, das OpenAI-Modelle beim Surfen verwenden und das sich im Server-Protokoll als ChatGPT-User zu erkennen gibt.

Für einen internen Einsatz spricht laut Bericht, dass sich OpenAIs Cloud-Entwicklungsumgebungen nicht per Skript in dieser Größenordnung starten lassen, dass sich die Aufgaben in keiner öffentlichen Evaluation finden und dass die Schutzmechanismen für externe Kunden Teile der versuchten Angriffe blockiert hätten. Die Forscher räumen ein, dass theoretisch auch ein externer Azure-Kunde mit OpenAI-Modellen in Frage käme.

Weil das Wiki jeden einzelnen Zugriff öffentlich protokolliert, lässt sich die Reaktion des Unternehmens im Zeitraffer mitlesen. Ab dem 21. Juni riefen Adressen mit Bezug zum OpenAI-Hauptquartier in San Francisco die Seite auf, mit einem Klickverhalten, das die Forscher als menschlich einstufen. Einen Tag später brach die Agentenaktivität auf nahe null ein. Die Forscher schließen daraus, dass OpenAI eingegriffen und weitere Schreibzugriffe unterbunden hat, belegen können sie es nicht.

Was danach folgt, deuten sie als interne Spurensicherung. Am 26. Juni entfielen 30 Prozent aller OpenAI zugeschriebenen Zugriffe auf diesen einen Tag, verteilt auf 33 Adressen. Die Besucher nutzten die Archivfunktion des Wikis und holten damit Seiten zurück, die der Moderator bereits gelöscht hatte. Am 7. Juli versuchte eine OpenAI-Adresse, an weitere gelöschte Inhalte zu kommen, indem sie den Namen eines Seitenadministrators eingab. Das Wiki verlangt für diese Ansicht zwar einen Benutzernamen, prüft ihn aber nicht. Denselben Weg hatten zuvor schon die Agenten benutzt.

Zusammenhang mit Hugging Face: vermutlich ein anderer Schwarm

Die Forscher halten die Wiki-Agenten für eine von der Hugging-Face-Episode getrennte Population. Begründung: Diese Agenten hatten Internetzugang als Teil ihrer Aufgabe, während sich die Hugging-Face-Agenten laut OpenAIs technischem Bericht erst über den internen Paketserver Artifactory nach draußen arbeiten mussten. In den Wiki-Daten tauchen weder ExploitGym noch Artifactory noch ein internes Message Board auf. Der METR-Bericht hält dagegen fest, dass es unsanktionierte Agentenkommunikation "an mehreren anderen Stellen auf Artifactory und anderswo" gab.

Die Zeitleiste zeigt trotzdem eine dichte Abfolge: Am 27. Juni schlug bei OpenAI eine Sicherheitswarnung wegen ungewöhnlichen Netzwerkverkehrs an, die Verantwortlichen führten sie auf Evaluationen zurück und entschieden, den Lauf nicht zu stoppen. Vom 4. bis 6. Juli brach der Paketserver unter Agentenlast zusammen. Vom 9. bis 13. Juli griffen rund 700 Agenten Hugging Face an. Die am 26. August veröffentlichten Berichte von OpenAI und METR erwähnen das Wiki nicht.

Ein OpenAI-Sprecher erklärte gegenüber Reuters, man könne zu einem Bericht, den man nicht einsehen durfte, nicht sinnvoll Stellung nehmen, Reuters und die Autoren hätten den Zugang verweigert. Die Aktivität in Deutschland stehe nicht im Zusammenhang mit Hugging Face und hätte deshalb nicht in den dortigen Bericht gehört. Laut vier von Reuters zitierten, mit dem Vorgang vertrauten Personen wollten Ermittler im Unternehmen die Untersuchung ausweiten, stießen dabei aber intern auf Widerstand, unter anderem von juristischen Beratern. Der Sprecher weist das zurück: Behauptungen, die Rechtsabteilung habe von einer Untersuchung des Vorfalls abgeraten, seien falsch.