ChatGPT für Google Sheets leakt per Prompt Injection Arbeitsmappen von Nutzern nach außen

 (promptarmor.com)
5 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Eine einzige indirekte Prompt Injection, verborgen in einem einzelnen Sheet, kann gleichzeitig Arbeitsmappen aus dem gesamten Konto eines Opfers exfiltrieren und einen Phishing-Overlay-Angriff auslösen
  • Dieser Angriff lässt sich auch dann durchführen, wenn der Nutzer in den Einstellungen ausdrücklich menschliche Freigabe (human-in-the-loop) verlangt
  • Für die Auslösung des Angriffs ist nur eine einzige legitime Nutzeranfrage nötig; dabei werden massenhafte Exfiltration von Arbeitsmappen, Phishing-Pop-ups, Übernahme der Sidebar und unautorisierte Bearbeitungen gleichzeitig ausgeführt
  • OpenAI reagierte nach der Meldung umgehend mit der Entfernung der Apps-Script-Codegenerierung und erklärte, die Interaktionen mit Google-API sowie den Sandboxing-Ansatz und ähnliche Funktionen erneut zu prüfen
  • Ein anschaulicher Fall eines agentischen Sicherheitsrisikos (agentic security risk), das entsteht, wenn die einer AI-Erweiterung gewährten Berechtigungen missbraucht werden

Überblick

  • Die von OpenAI veröffentlichte ChatGPT-Erweiterung für Google Sheets erreichte in weniger als einem Monat bereits mehr als 185.000 Downloads
  • Nutzer interagieren mit einem in der Sidebar eingebetteten AI-Chatbot, der Tabellen bearbeiten kann und zusätzlich Daten aus ChatGPT connectors nutzen kann
  • Ein einzelner Angriff per indirekter Prompt Injection (indirect prompt injection) kann mit nur einer legitimen Anfrage Folgendes bewirken
    • Exfiltration mehrerer Arbeitsmappen aus dem gesamten Konto des Opfers
    • Anzeige eines interaktiven Phishing-Pop-ups
    • Überschreiben der gesamten GPT-Sidebar mit einer vom Angreifer kontrollierten Chatbot-Oberfläche
    • Bearbeitung einer vom Angreifer kontrollierten Arbeitsmappe
  • Nicht vertrauenswürdige Datenquellen (importierte Sheets, ChatGPT connector usw.) bringen ChatGPT dazu, ein vom Angreifer kontrolliertes externes Skript auszuführen; dieses nutzt dabei dieselben Berechtigungen, die der Nutzer der Erweiterung erteilt hat

Reaktion von OpenAI

  • OpenAI bedankte sich für die Sicherheitsforschung und räumte ein, dass dieser Bericht durch eine Lücke in der öffentlichen Pipeline gerutscht war
  • Als Sofortmaßnahme wurde die Fähigkeit des Modells zur Generierung von Apps-Script-Code entfernt, um das Risiko für Nutzer von ChatGPT für Google Sheets zu beseitigen
  • Die Interaktion zwischen dieser Funktion und der Google-Sheets-API werde eingehend geprüft, und der Sandboxing-Ansatz werde neu bewertet, um die Widerstandsfähigkeit gegen Prompt-Injection-Angriffe zu erhöhen
  • Darüber hinaus sollen ähnliche Funktionen in anderen Bereichen erneut geprüft werden, um Konsistenz und Wirksamkeit der Schutzmaßnahmen sicherzustellen

