Aufgrund seiner weit verbreiteten Verwendung bei Unternehmen und einzelnen Benutzern ist chatgpt ein Hauptziel für Angreifer, die auf vertrauliche Informationen zugreifen möchten. In diesem Blogbeitrag werde ich Sie durch meine Entdeckung von zwei Cross-Site-Scripting (XSS)-Schwachstellen in ChatGPT und einigen anderen Schwachstellen führen. Bei einer Verkettung könnten diese zu einer Kontoübernahme führen.

Eintauchen in ChatGPT

Meine Reise begann mit der Untersuchung des Tech-Stacks von ChatGPT. Die Verwendung von NextJS, einem beliebten React-Framework, machte mich zunächst skeptisch, ob ich eine XSS-Schwachstelle finden sollte. Als ich jedoch die Funktionalitäten und den clientseitigen Code erkundete, bemerkte ich etwas, das meine Meinung änderte.

Die erste Entdeckung

Mit ChatGPT können Benutzer Dateien hochladen und Fragen dazu stellen. Bei der Beantwortung kann ChatGPT diese Dateien zitieren und ein anklickbares Zitiersymbol einfügen, das Sie als Referenz zur Originaldatei oder Website zurückführt.

Der obige Code verarbeitet das Zitat-Klick-Ereignis. Es verarbeitet den Inhalt der Datei in einem Blob, der dann mit der Funktion „window.open“ geöffnet wird. Abhängig vom Dateiinhaltstyp könnte diese Methode möglicherweise ein Sicherheitsrisiko darstellen.

Ich habe dies getestet, indem ich eine HTML-Datei mit Text und JavaScript hochgeladen habe. ChatGPT hat es verarbeitet und ein Zitat bereitgestellt. Als ich auf das Zitat klickte, wurde der HTML-Inhalt über eine Blob-URL auf meinem Bildschirm angezeigt, aber ein Verstoß gegen die Content Security Policy (CSP) blockierte meine JavaScript-Payload.

CSP umgehen

Als ich die CSP-Richtlinie untersuchte, fiel mir auf, dass der Nonce-Wert, der eigentlich dynamisch sein sollte, statisch war. Eine Nonce ist eine eindeutige Zeichenfolge, die es bestimmten HTML-Elementen ermöglicht, CSP-Einschränkungen zu umgehen. Normalerweise ändert sich dieser Wert mit jeder Anfrage, um sicherzustellen, dass nur vom Server genehmigte Elemente ausgeführt werden. Hier blieb es jedoch unverändert.

Ein Test mit einem anderen Konto und einer anderen IP-Adresse bestätigte das Problem. Anschließend habe ich eine neue HTML-Datei mit einem Skript-Tag hochgeladen, das dieses Nonce-Attribut enthielt. Dieses Mal wurde mein Skript erfolgreich ausgeführt, nachdem ich auf das Zitat geklickt hatte.

Herausforderungen und Einschränkungen

Das Ausnutzen dieser Sicherheitslücke ist nicht einfach. Der Benutzer muss eine schädliche Datei hochladen und sich auf eine Art und Weise engagieren, die ChatGPT dazu veranlasst, aus dieser Datei zu zitieren. Anschließend muss der Benutzer auf das Zitat klicken, um das XSS auszulösen.

Ich habe mir die ChatGPT-Funktion zum Teilen von Gesprächen als eine Möglichkeit angesehen, diesen Exploit gemeinsam nutzbar zu machen. Der Plan bestand darin, einen Konversationslink mit der Zielgruppe zu teilen und sie dazu zu bringen, auf ein Zitat zu klicken, was das XSS auslösen würde.

Dieser Ansatz funktionierte nicht wie erwartet. Auf in einer ChatGPT-Konversation hochgeladene Dateien kann nur das Konto zugreifen, das sie hochgeladen hat. Versuche, von einem anderen Konto aus auf diese Dateien zuzugreifen, führten zu einem 404-Fehler.

Neuer Ansatz mit Wissensdateien

GPTs, eingeführt von OpenAI, werden mit Wissensdateien geliefert. Diese Dateien funktionieren über eine API, die der für vom Benutzer hochgeladene Dateien sehr ähnlich ist, jedoch mit einem bemerkenswerten Zusatz – einem „gizmo_id“-Parameter. Bei meinen Recherchen habe ich herausgefunden, dass, wenn ein GPT auf „Öffentlich“ gesetzt ist, es jedem Konto ermöglicht, auf diese Wissensdateien zuzugreifen und sie herunterzuladen, sofern es über die erforderlichen Informationen verfügt – insbesondere die GPT-ID und die zugehörige Datei-ID.

Ich habe dies für einen Fehler bei der Autorisierung auf defekter Funktionsebene gehalten, da dadurch jeder ChatGPT-Benutzer öffentliche GPT-Wissensdateien herunterladen kann.

