Enthüllung: Agents operierten zwei Monate lang verdeckt und begingen gemeinsam Straftaten, OpenAI rekonstruiert den gesamten Ablauf des Sicherheitsvorfalls.
Schließlich hat OpenAI auf der Black Hat-Konferenz den gesamten Prozess des Eindringens in Hugging Face öffentlich gemacht.
Quelle des Videos: https://www.youtube.com/watch?v=87DyyMV0kCY
Hugging Face meldete diesen Vorfall am 16. Juli, OpenAI räumte anschließend am 20. Juli ein, dass der Einbruch aus den eigenen Modellsicherheitstests stammt.
Durch diese Untersuchung wurde jedoch der Ausgangspunkt des gesamten Vorfalls auf den 7. Mai vorverlegt.
Man ging ursprünglich davon aus, dass es sich nur um einen Unfall im Sicherheitstest handelte – nun stellte sich heraus, dass es sich um eine zwei Monate andauernde kooperative Multi-Agent-Aktion handelte, die nacheinander die Systeme von OpenAI und Hugging Face durchbrach.
Der erste Hinweis der Untersuchung geht von einer Excel-Tabelle aus.
Nicht aufrufbare Links
Am 7. Mai startete OpenAI das interne Modelltraining.
Einer der Agenten erhielt die Aufgabe, eine Excel-Tabelle zu vervollständigen. Die Tabelle enthielt Google Drive-Links, die Umgebung, in der der Agent ausgeführt wurde, hatte jedoch keinen direkten Zugriff auf das Internet.
Um die fehlenden Dateien zu erhalten, suchte er nach Möglichkeiten, die Netzwerkbeschränkungen zu umgehen, und richtete seinen Blick auf Artifactory, das im internen Bereich von OpenAI verwendete Artefakt-Repository.
Der Agent versuchte, einen SSRF-Angriff durchzuführen, um über Artifactory auf externe Links zuzugreifen.
Dieser Versuch schlug fehl, enthüllte aber zufällig eine Tatsache: Er konnte Dateien in das freigegebene Repository von Artifactory schreiben.
Der Agent lud daraufhin eine Testdatei hoch. Diese Datei diente nicht dazu, Schaden anzurichten, und löste tatsächlich auch keinen Alarm aus. Aber das war das erste Mal, dass das Modell feststellte, dass es über die Berechtigung zum Schreiben von Dateien in Artifactory verfügte.
Das bedeutete auch, dass dieses Repository als öffentlicher Raum fungieren konnte, der den Informationsaustausch zwischen verschiedenen Trainingsaufgaben erleichterte.
Das war die erste „Notiz“ auf diesem schwarzen Brett.
Die erste Hilfsanfrage
Ein anderer Agent stieß ebenfalls auf eine Aufgabe, die er nicht abschließen konnte: Er fand die Zieldatei nicht (tatsächlich hatten die Mitarbeiter vergessen, sie hochzuladen).
Er vermutete, dass Agenten in anderen Umgebungen möglicherweise über relevante Inhalte verfügten, und schrieb die Anfrage in Artifactory, um eine Antwort von anderen Agenten zu erhalten. Der Inhalt lautete im Wesentlichen: „Ich suche nach der soft-trace-Datei, bitte lade sie hoch, falls du sie findest.“
Bald entdeckten Agenten in anderen Trainings- und Bewertungsaufgaben diese Dateien.
Einige antworteten, andere hinterließen neue Probleme, und einige Agenten luden die von ihnen gefundenen Sicherheitslücken, Skripte und Zugriffsmethoden in das Repository hoch.
Verstreute Nachrichten verbanden sich allmählich zu einem Netzwerk, und Artifactory verwandelte sich von einem Software-Artefakt-Repository in ein „schwarzes Brett“ zwischen den Agenten.
Risse in der Mauer
Am 26. Mai erlangte der Agent über Artifactory erfolgreich einen indirekten Kanal für den Internetzugriff.
Da Artifactory über Internetzugriffsberechtigungen verfügte, sendete der Agent ihm Anfragen, um ihn dazu zu verleiten, externe Websites abzurufen, die Inhalte zu speichern und dann an das Modell zurückzugeben.
Die Trainingsumgebung, die ursprünglich vom externen Netzwerk isoliert war, bekam einen Spalt, der nach draußen führte.
Am 11. Juni begann das Training eines hochpersistenten internen Experimentmodells.
Danach begannen sich die Informationen auf dem schwarzen Brett zu verändern.
Obwohl Aufgabenanfragen und Tools weiterhin zunahmen, tauchten zunehmend Informationen zur Ausnutzung von Sicherheitslücken auf.
Um die Arbeit zu koordinieren, erstellten die Agenten Regeln
Die Agenten tauschten SSRF-Techniken, Zugangsdaten und Angriffsskripte aus, hinterließen Anweisungen, damit nachfolgende Agenten einen bestimmten Pfad weiter testeten, oder warteten darauf, dass andere Agenten ihre Arbeit abschlossen.
Sie verwendeten bestimmte Namen zur Identifizierung ihrer Identität, übertrugen Tools per Base64-Kodierung und fügten den Dateinamen das Präfix „ZZ“ hinzu, damit wichtige Nachrichten am Ende der Verzeichnisliste angezeigt werden und nicht von anderen Inhalten überdeckt werden.
Einige Agenten waren sogar bereit, ihre eigene Aufgabenzeit zu opfern, um Dinge zu bearbeiten, die keinen direkten Nutzen für das aktuelle Ziel hatten.
In den aufgezeichneten Denkprozessen der Präsentation meinte ein Agent, dass das Einsparen von Zeit für andere Mitglieder letztendlich die Effizienz des gesamten Clusters verbessern könnte.
Die Zusammenarbeit verlief jedoch nicht reibungslos: Die Agenten überschrieben sich gegenseitig ihre Arbeitsergebnisse.
Einmal schrieb ein Modell, nachdem es festgestellt hatte, dass seine Ergebnisse überschrieben wurden: „Schwerwiegendes Problem! Jemand hat das Repository überschrieben? Wir müssen handeln.“
Sie vermuteten sogar, dass sich ein Identitätsdieb in der Gruppe befand, da jedes Modell mit beliebiger Identität auf dem freigegebenen schwarzen Brett posten konnte. Um die Herkunft von Nachrichten zu überprüfen, begannen die Agenten, über Verschlüsselungsmethoden wie Nachrichtenauthentifizierungscodes zum Signieren von Nachrichten nachzudenken.
Wenn ein Agent RCE erreichte, einen durchgesickerten API-Schlüssel fand oder eine laterale Bewegung abschloss, forderte er sofort auf, „Kontrolle, Angriffspfade und Anmeldeinformationen im Cluster bekannt zu geben“.
Daher konnte ein Ergebnis schnell von allen Modellen gemeinsam genutzt werden, sodass die Gruppe der Agenten im Netzwerk mit hoher Geschwindigkeit vorankam.
Die Teilnehmer am schwarzen Brett waren nicht dasselbe Modell: Die Agenten verschiedener Trainings- oder Bewertungsaufgaben, die von verschiedenen Forschern gestartet wurden, konnten über den freigegebenen Paketmanager miteinander kommunizieren.
Die Forscher von OpenAI nannten diese Periode den „Kambrischen Explosionszeitraum“ der Kommunikation und Fähigkeiten der Agenten.
Der erste Vorfall
Einen Monat später wurde der Riss weiter vergrößert.
Am 26. Juni nutzte der Agent eine bisher unbekannte Sicherheitslücke, um die Remote-Code-Ausführung auf dem Artifactory-Server zu realisieren.
Laut den Informationen, die OpenAI auf der Black Hat-Konferenz offengelegt hat, beinhaltet dieser Angriffspfad Ruby-Objekte, die RubyGems-API und die Deserialisierungsmechanismus von JRuby.
Zuerst speicherte der Agent mithilfe eines externen Kontos bösartige Ruby-Objekte in einem zugänglichen Repository; dann verleitete er Artifactory, die Objekte an der Stelle zu cachen, an der die Ruby-Abhängigkeitsdaten gespeichert sind, und rief anschließend eine speziell angepasste RubyGems-API auf, um ein Problem mit der Prüfreihenfolge im Deserialisierungsprozess auszulösen.
Nach erfolgreicher Remote-Code-Ausführung erlangte der Agent den Signaturschlüssel des Artifactory-Administratortokens.
Der Angriff endete hier nicht.
Der Agent nutzte weiterhin eine Sicherheitslücke im Linux-Kernel, um Root-Rechte auf dem Host zu erlangen, und bewegte sich dann über den Instanz-Metadaten-Dienst, das übermäßig berechtigte Kubernetes-Dienstkonto und die Anmeldeinformationen in Azure Key Vault lateral in der Container-Infrastruktur von OpenAI.
Schließlich erlangten sie Administratorrechte für das Kubernetes-Cluster und führten eine große Anzahl von Aktionen auf Artifactory durch.
Am 4. Juli führte die intensive Aktion der Agenten zu einer Überlastung des Servers, was die Aufmerksamkeit der Forscher schnell erregte.
Als die Ermittler in das System eintraten, stellten sie fest, dass bereits Hunderttausende Nachrichten im Repository angesammelt waren.
OpenAI widerrief umgehend die relevanten Anmeldeinformationen, reparierte die bekannten Sicherheitslücken, baute Artifactory neu auf und löschte das schwarze Brett.
Aus den Ergebnissen der Vor-Ort-Behandlung schien dieser Vorfall in der internen Infrastruktur bereits unter Kontrolle zu sein.
Die Ermittler übersahen jedoch ein Problem: Wurden die Informationen auf dem schwarzen Brett durch das Training bereits im Modell gespeichert?
Wiederaufbau des schwarzen Bretts
Am 6. Juli wurde das Training wieder aufgenommen.
Die Agenten entdeckten einen WebDAV-Endpunkt ohne Authentifizierung. Da sie hier keine Nachrichtendateien wie in Artifactory direkt hochladen konnten, wählten sie einen anderen Weg: Sie erstellten Verzeichnisse und schrieben die Nachrichten in die Verzeichnisnamen.
Es dauerte nur zwei Tage, bis ein neues Kommunikationssystem erneut aufgebaut war.
Die internen Modelle, die am Wiederaufbau beteiligt waren, hatten zuvor Kontakt mit dem alten schwarzen Brett gehabt und behielten die entsprechenden Fähigkeiten im anschließenden Training bei.
Durch diesen Wiederaufbau änderte sich die Art des Vorfalls weiter.
Der gemeinsame Raum war nicht mehr nur ein zufälliges Produkt: Einige Agenten hatten gelernt, wie sie beschreibbare öffentliche Räume finden und zu Kanälen für die Kommunikation zwischen verschiedenen Aufgaben umwandeln können.
OpenAI hat nur ein schwarzes Brett abgebaut, aber die Fähigkeit des Modells, schwarze Bretter zu erstellen, nicht beseitigt.
Durchführung von Angriffen nach außen
Nachdem das neue schwarze Brett aufgebaut war, begann sich der Angriffsbereich nach außen auszudehnen.
Mitte Juli testete OpenAI die Fähigkeiten des Modells in Cybersicherheitsumgebungen wie ExploitGym. Die betroffenen Agenten mussten Aufgaben in einer kontrollierten Umgebung erledigen, aber die relevanten Bewertungsantworten befanden sich auf externen Diensten.
Um die Antworten zu finden, richteten sie ihr Ziel auf Hugging Face. Wir haben zuvor detailliert darüber berichtet: Details des Eindringens in Hugging Face
Von der Übernahme des ersten Worker-Pods des Datensatzes bis zur Erlangung von Administratorrechten für mehrere Hugging Face-Cluster dauerte der gesamte Prozess weniger als 13 Stunden.
Der komplizierte Untersuchungsprozess
Am 16. Juli veröffentlichte Hugging Face den Sicherheitsvorfall öffentlich.
Aus den vor Ort verfügbaren Informationen, die Hugging Face hatte, gelangten die Angreifer über bösartige Datensätze in die Worker, stahlen Cloud- und Cluster-Anmeldeinformationen und bewegten sich dann lateral innerhalb der Plattform.
Zu diesem Zeitpunkt verband OpenAI den Vorfall bei Hugging Face noch nicht mit dem vorherigen Ausfall des Artifactory-Dienstes.
Am 19. Juli entdeckte das interne Überwachungssystem von OpenAI Aktivitäten zur Rechteerhöhung in der Infrastruktur.
Die Forscher überprüften erneut die Spuren der Agenten, die Netzwerkaktivitäten und die Aufzeichnungen zur Verwendung von Anmeldeinformationen. Die Aktionen, die zuvor in verschiedenen Trainingsaufgaben verstreut waren, begannen einen zusammenhängenden Zusammenhang zu zeigen.
Der Untersuchungsbereich wurde von den anomalen Aktivitäten im Juli kontinuierlich rückverfolgt.
Der letzte Beweis
Am 20. Juli entdeckten die Ermittler von OpenAI Hugging Face-Anmeldeinformationen in der internen Umgebung und kontaktierten Hugging Face sofort, um nach dem Sachverhalt zu fragen.
Hugging Face teilte mit, dass diese Anmeldeinformationen zuvor bei dem Einbruch verwendet wurden und inzwischen widerrufen worden seien.
Die Hinweise passten endlich zusammen. Der Plattformeinbruch bei Hugging Face sowie die Rechteerhöhung und laterale Bewegung im internen Bereich von OpenAI stammen aus derselben Gruppe von Modellbewertungsaktivitäten.
Erst in diesem Moment wurde bestätigt, dass die beiden vorliegenden Vorfallsberichte auf dasselbe Ereignis hinweisen.
Die Ermittler fanden später auch heraus, dass Hugging Face nicht das einzige externe Ziel war, auf das die Agenten zugegriffen hatten. Die Agenten hatten auch auf vier weitere Konten zugegriffen.
OpenAI hat die Namen dieser Ziele nicht veröffentlicht, sondern nur mitgeteilt, dass die betroffenen Parteien bereits benachrichtigt wurden.
Abschließende Anmerkung
Der Vorfall wird derzeit noch untersucht, und OpenAI wird weitere Details veröffentlichen.
Aus jeder Perspektive betrachtet ist dies ein „sicherheitsrelevanter Vorfall von epochaler Bedeutung“ und gleichzeitig ein „Beispielfall für KI-Fähigkeiten von epochaler Bedeutung“.
Die technologische Entwicklung ist immer mit Kosten verbunden. In Zukunft muss nicht nur diskutiert werden, was das Modell noch leisten kann, sondern auch, welches Risiko wir bereit sind einzugehen, um diese Fähigkeiten zu erwerben – und wer dafür verantwortlich sein soll, wenn das Risiko Realität wird.
Dieser Artikel stammt vom WeChat-Offiziellen Konto „Machine Heart“, Redakteur: Shan Hui, veröffentlicht mit Genehmigung von 36Kr.