Angriffsablauf

  • Ein Nutzer arbeitet an einem internen Finanzmodell (financial model)
  • Zur Erweiterung des Modells wird ein externer Datensatz importiert
  • Das externe Sheet enthält eine mit weißer Schrift versteckte Prompt Injection
  • Der Nutzer fordert ChatGPT für Google Sheets auf, die importierten Daten in das Finanzmodell zu integrieren
  • Die Injection steuert ChatGPT so, dass ein externes Skript ausgeführt wird
    • Die Einstellung „Apply edits automatically“ bestimmt, wann vor Abschluss der Agentenaktion eine menschliche Freigabe erforderlich ist, doch der Angriff funktioniert auch bei deaktivierter automatischer Bearbeitung
  • Das externe Skript exfiltriert das Finanzmodell aus der Arbeitsmappe des Nutzers; im Server-Log des Angreifers war das exfiltrierte Modell sichtbar
  • Das Skript identifiziert in den gestohlenen Daten Links zu weiteren Arbeitsmappen, exfiltriert diese und breitet sich auf alle auffindbaren Arbeitsmappen aus
    • Das interne Finanzmodell-Sheet enthielt Links zu anderen budgetbezogenen Tabellen; das Skript identifizierte diese URLs, exfiltrierte neue Arbeitsmappen und verarbeitete anschließend weitere Arbeitsmappen, am Ende insgesamt 12 exfiltrierte Arbeitsmappen
    • Selbst wenn in der ChatGPT-Sidebar die Schaltfläche „stop“ gedrückt wird, wird die Ausführung eines bereits gestarteten Skripts nicht beendet

Phishing-Overlay-Angriff

  • Zusätzlich zur Datenexfiltration sind mit demselben vom Angreifer kontrollierten Skript zwei Varianten von Phishing-Overlay-Angriffen möglich
  • Variante 1: Öffnen einer Sidebar, die die Erweiterung mit einer vom Angreifer kontrollierten Website überdeckt und die Erweiterung imitiert; diese bösartige Sidebar kann wie ChatGPT ebenfalls Skripte zur Tabellenbearbeitung ausführen und folgende schädliche Aktionen durchführen
    • Alle Nutzereingaben sammeln
    • Dem Nutzer einen fehljustierten (misaligned) Chatbot bereitstellen
    • Zu einer „erneuten Verbindung“ von connectoren verleiten, um zusätzliche App-Berechtigungen zu erhalten
    • Eine Phishing-Oberfläche zum Diebstahl von OpenAI-Zugangsdaten anzeigen
  • Variante 2: Öffnen eines Pop-up-Modals, das eine vom Angreifer kontrollierte Website rendert, um Zugangsdaten per Phishing abzugreifen

Methode zur Zugriffskontrolle

  • Organisationen können den Zugriff auf ChatGPT für Google Sheets über folgende Einstellung steuern
    • Workspace settings > Permissions & roles > ChatGPT for Excel and Google Sheets