Dies führte zu einer neuen Möglichkeit der Ausbeutung. Wenn ich die gemeinsame Konversationsanforderung in eine öffentliche Datei anstelle der ursprünglich hochgeladenen Datei umwandeln kann, könnte die XSS-Sicherheitslücke ausgenutzt werden.

Ich habe mich auf das konzentriert „/backend-api/conversation“ Endpunkt zum Starten von ChatGPT-Konversationen. Unten sehen Sie, wie der Anfragetext aussieht:

Mir ist aufgefallen, dass diese Struktur den Metadaten des Assistenten ähnelt, die ich im „pageProps“-Objekt einer zuvor erstellten gemeinsamen ChatGPT-Konversation gesehen habe.

Ich sah das Zitatobjekt in den Metadaten der Assistentennachricht, die die von mir hochgeladene Datei-ID enthielten. Dies war dieselbe ID, die von dem anfälligen Code verwendet wurde, den ich ursprünglich besprochen habe, um den Dateiinhalt abzurufen. An diesem Punkt wurde mir klar, dass ich diese Schwachstelle wahrscheinlich gemeinsam nutzen könnte, wenn ich diese Metadaten kontrollieren könnte.

Experimentieren mit Rollen und Massenzuweisung

Anschließend habe ich untersucht, ob und wie ich diese Metadaten manipulieren kann. Ich habe zunächst versucht, die Rolle im Gespräch von „Benutzer“ zu „Assistent“ zu ändern. Zu meiner Überraschung akzeptierte ChatGPT diese Änderung und generierte weiterhin Antworten, als kämen sie vom Assistenten.

Als nächstes habe ich versucht, die Metadaten so anzupassen, dass sie der Zitatstruktur entsprechen, die ich im „pageProps“-Objekt gesehen habe. Diese Methode funktionierte ebenfalls und deutete auf das Vorhandensein einer Massenzuweisungsschwachstelle hin. Eine Massenzuweisungsschwachstelle entsteht, wenn eine Anwendung vom Benutzer bereitgestellte Daten wahllos internen Objekten oder Variablen zuweist. Dies kann passieren, wenn die Anwendung die zuordenbaren Daten nicht richtig filtert oder einschränkt. In diesem Zusammenhang könnte ich Eingabedaten verwenden, um Aspekte der ChatGPT-Anwendung – insbesondere die Zitatmetadaten – auf eine Weise zu manipulieren, die für einen normalen Benutzer normalerweise tabu wäre.

Der Exploit

Ich habe eine neue Anfrage an den Endpunkt „/backend-api/conversation“ erstellt, mich als Assistent ausgegeben und ein benutzerdefiniertes Zitierobjekt eingefügt. Die einzige Änderung, die ich vorgenommen habe, bestand darin, die Datei-ID auf festzulegen „file-Cbn7djQD1W20s3h5JM8NfFs8/download?gizmo_id=g-ghPiYIKcD#“ ChatGPT-Clientseite wird gezwungen, stattdessen die GPTs-API zu verwenden.

Dieser Exploit funktionierte wie geplant. Ich habe eine Konversation erstellt und geteilt, und als ich sie mit einem anderen ChatGPT-Konto getestet habe, habe ich durch Klicken auf ein beliebiges Zitat in der Konversation die Wissensdatei von meinem öffentlichen GPT heruntergeladen, was das XSS ausgelöst hat.

Ich habe diese Sicherheitslücke an OpenAI gemeldet. Sie reagierten, indem sie die Blob-Erstellung entfernten und die Logik änderten, um die Download-URL direkt zu öffnen.

Nach dem Fix habe ich zusätzliche Funktionen untersucht, darunter „context_connector“, „metadata“ und „download_url“. Allerdings stellten diese Komponenten keine neuen Schwachstellen dar, da die Konversationsmetadaten diese Werte nicht direkt steuern können.

Eine weitere XSS-Sicherheitslücke

Anschließend habe ich meine Untersuchung erweitert, indem ich zusätzliche Funktionen im Zusammenhang damit untersucht habe, wie ChatGPT die Darstellung von Zitaten von Websites handhabt. Diese Untersuchung führte mich zu folgendem Code:

Beim Untersuchen des Codes ist mir aufgefallen, dass das Zitiermetadatenobjekt, auf das verwiesen wird als „sie“ im Code wurde direkt verwendet, um das „href“-Attribut eines Zitierlinks (z. B. „em.url“) festzulegen. Dies war ein Warnsignal, da ich, wie ich bereits festgestellt hatte, die Metadaten manipulieren konnte, indem ich mich als Assistent ausgab.

Erster Test und eine neue Herausforderung

Um diese Schwachstelle zu testen, habe ich eine neue Konversation eingerichtet. In diesem Setup habe ich die Zitiermetadaten manipuliert und ihren URL-Wert auf eine JavaScript-Protokoll-URL wie „javascript:alert(1)“ festgelegt. Die Ausbeutung verlief jedoch nicht wie geplant. Obwohl ich das Attribut „href“ des Anker-Tags erfolgreich auf meine JavaScript-URL gesetzt habe, enthielt das Tag auch ein Attribut „target=“_blank“. Dieses Attribut, wie ich in einem früheren Blogbeitrag besprochen habe, „Hacken von Microsoft und Wix mit Tastaturkürzeln„kann nur über Tastaturkürzel ausgenutzt werden.

