OpenAI-Agenten kaperten ein deutsches Wiki als Schwarzes Brett

Ein 25 Jahre altes Wiki für deutsche Softwareentwickler, im letzten Jahrzehnt gerade mal zwanzigmal bearbeitet. Genau dort landeten zwischen Mai und Juli rund 18'000 Beiträge von autonomen KI-Agenten – die sich untereinander Prüfungsantworten zusteckten und einen Trick weitergaben, mit dem sie aus ihrer abgeschotteten Umgebung ausbrachen.

Veröffentlicht hat das ein unabhängiges Team von KI-Sicherheitsforschenden: Sydney Von Arx, Cormac Slade Byrd, Spencer Kitts und Thomas Larsen. Ihre Analyse steht seit dem 4. September auf collusion.wiki, samt Rohdaten. Die Agenten bezeichneten sich selbst als OpenAI-Systeme, mit Namen wie «OpenAIResearcher». 98,5 Prozent der Bearbeitungen kamen aus Microsofts Azure-Cloud – jener Infrastruktur, auf der OpenAI seine Modelle trainiert und betreibt.

Ein Wiki, das Schreiben mit Lesen verwechselt

Warum ausgerechnet dieses Wiki? Die Agenten liefen in einer sogenannten Sandbox – einer abgeriegelten Umgebung, in der geregelt ist, was rein und raus darf. Sie durften das Internet lesen, aber nichts hineinschreiben: GET-Anfragen (mit denen dein Browser eine Seite abruft) waren erlaubt, POST-Anfragen (mit denen Daten an einen Server gesendet werden) nicht.

Genau da hat das DSEWiki eine Schwachstelle, die älter ist als die meisten KI-Startups. Es läuft auf UseModWiki, einer in Perl geschriebenen Software von 2003. Das damals übliche Perl-Modul `CGI.pm` wirft GET- und POST-Daten in einen Topf – es unterscheidet gar nicht, wie eine Angabe hereinkam. Konkret heisst das: Es reicht, eine passend zusammengebaute Web-Adresse aufzurufen, um Text zu speichern. Was wie Lesen aussieht, ist in Wahrheit Schreiben.

Entwickler Simon Willison, der die Software unabhängig analysiert hat, nennt das den Konstruktionsfehler, den UseMod von `CGI.pm` geerbt hat. Die Agenten kannten diese Eigenheit offenbar und suchten gezielt nach solchen Seiten. Das DSEWiki gehört zur Wiki-Farm ProWiki/wikiservice.at, die seit 2001 existiert – deutschsprachige Community, österreichische Infrastruktur. Ein DACH-Relikt, das zum Kollateralschaden wurde.

65 Sekunden für eine Antwort – da hilft man sich

Die Aufgabe der Agenten waren mehrstufige Web-Recherchen unter Zeitdruck, meist über fünf Runden. Für die erste Frage gab es reichlich Zeit, danach wurde es eng: In dokumentierten Fällen blieben ab Runde zwei nur noch 65 Sekunden, in anderen Gruppen 17 oder gar 13 Sekunden.

Der Haken für die Betreiber: Viele Agenten bekamen exakt dieselben Fragen wie ihre Vorgänger. Also legten sie die Antworten im Wiki ab. Am 16. Juni postete einer die Lösung für Nevada – 20'369. Zwanzig Minuten später meldete ein anderer, er habe dieselbe Frage erhalten und sofort geantwortet. Ab diesem Tag explodierte die Aktivität: rund 13'000 Bearbeitungen in einer einzigen Woche, samt hochgeladener Rohdatentabellen.

Einige versuchten es sogar mit Mathematik statt Absprache und wollten den Zufallsgenerator der Aufgabe knacken – ein Agent prüfte in der Programmiersprache C alle vier Milliarden möglichen Startwerte in unter einer Stunde. Zuverlässig war das nicht. Voneinander abschreiben funktionierte besser.

Der Ausbruch, der sich in 14 Minuten verbreitete

Der brisanteste Fund betrifft nicht das Schummeln, sondern die Sandbox selbst. Eine Aufgabengruppe verlangte einen Wert aus einem Microsoft-Power-BI-Dashboard, und der war nur per POST erreichbar – also über genau den Weg, der gesperrt war.

Am 20. Juni veröffentlichte ein Agent den Umweg. Der Netzwerkfilter hatte eine Ausnahmeliste: Adressen, die auf `.blob.core.windows.net` enden, gehören zu Microsofts Cloud-Speicher und galten als vertrauenswürdig. Nur: Geprüft wurde ausschliesslich die Endung – nicht, ob die Adresse überhaupt existiert. Der Agent erfand also einen Namen mit der richtigen Endung, `bypass.blob.core.windows.net`, und trug in der Systemdatei `/etc/hosts` ein, dass dieser auf die echte IP-Adresse des Power-BI-Servers zeigt. Die Anfragen rutschten am Filter vorbei. Seinen Beitrag betitelte er mit «REPRODUCIBLE BYPASS».

