Wenn benutzerdefinierte GPTs zu Cloud-Hintertüren werden: Der ChatGPT SSRF Hack und die Zukunft der KI-Sicherheit

Wenn man lange genug in der Sicherheitsbranche tätig ist, entwickelt man irgendwann eine schlechte Angewohnheit: Man hört auf, "Funktionen" zu sehen, und beginnt, potenzielle Angriffswege zu erkennen. Die jüngste Geschichte über "ChatGPT gehackt mit benutzerdefinierten GPTs unter Ausnutzung einer SSRF-Schwachstelle, um Geheimnisse preiszugeben" ist ein Lehrbuchbeispiel. Was wie eine praktische Aktionsfunktion für benutzerdefinierte GPTs aussah, entpuppte sich als Tunnel direkt in die Cloud-Umgebung von OpenAI. Keine exotische Prompt-Zauberei, keine schiefgelaufene "KI-Magie" - nur ein sehr alter Fehler, serverseitige Request Forgery, der in einer sehr neuen Plattform wiederentdeckt wurde.

Genau deshalb ist dieser Vorfall so wichtig. Es handelt sich nicht um eine weitere Hype-Schlagzeile über KI, die aus dem Ruder läuft. Es ist eine Erinnerung daran, dass die traditionellen Regeln der Anwendungs- und Cloud-Sicherheit mit aller Macht zurückkehren, sobald man LLMs in eine reale Infrastruktur einbettet. Die Modelle mögen neu sein, die zugrunde liegenden Fehler sind es nicht.

Rekonstruktion des Exploits: von "Aktion hinzufügen" bis zum Cloud-Token

Um zu verstehen, was passiert ist, müssen Sie sich ansehen, wie Custom GPTs funktionieren. Die Schnittstelle von OpenAI ermöglicht es Ihnen, Aktionen zu definieren, die im Wesentlichen externe HTTP-APIs sind, die Ihr GPT auf der Grundlage eines OpenAPI-Schemas aufrufen kann. Für die Benutzer bedeutet dies, dass Ihr GPT "Superkräfte" erhält: Es kann Daten abrufen, Workflows auslösen und sich mit internen Systemen verbinden. Unter der Haube bedeutet dies, dass es einen Backend-HTTP-Client gibt, der innerhalb der OpenAI-Infrastruktur läuft, der gerne URLs aufruft, die Sie beschreiben, und die Antworten zurück in das Modell einspeist.

Einem Forscher von Open Security ist genau das aufgefallen. Beim Spielen mit benutzerdefinierten GPTs sahen sie das bekannte Muster: benutzergesteuerte URLs, eine "Test"-Schaltfläche, die Live-Anfragen sendet, und einen Server, der eindeutig in einer Cloud-Umgebung läuft. Jeder, der schon einmal Cloud-Pen-Tests durchgeführt hat, wird den folgenden Instinkt erkennen: Überprüfen Sie, ob Sie diesen Server austricksen können, damit er interne Adressen in Ihrem Namen anruft. Das ist die Essenz von SSRF.

In Cloud-Umgebungen ist das wertvollste interne Ziel fast immer der Metadatendienst. Auf Azure, wie auch auf anderen Clouds, befindet er sich unter der link-lokalen Adresse 169.254.169.254. Innerhalb einer VM oder eines Containers kann dieser Endpunkt Details über die Instanz offenlegen und, was noch wichtiger ist, kurzlebige Token ausgeben, die es Arbeitslasten ermöglichen, Cloud-Verwaltungs-APIs aufzurufen. Von außerhalb der Cloud können Sie ihn nicht erreichen. Das ist genau der Grund, warum SSRF so wichtig ist: Sie kapern den Blickwinkel des Servers und zwingen ihn, mit Dingen zu sprechen, die Sie als externer Angreifer nicht erreichen können.

