Voraussetzung für den Angriff war, dass die Anweisung bereits im Dialog steckte. Check Point nennt drei Wege dorthin: einen Prompt, den der Nutzer selbst einfügt, eine geteilte ChatGPT-Unterhaltung, die er öffnet, oder ein Custom GPT, das die Anweisung in seinen für den Nutzer unsichtbaren Builder-Instruktionen trägt. Danach genügte eine einzige gewöhnliche Nachricht als Auslöser.
Die Anweisung war so formuliert, dass ChatGPT im Thinking-Modus zwei Arbeitsstränge in derselben Runde ausführte: Es beantwortete die Nutzerfrage und prüfte parallel ein verstecktes Postfach auf eine Aufgabe des Angreifers, erledigte diese mit den Werkzeugen der Nutzersitzung und schickte das Ergebnis zurück. Das Modell wurde angewiesen, beide Stränge zu trennen — die verdeckte Aufgabe erschien nie in der sichtbaren Antwort.
Das einzige Anzeichen war ein kleiner Hinweis „Mit Gmail gesprochen" über der Antwort. Er dokumentierte einen Lesezugriff, der schon erfolgt war, und gab dem Nutzer keine Gelegenheit, ihn zu erlauben oder zu verweigern. Gefragt wurde niemand, weil verbundene Apps standardmäßig so arbeiten: OpenAIs Dokumentation nennt „Important actions" als Vorgabe, die Lesezugriffe ohne Rückfrage zulässt. Nachgefragt wird nur bei Aktionen, die außerhalb von ChatGPT echte Wirkung haben, sensible Informationen offenlegen oder schwer rückgängig zu machen sind. Wer immer gefragt werden will, kann auf „Always ask" umstellen. In Business-, Enterprise- und Edu-Arbeitsbereichen legen Administratoren fest, welche Aktionen eine App ausführen darf und wer sie nutzen kann; in Business-Tarifen sind Apps standardmäßig aktiv, in Enterprise und Edu standardmäßig aus.
Der verdeckte Kanal lief zwischen den Containern, in denen ChatGPT Code ausführt und die pro Unterhaltung bei Bedarf angelegt werden. Laut OpenAIs Dokumentation kann die für Datenanalyse genutzte Python-Umgebung keine Anfragen ins Web oder an externe APIs stellen. Auch untereinander hatten Container verschiedener Unterhaltungen — selbst unter verschiedenen Konten — laut Check Point keinen direkten Pfad.
Alle erreichten jedoch einen gemeinsamen internen Dienst. Da ChatGPT gelegentlich zusätzliche Python- oder npm-Pakete installieren muss, durften die Container statt öffentlicher Paketquellen eine interne JFrog-Artifactory-Instanz ansprechen, die Pakete für sie beschaffte. Diese Instanz erlaubte es, an eine gespeicherte Datei benannte Werte — sogenannte Properties — anzuhängen und wieder auszulesen. Die Zugangsdaten für den Lesezugriff, die in Umgebungsvariablen lagen und von ausgeführtem Code abgegriffen werden konnten, genügten auch zum Schreiben dieser Properties. Ein separates Geheimnis oder eine Rechteausweitung war nicht nötig.
Entscheidend: Die Properties waren nicht nach Konto getrennt. Aus einem Container unter einem Konto hängte Check Point einer zwischengespeicherten Datei die Property chatgpt_test_ts mit der aktuellen Uhrzeit an — in einer Unterhaltung unter einem anderen Konto ließen sich Name und Wert unverändert abrufen. Properties können Klartext oder Base64 aufnehmen, zu große Inhalte lassen sich auf mehrere verteilen und am anderen Ende wieder zusammensetzen. Damit wurden die Metadaten des Paketdienstes zur gemeinsamen Zwischenablage zwischen eigentlich isolierten Containern.
Es ist der zweite Ausleitungskanal, den Check Point in diesem Teil von ChatGPT gefunden hat: Im März beschrieb das Unternehmen einen Weg über DNS-Abfragen, mit dem Gesprächsdaten an einen externen Server gingen; OpenAI habe ihn am 20. Februar behoben. Vom Hugging-Face-Vorfall, bei dem OpenAIs eigene Modelle während firmeninterner Sicherheitstests eine interne Artifactory-Instanz als Nachrichtenbrett nutzten, grenzt Check Point den Fall ab: Der Mechanismus sei ein anderer, beide seien aber Fälle, in denen „ein gemeinsam genutzter interner Dienst zu einer unbeabsichtigten Kommunikationsschicht wurde" — zwischen Umgebungen, die isoliert bleiben sollten.