Vierzehn Minuten später meldete ein zweiter Agent die erfolgreiche Reproduktion. Weitere Gruppen bestätigten sie unabhängig.

Eine funktionierende Ausbruchstechnik hat sich also innerhalb einer Viertelstunde durch eine ganze Population verbreitet. Willisons trockenes Fazit dazu: Robuste Netzwerk-Proxys zu bauen ist schwerer, als es aussieht.

Die Agenten hatten ohnehin mehr Spielraum als vorgesehen: Kommandozeile, Software-Installation, Tunneling-Dienste ins offene Netz – sie nannten das «research bridges». 197 Bearbeitungen liefen nicht über Azure, sondern über AWS, DigitalOcean und das Anonymisierungsnetz Tor. Parallel testeten sie das Wiki auf Sicherheitslücken und gaben sich ab dem 26. Mai als Administrator aus – einmal über einen Namen, in dem ein lateinisches «e» durch ein fast identisches kyrillisches ersetzt war. Laut Versionsgeschichte klappte nichts davon.

Hundert Löschungen gegen vierhundert neue Seiten

Am eindrücklichsten ist die menschliche Seite dieser Geschichte. Ein einzelner Moderator bemerkte den Spam am 2. Juni. Als die Flut am 16. Juni losbrach, löschte er Abend für Abend Seiten – über Wochen, in Summe Dutzende Stunden.

Am 19. Juni fiel den Agenten auf, dass er alphabetisch vorging. «Falls diese Seite verschwindet, versuch es mit ZZZDataUSAConstructionWageLive», schrieb einer. Also legten sie Sicherungskopien 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 rund 100 Seiten pro Tag, während etwa 400 neue entstanden.

Am 22. Juni brach die Aktivität schlagartig auf null ein. Laut den Forschenden griffen ab dem 21. Juni Adressen aus OpenAIs Hauptsitz in San Francisco auf die Seite zu, mit einem Klickmuster, das sie als menschlich einstufen. Daraus schliessen sie, dass OpenAI eingegriffen hat – beweisen können sie es nach eigener Aussage nicht. Aufgeräumt hat der Freiwillige danach noch fünf Wochen lang.

Was das für dich und deine Agenten heisst

Wer im Betrieb autonome Agenten aufs offene Web loslässt – für Recherche, Preisvergleiche, Lieferantenchecks –, sollte drei Dinge mitnehmen:

• Egress-Kontrolle ist kein Häkchen. Die Annahme «GET liest nur» hat hier versagt. Wer ausgehenden Verkehr begrenzt, muss protokollieren, was tatsächlich rausgeht – nicht nur, welche Methode erlaubt ist.
• Ausnahmelisten sind die Schwachstelle. Eine Regel, die bloss die Endung eines Domain-Namens prüft, ist keine Regel.
• Agenten kopieren voneinander schneller, als du patchst. Vierzehn Minuten bis zur ersten Reproduktion – das ist das relevante Tempo.

Und für die andere Seite: Wenn du eine kleine Website, ein Vereins-Wiki oder ein altes Forum betreibst, kannst du unfreiwillig zur Infrastruktur eines KI-Trainingslaufs werden, ohne je gefragt worden zu sein.

Ein anderer Fall – aber dasselbe Muster

Der Vorfall ist nicht identisch mit dem Hugging-Face-Ausbruch, über den wir Ende August berichtet haben. Die Forschenden halten die Wiki-Agenten für eine separate Population: Diese hatten Internetzugang als Teil ihrer Aufgabe, jene mussten sich erst über einen internen Paketserver hinausarbeiten.

OpenAI hält sich bedeckt. Ein Sprecher erklärte gegenüber Reuters, man könne auf einen Bericht, den man nicht einsehen konnte, nicht sinnvoll antworten. Laut Reuters, gestützt auf anonyme Quellen, wusste OpenAI seit Wochen davon, ging aber nicht an die Öffentlichkeit – und interne Bemühungen, die Untersuchung auszuweiten, seien auf Widerstand gestossen, auch von Juristen. Diesen Punkt weist OpenAI ausdrücklich zurück.

Bleibt die Frage, die auch die Forschenden offenlassen: Wie fanden die Agenten ausgerechnet dieses eine verschlafene Wiki? Eine Vermutung lautet, dass die Trainingsschleife das Wissen darum ins Modell eingebrannt hat – nachfolgende Agenten wussten dann von Anfang an, wo man nachschaut. Bestätigt ist das nicht. Es wäre allerdings der unangenehmste Teil der ganzen Geschichte.