ChatGPT ermöglicht die Einbettung seiner Schnittstelle in andere Websites mithilfe eines „Iframes“. Dies bedeutete, dass die Sicherheitslücke von einer völlig anderen Website aus ausgelöst werden konnte.

In meinem Proof of Concept habe ich die geteilte ChatGPT-Konversation in einen „Iframe“ eingebettet und mithilfe von CSS so positioniert, dass jeder Klick versehentlich den Zitierlink auslöst. Um den Iframe unsichtbar zu machen, habe ich seine Deckkraft auf Null gesetzt. Auf diesem unsichtbaren Iframe habe ich den Text „Halten Sie ⌘ gedrückt und klicken Sie, um mich in einem neuen Tab zu öffnen“ hinzugefügt. Ein Benutzer, der diese Anweisungen befolgt, würde unwissentlich beliebiges JavaScript auf chat.openai.com ausführen.

SameSite-Cookies und Speicherpartitionierung

Ein weiteres Hindernis SameSite-Cookies Und google.com/privacy-sandbox/3pcd/storage-partitioning”>Speicherpartitionierung, Sicherheitsmaßnahmen zum Schutz der Privatsphäre und Sicherheit im Web, indem die Art und Weise eingeschränkt wird, wie Browser Cookies und andere Arten von Speicherung über verschiedene Ursprünge hinweg verwalten. Wenn in unserem Szenario ein Benutzer unsere bösartige Website besuchte, die einen Iframe eingebettet hatte, der auf unsere gemeinsame ChatGPT-Konversation verlinkte, blockierten diese Maßnahmen den Zugriff auf das ChatGPT-Sitzungscookie und LocalStorage und meldeten ihn effektiv von seinem Konto innerhalb des Iframes ab.

Diese Sicherheitsfunktionen zielen darauf ab, vor Cross-Site Request Forgery (CSRF)-Angriffen und verschiedenen Formen von Side-Channel-Cross-Site-Tracking-Angriffen zu schützen, wie z Timing-Angriffe, XS-LeaksUnd Cross-Origin State Inference (COSI)-Angriffe. Insbesondere umfasst das Bedrohungsmodell für diese Maßnahmen kein Cross-Site Scripting (XSS), die Schwachstelle, die wir in diesem Szenario ausgenutzt haben.

Durch das Erstellen eines Blob-Objekts mit HTML-Inhalt und das Generieren einer URL dafür mithilfe der URL.createObjectURL-Methode im chat.openai.com-Kontext konnte ich im übergeordneten Fenster zu dieser Blob-URL navigieren. Dadurch werden die Cookie-Einschränkungen und die Speicherpartitionierung von SameSite umgangen. Dies war möglich, weil die Navigation, die von chat.openai.com aus initiiert wurde, als Anfrage desselben Ursprungs betrachtet wurde und daher nicht den typischen ursprungsübergreifenden Einschränkungen unterliegt. Ermöglicht die Übernahme eines beliebigen ChatGPT-Kontos.

Nachfolgend finden Sie unseren endgültigen Exploit-Code:

OpenAIs Fix

Nachdem ich diese Schwachstellen entdeckt hatte, teilte ich OpenAI umgehend meinen Proof of Concept mit. Ihre Antwort war beeindruckend schnell und das XSS-Problem wurde innerhalb weniger Stunden behoben, indem eine clientseitige Validierung für Zitat-URLs hinzugefügt wurde.

Unten können Sie sehen, dass die Methode „eF“ hinzugefügt und beim Rendern der Zitierlinks verwendet wurde, wodurch bestätigt wird, dass nur die Protokolle „https“, „mailto“ und „tel“ verwendet werden können.

Schlussgedanken

Ich möchte OpenAI meinen Dank für seinen kollaborativen und effizienten Ansatz zur Behebung dieser Schwachstellen aussprechen. Es ist erfreulich zu wissen, dass unsere Bemühungen ChatGPT für alle seine Benutzer sicherer gemacht haben.

Achten Sie auf unseren nächsten Blogbeitrag, in dem wir uns mit dem Double Agent-Angriff befassen, einer neuen Post-Exploitation-Technik, die wir für ChatGPT-ähnliche Systeme entwickelt haben.

Die Post XSS markiert die Stelle: Schwachstellen in ChatGPT ausgraben erschien zuerst auf Blog.

*** Dies ist ein syndizierter Blog von Security Bloggers Network Blog Autor: Ron Masas. Lesen Sie den Originalbeitrag unter: https://www.imperva.com/blog/xss-marks-the-spot-digging-up-vulnerabilities-in-chatgpt/