Das erste Hindernis für den Forscher war, dass Custom GPT Actions nur HTTPS-URLs zulässt, während der Metadatendienst nur HTTP verwendet. Auf den ersten Blick sieht diese Einschränkung wie eine Verteidigung aus, aber in der Praxis ist sie nur ein weiteres Puzzlestück. Die Abhilfe war einfach: Registrieren Sie eine externe HTTPS-Domäne unter der Kontrolle des Forschers und lassen Sie sie mit einer 302-Weiterleitung antworten, die auf den http://169.254.169.254 Metadaten-URL und sehen Sie, ob das Actions-Backend der Umleitung gefolgt ist. Das tat es. Plötzlich führte ein unschuldig aussehender HTTPS-Aufruf in der benutzerdefinierten GPT-Konfiguration zu einem HTTP-Aufruf an den internen Cloud-Metadaten-Endpunkt.

Der Metadatendienst von Azure ist jedoch nicht völlig naiv. Um gelegentlichen Missbrauch zu verhindern, verlangt er einen speziellen Header, Metadaten: wahrbei jeder Anfrage. Fehlt die Kopfzeile, weigert sich der Dienst, echte Daten preiszugeben. An diesem Punkt könnte man meinen, dass das System wieder sicher ist, da die OpenAPI-Schema-Schnittstelle, die zur Definition von Aktionen verwendet wird, keine willkürliche Header-Konfiguration zulässt. Große Systeme haben jedoch selten nur eine Konfigurationsoberfläche. In diesem Fall unterstützt die Actions-Funktion auch die Idee von "API-Schlüsseln" und anderen Authentifizierungs-Headern, die Sie definieren können, wenn Sie einen externen Dienst verdrahten. Diese Header werden dann automatisch an ausgehende Anfragen angehängt.

Das reichte aus, um die Kette zu vervollständigen. Durch die Definition eines gefälschten "API-Schlüssels", dessen Header-Name wörtlich lautet Metadaten und dessen Wert war wahrhat der Forscher das Backend davon überzeugt, genau den Header einzubinden, den Azure IMDS erwartet. Kombinieren Sie das mit dem Redirect-Trick und Sie haben jetzt einen SSRF-Kanal vom Custom GPT Actions-Backend in den Metadaten-Service, mit einem gültigen Metadaten: wahr Kopfzeile.

Sobald dieser Kanal eingerichtet war, war der Rest fast mechanisch. Der Forscher bat den Metadatendienst um ein OAuth2-Token, das für die Azure Management API bestimmt war, und verwendete dabei den bekannten IMDS-Pfad. Die Antwort enthielt ein Zugriffstoken, das an die von der ChatGPT-Infrastruktur verwendete Cloud-Identität gebunden war. Dieses Token konnte zumindest die Verwaltungsendpunkte abfragen und möglicherweise auf sensible Ressourcen zugreifen, je nachdem, wie viele Berechtigungen die Identität hatte. An diesem Punkt stoppte der Forscher, meldete die Ergebnisse über das Bug Bounty-Programm von OpenAI und OpenAI stufte die Schwachstelle als hochgradig gefährlich ein und veranlasste, sie zu patchen.

Das Besondere an dieser Kette ist, dass der Angreifer weder Shell-Zugriff noch Quellcode oder einen klassischen Fehler im HTTP-Stack benötigte. Alles geschah innerhalb normaler Konfigurationsbildschirme: URLs, Authentifizierungseinstellungen und eine Testschaltfläche, die den Unfug pflichtbewusst ausführte.

Eine kleine Codeskizze einer SSRF-ähnlichen Sonde

Um dies zu verdeutlichen, stellen Sie sich ein sehr kleines internes Hilfsskript vor, das ein Sicherheitsingenieur verwenden könnte, um einen HTTP-Client im Stil von "Actions" auf seine Unbedenklichkeit zu überprüfen. Das Ziel ist nicht, echte Metadatendienste in der Produktion anzugreifen, sondern die Gewohnheit zu kodifizieren, nach unerwarteten Umleitungen und internen IP-Hops in Staging- oder Laborumgebungen zu suchen:

importiere Anfragen
from urllib.parse import urljoin