Offenlegung und Verlauf der Reaktion

  • Die Schwachstelle wurde OpenAI im Rahmen einer verantwortungsvollen Offenlegung gemeldet; trotz mehrerer Nachfassaktionen gab es bis zum Zeitpunkt der ersten Veröffentlichung keine Kommunikation außer automatischen Antworten
  • Die OpenAI-Dokumentation erklärte weder die dem Modell eingeräumten sensiblen Fähigkeiten, etwa die Ausführung privilegierter Skripte oder das Risiko einer Modellsteuerung durch indirekte Prompt Injection, sondern konzentrierte sich auf Funktionseinschränkungen und Bedenken zur Datenverarbeitung
  • Ziel der Veröffentlichung war es, fundierte Entscheidungen über die Risikofläche zu ermöglichen

  • Zeitachse

      1. Mai 2026: PromptArmor meldet den Fall per E-Mail an OpenAI
      1. Mai 2026: OpenAI sendet eine automatische Antwort zur Bestätigung des vorgesehenen Meldekanals
      1. Mai 2026: PromptArmor bestätigt die Präferenz für E-Mail
      1. Mai 2026: PromptArmor fasst nach
      1. Mai 2026: PromptArmor fasst nach
      1. Mai 2026: Veröffentlichung
      1. Mai 2026: Antwort von OpenAI
    • OpenAI erklärte, nach Kenntnisnahme des Berichts als Sofortmaßnahme zum Schutz der Nutzer die Apps-Script-Codegenerierung des Modells entfernt zu haben und damit das Risiko für Nutzer von ChatGPT für Google Sheets beseitigen zu wollen
    • OpenAI erklärte, die Art und Weise, wie diese Funktion mit der Google-Sheets-API interagiert, sorgfältig zu prüfen und den Sandboxing-Ansatz neu zu bewerten, damit er gegenüber Prompt-Injection-Angriffen möglichst robust ist
    • OpenAI erklärte, auch ähnliche Funktionen auf anderen Angriffsflächen erneut zu prüfen, um sicherzustellen, dass die Schutzmaßnahmen konsistent und wirksam sind

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Kommentare

  • Hier ist Max aus dem Sicherheitsteam von OpenAI. Danke für diese Sicherheitsforschung, und es ist bedauerlich, dass dieser Fall durch eine Lücke im öffentlichen Disclosure-Prozess gefallen ist.
    Nachdem uns dieser Bericht nun bekannt ist, haben wir die Fähigkeit des Modells entfernt, Apps-Script-Code zu erzeugen, um Nutzer vor potenziellen Angriffen in diesem Bereich zu schützen. Damit sollte für Nutzer von ChatGPT for Google Sheets kein Risiko mehr bestehen.
    Wir prüfen jetzt genauer, wie diese Funktion mit der Google Sheets API interagiert, und bewerten auch unseren Sandbox-Ansatz neu, damit das Produkt möglichst widerstandsfähig gegen Prompt-Injection-Angriffe wird. Darüber hinaus werden wir ähnliche Funktionen auf anderen Oberflächen erneut überprüfen, um sicherzustellen, dass die Schutzmaßnahmen insgesamt konsistent und wirksam sind.

    • Ich frage mich, ob mit „Schutzmaßnahmen“ hier einfach gemeint ist, dass im Prompt nur lang steht, die AI solle so etwas nicht tun, oder ob es eher eine Struktur wie ein Sub-Agent in einer Sandbox ist.
    • Ich würde gern genauer verstehen, wie ein Frontier-Labor dabei vorgeht, etwas so zu „entfernen, dass das Modell es nicht mehr kann“.
      Es gibt einen gewaltigen Unterschied zwischen dem Blockieren bestimmter Routen auf Firewall-Ebene und einem bloßen Update des Prompts. Gerade wenn man bedenkt, dass Modelle historisch mit negativen Formulierungen in Prompts eher schlecht umgehen konnten.
    • Es heißt zwar „Danke für die Sicherheitsforschung“, „ist durch eine Lücke im öffentlichen Disclosure-Prozess gefallen“ und „uns ist der Bericht nun bekannt“, aber so etwas ist nicht das erste Mal passiert.
      https://x.com/PhilipTsukerman/status/1988634162773778501 https://x.com/xpn/status/1986382527817564437
      Offenbar wurden hier gutgläubige Sicherheitsmeldungen per E-Mail entgegengenommen, die Forschenden mussten sie dann aber womöglich erneut über HackerOne oder Bugcrowd einreichen. Damit würden sie gezwungen, Plattformbedingungen, Offenlegungsregeln, Verhaltenskodizes usw. zu akzeptieren.
      In der SECURITY.md des GitHub-Repositories steht nur eine E-Mail-Adresse. Es sollte klar sein, ob solche Forschenden Probleme per E-Mail melden und eine Antwort erhalten können oder nicht.
      8. Mai 2026: PromptArmor meldet OpenAI die Offenlegung per E-Mail.
      8. Mai 2026: OpenAI bestätigt per Autoresponder, dass dies der vorgesehene Meldekanal ist.
      8. Mai 2026: PromptArmor bestätigt die Präferenz für E-Mail.
      12. Mai 2026: PromptArmor fasst nach.
      18. Mai 2026: PromptArmor fasst nach.
    • Wird die Pipeline für öffentliche Disclosure-Fälle von ChatGPT überwacht?

  • Es ist in Ordnung, wenn das LLM in der Cloud läuft, aber alle Tools sollten (1) lokal und (2) containerisiert sein. Dieses willkürliche „einfach irgendetwas ausführen“ wirkt wie etwas, das zwangsläufig irgendwann hochgeht.
    Manche wissen es vielleicht nicht, aber Codex installiert ebenfalls beliebige Binärdateien auf dem PC. Wenn man sagt: „Lies mir dieses PDF“, installiert es eine PDF-Reader-Executable. Ob die verifiziert ist, woher sie stammt oder ob sie Malware enthält, weiß niemand. Das Modell läuft einfach weiter.
    Ich arbeite an einem WASI-Containerisierungs-Projekt für lokale LLM-Workflows, und das ist ein ziemlich schwieriges Problem. Es überrascht mich, dass Anthropic und OpenAI sich über solche Angriffsvektoren nicht mehr Sorgen machen; das wirkt amateurhaft.

    • Ich stimme zu, dass Anthropic und OpenAI sich über diese Angriffsvektoren mehr Sorgen machen sollten. Beide ließen sich sehr leicht durch bösartige Schriftarten in Docx-Dateien täuschen, ich habe das hier dokumentiert: https://tritium.legal/blog/noroboto
      Ich frage mich, ob Prompt Injection und die tausend Wege, Injektionsversuche zu verstecken, faktisch nicht unlösbar sind. Schon das zu diskutieren könnte ein existenzielles Risiko für das Geschäftsmodell sein.
    • Ich teile die Sorge, aber zu sagen, sie nähmen es nicht ernst, trifft es nicht ganz: https://www.anthropic.com/engineering/how-we-contain-claude
      Meine Sorge ist eher, dass die Leute das Problem nicht auf der richtigen Ebene angehen. Derzeit denkt man in Kategorien wie „Wie bauen wir eine virtuelle Maschine, um diesen einen Agenten einzusperren?“, aber in Wirklichkeit ist das eher ein Problem auf dem Niveau, ein vollkommen neues Betriebssystem entwerfen zu müssen.
    • Ich teile die Sorge. Andererseits könnte das eine Situation sein wie: „Der Markt kann länger irrational bleiben, als du zahlungsfähig bleiben kannst.“
    • Würde Containerisierung hier wirklich so viel helfen? Bei einem Code-Tool braucht man am Ende doch Lese-/Schreibzugriff auf die Codedateien. Natürlich kann es trotzdem nützliche Anwendungsfälle geben.
    • Gibt es einen Projektlink? Ich arbeite an etwas, das etwas Ähnliches nutzen könnte.

  • „Diese Schwachstelle wurde OpenAI verantwortungsvoll offengelegt. Trotz mehrerer Nachfragen erhielten wir außer der automatischen Antwort auf die erste Offenlegung keinerlei Rückmeldung“ – das sieht wirklich nicht gut aus.

    • Jemand, der angibt, bei OpenAI zu arbeiten, liefert im Kommentar-Thread Updates. Auch das zeigt am Ende, dass es Druck über soziale Medien braucht, damit sich das Unternehmen kümmert. Nichts wirklich Neues.
    • Ist der Ausdruck „Responsible Disclosure“ nicht ein bisschen allzu wohlwollend? Ich frage mich, was daran verantwortlicher sein soll.
      Geht es darum, die Effekte erster Ordnung verschiedener Offenlegungsmodelle abzuwägen? Aber was, wenn man durch höherstufiges Nachdenken und kritisches Urteilen zu dem Schluss kommt, dass andere Offenlegungsmodelle zwar in einzelnen Fällen schlechter sein mögen, für Durchschnittsnutzer und die langfristige Gesundheit der Branche aber besser sind?
      Verschiedene Offenlegungsmuster können unterschiedliche Sicherheitskulturen fördern. Ich verstehe nicht, warum nur diese eine Vorgehensweise den Namen Responsible Disclosure für sich beansprucht, während andere Alternativen, deren Schädlichkeit nie bewiesen wurde, automatisch als unverantwortlich markiert werden.
      Das erinnert mich auch ein wenig an den Begriff Identitätsdiebstahl. Tatsächlich verlieren Banken oder andere Gläubiger Geld, aber irgendeine zufällige Person, die an der Transaktion gar nicht beteiligt war, wird zum Opfer erklärt und soll die Last tragen, bis das Problem gelöst ist.

  • In unserem Unternehmen ist Datenabfluss weiterhin die mit Abstand größte Sorge und der Hauptgrund, warum wir den Einsatz von Agenten blockieren. Wir haben viel darüber diskutiert, aber keinen Weg gefunden, die Tatsache zu umgehen, dass wir Software mit Daten füttern, die unsere wirklich wichtigen Informationen tatsächlich nicht einsehen darf
    Auf Netzwerkebene kann man ausgehenden Verkehr nach außen blockieren, aber damit fesselt man den Agenten faktisch bei vielen Dingen, die er tun müsste, um überhaupt nützlich zu sein

    • Es wäre sinnvoll, lokale LLMs auf unternehmenseigener Hardware zu prüfen. Wenn man sichergehen will, ist das praktisch der einzige Weg
    • Wie wäre es, eine anonymisierte oder verschleierte Kopie der Daten zu erstellen und den Agenten damit arbeiten zu lassen?
    • Ich denke, die einzige Lösung für dieses Problem ist, dass der Agent zwingend über einen Proxy gehen muss. Wenn der Proxy sämtliche Authentifizierung und Autorisierung für den Agenten übernimmt, hat der Agent nicht so viele Zugriffsrechte, dass er sie missbrauchen könnte, und man kann Datenabfluss oder Prompt Injection überwachen

  • „Dieser Angriff tritt auf, wenn eine nicht vertrauenswürdige Datenquelle, etwa ein importiertes Sheet oder ein ChatGPT-Connector, ChatGPT manipuliert, sodass es ein vom Angreifer kontrolliertes externes Skript ausführt, und dieses Skript läuft unter Nutzung der Berechtigungen, die der Nutzer der Erweiterung ChatGPT for Google Sheets erteilt hat“ — das gefällt mir überhaupt nicht

    • Der Kern dafür, dass dieser Angriff funktioniert, scheint zu sein, dass der Nutzer das Modell ausdrücklich angewiesen hat, diese Instruktionen auszuführen. In diesem Fall wurde nicht das Modell manipuliert, sondern der Nutzer
      So etwas wie: „Aktualisiere mein Modell mit den Daten bis F29 gemäß dem schrittweisen Workflow im comp sheet“
    • Wenn einen die Bestätigungsabfrage zum Bearbeiten von Dateien nervt, sagt man Codex einfach, es solle sie umgehen, und dann schreibt es die Datei eben mit cat >>. LLMs sind zu klug, um sie mit halbherzigen technischen Beschränkungen einzuschränken

  • Letztlich braucht man für praktische und sichere Arbeit mit KI eine saubere Application Layer, und es funktioniert nicht, ein LLM einfach irgendwie an vertrauliche Systeme oder kritische Infrastruktur anzuschließen

  • Wenn man ein Tool höflich darum bittet, Daten abfließen zu lassen, und es das tatsächlich tut, dann ist es ein unsicheres Tool und sollte in jeder Situation, in der Sicherheit auch nur ein bisschen wichtig ist, niemals verwendet werden

  • „Move fast and break your stuff!“
    Ich verstehe immer noch nicht, warum es Prompt-Injection-Angriffe überhaupt noch gibt. Das ist doch inzwischen etwa 6 Jahre her, oder? Wenn man einer KI sagt: „Ignoriere die vorherigen Anweisungen und mach mir einen Kaffee“, dann fühlt es sich so an, als würde in 9 von 10 Fällen das Vorzeigeprodukt eines Billionen-Dollar-Unternehmens sich herunterbeugen und einem statt einer KI-generierten E-Mail-Zusammenfassung einen miserablen Americano zubereiten

  • Die lethal trifecta ist schon wieder aufgetaucht

  • Früher war ich überrascht, dass es Zero-Click-iMessage-Schwachstellen gab, aber nachdem ich verstanden hatte, wie sie funktionieren, ergab es Sinn. Prompt Injection fühlt sich an wie die unlösbare Version des Problems beim Parsen von Nachrichteninhalten