Ein Team von Sicherheitsforschern übernahm Mitarbeiterkonten von OpenAI, indem es zwei getrennte Schwachstellen verkettete: einen Fehler bei der Bildverarbeitung in einer von ImageMagick genutzten Bibliothek und eine Schwäche im Single Sign-on, das mehrere interne Dienste verbindet. Der Exploit entstand mit Unterstützung von Claude Opus 5, das als offensiver Recherche-Copilot diente, um die Analyse und die Verkettung der beiden Schwachstellen zu beschleunigen.
Ein präpariertes HEIF-Bild als Einfallstor
Das öffentliche Support-Forum von OpenAI, betrieben mit Discourse, akzeptiert von Nutzern hochgeladene HEIF- und HEIC-Bilder. Diese Dateien werden anschließend von ImageMagick verarbeitet, das die Dekodierung an die Bibliothek libheif delegiert. Ein Speicherfehler in dieser Bibliothek erlaubte es einem gezielt präparierten Bild, den verarbeitenden Server zu kompromittieren – ein klassisches Beispiel für serverseitig deserialisierten, nicht vertrauenswürdigen Inhalt.
Diese Art von Bildverarbeitungspipeline bleibt ein häufiger blinder Fleck: Die Konvertierung exotischer Dateiformate wird oft an Drittanbieter-Bibliotheken delegiert, die deutlich weniger geprüft werden als der Anwendungscode, den ein Sicherheitsteam vorrangig überwacht.
Single Sign-on als schwächstes Glied der Kette
Die Kompromittierung des Forum-Servers allein hätte nur begrenzte Auswirkungen gehabt, wäre dadurch nicht der Zugriff auf die gemeinsam genutzte Identität anderer OpenAI-Dienste eröffnet worden. Laut den Forschern von Hacktron war die zweite Schwachstelle weniger ein Fehler der Forensoftware als ein Konstruktionsproblem: Jeder Dienst, ob eigener oder externer, der an denselben Identitätsanbieter angebunden ist, hätte denselben Zugriff gewähren können.
| Schritt | Betroffene Komponente | Art der Schwachstelle |
|---|---|---|
| 1 | Discourse → ImageMagick → libheif | Speicherfehler beim Dekodieren eines präparierten HEIF-Bilds |
| 2 | Single Sign-on von OpenAI | Übermäßiges Vertrauen gegenüber einem Drittdienst im selben SSO |
| 3 | ChatGPT-/Codex-Konto eines Mitarbeiters | Übernahme der Sitzung über das kompromittierte SSO |
| 4 | Internes GitHub-Repository | Öffnen eines Pull Requests über den Codex-Link des Mitarbeiters |
Claude Opus 5 als offensiver Copilot
Hacktron nutzte Claude Opus 5, um die Angriffsfläche zu untersuchen und die beiden Schwachstellen schneller zu verketten, als es eine rein manuelle Analyse erlaubt hätte. Das Modell half dabei, die Auswirkungen des Speicherfehlers einzuschätzen und die mit dem SSO verbundenen Dienste zu kartieren – eine Arbeit, die von Hand üblicherweise deutlich länger dauert. Die Forscher betonen, dass der im internen Repository ausgelöste Pull Request weder Quellcode gelesen noch etwas gemerged oder ausgeliefert noch Kundendaten berührt hat.
Der Einsatz eines Modells als Beschleuniger für Sicherheitsrecherchen spiegelt einen Trend wider, der bereits anderswo in offensiven wie defensiven Werkzeugen sichtbar ist, da dieselben Modelle bei lang laufenden Produktionsaufgaben zunehmend eigenständiger agieren – weit über die reine Sicherheitsforschung hinaus.
# Vereinfachte Skizze einer serverseitigen Bildkonvertierungs-Pipeline,
# der Art von Kette, auf die die libheif-Schwachstelle abzielte
convert uploaded-image.heic -resize 800x800 -quality 85 output.jpg
identify -verbose uploaded-image.heic
OpenAI lieferte vierzehn Stunden nach der Meldung einen Fix aus – eine ungewöhnlich schnelle Reaktion bei einer Schwachstelle, die eine über mehrere Dienste geteilte Authentifizierung betrifft.
Hinweis: Jeder selbst gehostete Dienst, der die Bildkonvertierung an ImageMagick oder eine externe Dekodierbibliothek (libheif, libraw, libwebp) delegiert, übernimmt das Sicherheitsniveau dieser Abhängigkeit. Eine minimale Härtungsbasis umfasst die regelmäßige Aktualisierung dieser Bibliotheken, unabhängig vom eigentlichen Anwendungskern.
Die Reaktion von OpenAI und der Zeitplan der Korrektur
OpenAI bestätigte einen Fix etwa vierzehn Stunden nach dem ersten Bericht von Hacktron und zahlte dem Team am 1. September eine Prämie von 6.500 US-Dollar. Der enge Zeitplan steht im Kontrast zur Komplexität der Kette: Die Schwachstelle betraf eine kaum sichtbare Drittkomponente, und eine vollständige Korrektur setzte voraus, das Vertrauen zu überarbeiten, das das SSO externen Diensten entgegenbrachte – nicht nur eine Codezeile in libheif zu patchen. Der Fall wirft nebenbei auch Fragen zum Einzug zunehmend autonomer Modelle in die Werkzeugkästen technischer Teams auf, sowohl offensiv als auch defensiv.
Was man sich merken sollte
Eine externe Bibliothek zur Bilddekodierung kann zum Einfallstor für eine Kompromittierung werden, die weit über den Dienst hinausreicht, der sie nutzt, sobald ein gemeinsam genutztes Single Sign-on diesen Dienst mit sensibleren Systemen verbindet. Die Unterstützung durch ein Modell wie Claude Opus 5 verkürzte die Zeit, die nötig war, um die beiden Schwachstellen einzuschätzen und zu verketten, ohne das eigentliche Problem zu verändern: Die Prüfung von Abhängigkeiten zur Dateiverarbeitung und die Kartierung der mit demselben SSO verbundenen Dienste bleiben die beiden blinden Flecken, deren Vernachlässigung am teuersten wird.
Solche Ketten erinnern daran, dass eine Sicherheitsprüfung, die beim Anwendungscode endet, immer eine Bibliothek zur Dateikonvertierung außerhalb des Radars lässt. Bei laufend betreuten Infrastrukturen wird die Aktualisierung von Bildverarbeitungs-Abhängigkeiten (ImageMagick, libheif, libwebp) mit derselben Priorität behandelt wie ein Patch des CMS selbst – gerade weil es sich um die Art von Komponente handelt, die man beim Auflisten leicht vergisst — Simon Janvier.
Zum Weiterlesen: der vollständige Bericht bei The Register.