def trace_request(base_url: str, path: str = "/"):
    url = urljoin(base_url, path)
    print(f"[+] Anfordern von {url}")
    try:
        resp = requests.get(url, timeout=3, allow_redirects=True)
    except Exception as e:
        print(f"[!] Fehler: {e}")
        return

    print(f"[+] Endgültige URL: {resp.url}")
    print(f"[+] Status: {resp.status_code}")
    print("[+] Umleitungskette:")
    for h in resp.history:
        print(f" {h.status_code} -> {h.headers.get('Location')}")

    # Sehr grobe Heuristik: warnen, wenn wir auf einer internen IP gelandet sind
    if resp.raw._connection und hasattr(resp.raw._connection, "sock"):
        peer = resp.raw._connection.sock.getpeername()[0]
        print(f"[+] Peer IP: {peer}")
        if peer.startswith("10.") oder peer.startswith("192.168.") oder peer.startswith("169.254."):
            print("[!] Warnung: Backend folgte einem Redirect auf eine interne Adresse")

if __name__ == "__main__":
    # Beispiel: durch einen kontrollierten Test-Endpunkt im eigenen Labor ersetzen
    trace_request("")

Ein Skript wie dieses "nutzt ChatGPT nicht aus", aber es hat dieselbe investigative Form: Starten Sie von einer vermeintlich sicheren externen URL, folgen Sie Umleitungen und beschweren Sie sich lautstark, wenn Ihr HTTP-Client plötzlich mit internen oder link-lokalen IP-Bereichen spricht. Dieses Muster in eine Automatisierung umzuwandeln und es mit den Komponenten zu vergleichen, die Ihre eigenen KI-Aktionen ausführen, ist weitaus nützlicher als nur über den Vorfall zu lesen.

Es handelt sich nicht um einen "KI-Bug", sondern um Cloud-Missbrauch der alten Schule auf einer neuen Stufe

Es ist sehr verlockend, dies als "ChatGPT wurde gehackt" zu lesen und weiterzumachen. Diese Sichtweise geht an der eigentlichen Lektion vorbei. Nichts an dem Modell selbst hat sich falsch verhalten. Es gab keine Eingabeaufforderung, die irgendwie verbotene Fähigkeiten freigeschaltet hat. Der LLM tat, was ihm aufgetragen wurde: Er rief eine Aktion auf, las das Ergebnis und fasste es zusammen. Die Schwachstelle lag ausschließlich in der Verbindung zwischen dem LLM und der Außenwelt.

Dieser Klebstoff ist genau das, worauf Sicherheitsteams ihr Augenmerk richten müssen. Wann immer Sie einem LLM die Möglichkeit geben, Tools, Aktionen oder Plugins aufzurufen, machen Sie ihn effektiv zu einem programmierbaren Client in Ihrer Infrastruktur. In der Vergangenheit rief ein Benutzer Ihre API manuell auf, und Sie überprüften die Eingaben. Jetzt gibt ein Benutzer einem Modell Anweisungen, und das Modell übersetzt diese in API-Aufrufe in seinem Namen. Das Modell wird zu einem weiteren Weg für die feindliche Absicht, Ihr Backend zu erreichen.

So gesehen ist dieser Vorfall einfach ein OWASP SSRF in einem anderen Gewand. Die Bedingungen sind alle bekannt: vom Benutzer beeinflusste URLs, ein Server, der interne oder privilegierte Endpunkte erreichen kann, fehlende oder unvollständige Ausgangskontrollen und ein Cloud-Metadatenservice, der für reguläre Workloads zu zugänglich ist. Der Unterschied ist, dass der Einstiegspunkt nicht mehr ein klassisches Webformular oder ein JSON-Feld ist, sondern ein Konfigurationsblock, der Custom GPTs leistungsfähiger machen soll.

Das ist auch der Grund, warum der Explosionsradius wichtig ist. Der betroffene Server war kein zufälliger Microservice, sondern Teil der mandantenfähigen Infrastruktur von ChatGPT, die sich in der Azure-Umgebung von OpenAI befand. Jedes Token, das über IMDS erlangt wurde, gehörte zu einer Arbeitslast, die bereits einen bedeutenden Zugriff hatte. Selbst wenn lokale Verteidigungsmaßnahmen die Möglichkeiten des Angreifers einschränkten, unterscheidet sich das Risikoprofil grundlegend von einer vergessenen Test-VM.

KI als Integrationsdrehscheibe: Vergrößerung der Angriffsflächen und Verschiebung der Vertrauensgrenzen

Die interessantere Geschichte hinter diesem Fehler ist architektonischer Natur. KI-Plattformen werden immer mehr zu Integrationszentren. Ein benutzerdefiniertes GPT für ein Vertriebsteam kann mit einem CRM, einem Abrechnungssystem und einem Dokumentenspeicher kommunizieren. Ein sicherheitsorientiertes GPT kann mit Scannern, Ticketing-Systemen und CI/CD kommunizieren. In jedem Fall ist nicht das LLM das Asset, sondern die Daten und Aktionen hinter diesen Konnektoren.

Sobald Sie diese Realität akzeptieren, muss sich Ihr mentales Bedrohungsmodell ändern. Sie können bei "KI-Sicherheit" nicht mehr nur an Soforteinspeisung, Datenlecks oder toxische Ergebnisse denken. Sie müssen auch sehr unglamouröse Fragen zu Netzwerkgrenzen, Cloud-Identität und Mieterisolierung stellen.

Mit wem kann die Infrastruktur, auf der Ihre Aktionen ausgeführt werden, im Netz tatsächlich kommunizieren? Die Standardeinstellung in vielen Cloud-Umgebungen lautet: "Alles, was nach außen geht, ist erlaubt, solange DNS aufgelöst wird." Das war sinnvoll, als die Dienste noch relativ einfach waren und Ingenieure Flexibilität wünschten. Wenn man jedoch eine LLM-Plattform dazwischen schaltet, hat jeder Tenant plötzlich die Möglichkeit, neue ausgehende Ziele über die Konfiguration und nicht über den Code vorzuschlagen. Wenn es keine strengen Egress-Richtlinien gibt, haben Sie effektiv einen programmierbaren SSRF-Starter geschaffen.

Wie viele Berechtigungen haben die von diesen Arbeitslasten verwendeten Identitäten tatsächlich? Im Fall von ChatGPT waren die Forscher in der Lage, ein Token für die Azure Management API anzufordern. Selbst wenn dieses Token durch Rollenzuweisungen eingeschränkt war, stellt es dennoch ein hochwertiges Geheimnis dar. In vielen Unternehmen ist die Versuchung groß, der "Plattforminfrastruktur" weitreichende Berechtigungen zu erteilen, da dies die Bereitstellung vereinfacht. Für alles, was indirekt durch Benutzereingaben gesteuert werden kann - insbesondere durch KI - ist diese Versuchung gefährlich.

Wo genau liegen die Vertrauensgrenzen zwischen den Tenants, zwischen der Steuerungsebene und der Datenebene sowie zwischen der KI-Laufzeit und dem Rest der Cloud? Ein gut durchdachtes System sollte davon ausgehen, dass die Konfiguration eines Tenants nachteilig sein könnte, dass jeder ausgehende Anruf im Namen dieses Tenants feindlich sein könnte und dass jede Ausweitung von Aktionen über Metadaten bis hin zu Verwaltungs-APIs ein realistisches Ziel für Angreifer darstellt. Aus dieser Perspektive sind Muster wie strikte Netzwerksegmentierung, begleitende Sidecars zur Durchsetzung von Richtlinien und dedizierte Dienstidentitäten nicht verhandelbar, sondern "nice to have".

Von einem Vorfall zu einer wiederholbaren Prüfmethodik

Für Verteidiger und Entwickler liegt der eigentliche Wert dieser Geschichte nicht in dem spezifischen Fehler, sondern in der Test-Mentalität, die sie veranschaulicht. Der Forscher behandelte Custom GPT Actions im Wesentlichen als eine seltsame neue Art von HTTP-Client und ging dann eine vertraute Checkliste durch: Kann ich die URL kontrollieren, kann ich interne Hosts erreichen, kann ich Umleitungen missbrauchen, kann ich Header injizieren, kann ich Metadaten treffen, kann ich das in ein Cloud-Token verwandeln?

Diese mentale Checkliste ist genau das, was in modernen Penetrationstest-Workflows für KI-Plattformen automatisiert werden sollte. Anstatt auf eine Schlagzeile und einen Bounty-Bericht zu warten, sollten Teams routinemäßig ihre eigene benutzerdefinierte GPT-Infrastruktur, Plugin-Ökosysteme und Tool-Ketten zu Zielen machen.

Um dies ein wenig greifbarer zu machen, können Sie sich eine "AI Actions SSRF review" als eine einfache, wiederholbare Sequenz wie diese vorstellen:

Sobald Sie diese Art von Tabelle für Ihre Umgebung aufgeschrieben haben, wird es viel einfacher, die von Ihnen durchgeführten Tests zu automatisieren und zu erklären. Sie können sie in interne Playbooks einfügen, mit Anbietern teilen und sicherstellen, dass künftige KI-Funktionen demselben Standard entsprechen.

Hier kommen spezialisierte, KI-fähige Sicherheitstools ins Spiel. Ein generischer Web-Scanner weiß möglicherweise nicht, wie er durch eine Benutzeroberfläche navigieren soll, die Netzwerkaufrufe hinter Aktionen versteckt, oder wie er die in einer GPT-Definition verwendeten OpenAPI-Schemata verstehen soll. Im Gegensatz dazu kann eine KI-gesteuerte Pentest-Plattform wie Penligent diese Schemata und Konfigurationen als erstklassige Eingaben behandeln. Sie können sich einen Arbeitsablauf vorstellen, bei dem Sie die Aktionskonfiguration für eine Reihe von benutzerdefinierten GPTs oder anderen KI-Tools exportieren, sie in eine agentenbasierte Testpipeline einspeisen und sie systematisch auf SSRF-Bedingungen, unsichere Umleitungen, unbegrenzten Netzwerkzugriff und die Offenlegung von Metadaten prüfen lassen.

Penligents Philosophie, Automatisierung mit menschlicher Kontrolle zu kombinieren, passt gut zu diesem Muster. Ein Agent kann alle Tool-Definitionen auflisten, Nutzdaten für Endpunkte generieren, die URLs oder Hostnamen akzeptieren, und skriptgesteuerten Datenverkehr durchführen, der simuliert, was ein neugieriger Angreifer versuchen würde. Sobald das System ein vielversprechendes Verhalten entdeckt - z. B. dass ein scheinbar externer HTTPS-Endpunkt Umleitungen in interne IP-Bereiche folgt - kann es dies als Beweismittel aufzeigen: Anforderungsprotokolle, Antwortschnipsel und abgeleitete interne Topologie. Ein menschlicher Operator kann dann die nächsten Schritte lenken, indem er das System beispielsweise auffordert, speziell auf Cloud-Metadaten-Routen umzuleiten oder zu überprüfen, ob zurückgegebene Token für Management-APIs gültig sind.

Diese Art von Arbeitsablauf erreicht zwei Dinge. Er bringt KI-Plattformen in denselben evidenzbasierten Sicherheitskreislauf ein, den Webanwendungen und APIs bereits genießen, und er nutzt dieselben LLM-Funktionen, die Angreifer unweigerlich nutzen werden, aber im Dienste der Verteidiger. Der Fehler, der ChatGPT getroffen hat, ist dann keine einmalige Überraschung mehr, sondern wird zu einem Testfall in einer Regressionssuite, die Sie bei jeder neuen Integration oder Änderung Ihrer Aktionsinfrastruktur ausführen können.

Praktische Lektionen für Teams, die auf KI-Plattformen aufbauen

Wenn Sie ein Sicherheitsingenieur oder -architekt sind, der KI-Dienste nutzt, anstatt sie zu entwickeln, ist dieser Vorfall immer noch höchst relevant. Selbst wenn Sie intern nie mit benutzerdefinierten GPTs zu tun haben, setzen Sie wahrscheinlich interne APIs, Dashboards oder Dokumentenspeicher für KI-Agenten oder Co-Piloten ein. Die Ideen sind übertragbar.

Der erste Schritt besteht darin, den LLM nicht mehr als das Einzige zu betrachten, das einer Sicherheitsüberprüfung bedarf. Jede Funktion, die Modelle in Ihre Umgebung zurückrufen lässt - ob durch explizite Tools, Aktionen oder indirekte Webhooks - muss als potenzieller Angriffsgraph betrachtet werden. Sie sollten in der Lage sein, mit einiger Sicherheit zu beantworten, mit welchen internen Diensten eine KI-Komponente kommunizieren kann, welche Identitäten sie verwendet und was passiert, wenn ein feindlicher Benutzer absichtlich versucht, diese Fähigkeiten zu erweitern.

Der zweite Schritt besteht darin, Ihre Testprogramme so zu erweitern, dass sie den KI-Glue-Code abdecken. Wenn Sie einen Penetrationstest in Auftrag geben oder eine interne Red-Team-Übung durchführen, stellen Sie sicher, dass der Umfang ausdrücklich KI-Integrationen einschließt: die Konfigurationsoberflächen für Tools, die Art und Weise, wie URLs und Header aufgebaut sind, die Netzwerkpfade zwischen KI-Laufzeiten und sensiblen Diensten sowie die Schutzmaßnahmen für Metadaten-Endpunkte. Fragen Sie nach Beweisen dafür, dass jemand irgendwo versucht hat, diese zu missbrauchen, wie es ein echter Angreifer tun würde.

Der dritte Schritt besteht darin, zu akzeptieren, dass diese Angriffsfläche nicht schrumpfen wird. Da immer mehr Geschäftsprozesse mit LLMs verbunden werden, wird es mehr Aktionen, mehr Plugins und mehr Hintergrunddienste geben, die im Auftrag von Eingabeaufforderungen arbeiten. Sie können die Sicherheit entweder in Form einer Reihe von anlassbezogenen Patches einführen oder ein wiederholbares Programm erstellen: klare Bedrohungsmodelle, grundlegende Architekturmuster, automatisierte Testabläufe und Werkzeuge - möglicherweise mit Hilfe von Systemen wie Penligent -, die Ihre Umgebung ständig überprüfen.

Jenseits der Schlagzeile

Der Custom GPT SSRF-Hack kann leicht als einmalige Peinlichkeit für einen einzelnen Anbieter missverstanden werden. Es ist produktiver, ihn als Vorschau zu betrachten. KI-Plattformen entwickeln sich rasch zu Orchestrierungsebenen, die Benutzer, Modelle, APIs und Cloud-Infrastrukturen miteinander verbinden. Diese Rolle bringt Macht mit sich, und Macht hat immer einen größeren Aktionsradius, wenn etwas schiefgeht.

Das Ermutigende an dieser Geschichte ist, dass sie auch den Weg nach vorne aufzeigt. Die Schwachstelle wurde von einem Forscher gefunden, der alten Instinkten in einem neuen Kontext folgte. Sie wurde über einen Standard-Bug-Bounty-Kanal gemeldet. Sie wurde behoben. Der Rest von uns kann nun das gleiche Schema anwenden und es proaktiv auf unsere eigenen Systeme anwenden, idealerweise mit Hilfe von Tools, die sowohl Sicherheit als auch KI verstehen.

Wenn wir das tun, dann ist das Vermächtnis dieses Vorfalls nicht nur "ChatGPT hatte einmal ein SSRF". Er wird zu einer Fallstudie darüber, wie man über KI-Sicherheit nachdenken sollte: Behandeln Sie Modelle als eine Komponente in einem größeren System, behandeln Sie Integrationen als ernstzunehmende Angriffsflächen und nutzen Sie Automatisierung und menschliche Erkenntnisse - sei es durch Plattformen wie Penligent oder Ihre eigenen internen Pipelines -, um vage Bedenken kontinuierlich in konkrete, testbare, evidenzbasierte Sicherheit zu verwandeln. Das ist die Art von Geschichte, die es wert ist, auf Medium erzählt zu werden, und die es noch mehr wert ist, in Ihrer technischen Organisation gelebt zu werden.