Verschlüsselte Anweisungen umgehen Groks Schutzfilter
Sicherheitsforscher haben einen Angriff auf Grok entwickelt, bei dem verschlüsselte Anweisungen den Abfluss persönlicher Daten auslösen. Betroffen sein können der Name, Standortinformationen und bisherige Chatverläufe eines Nutzers. Zum Zeitpunkt der Veröffentlichung war der Angriff weiterhin reproduzierbar, obwohl xAI bereits im Juni darüber informiert worden war.
Die Methode wird als Cryptographic Context Injection bezeichnet. Dabei versteckt ein Angreifer die schädliche Prompt Injection in einem verschlüsselten Text. Grok erhält auf derselben Webseite sowohl das verschlüsselte Material als auch den Schlüssel und die Anweisung zur Entschlüsselung.
Sobald das Modell die Seite zusammenfassen soll, verarbeitet es den Inhalt in seiner Code-Umgebung. Eine zusätzliche Warnung oder Bestätigung ist dabei nach Angaben der Forscher nicht erforderlich.
So funktioniert der Datendiebstahl
Eine Prompt Injection schleust fremde Anweisungen in Inhalte ein, die ein KI-Modell verarbeitet. Das kann beispielsweise über Webseiten, Dokumente oder E-Mails geschehen. Große Sprachmodelle können solche Inhalte nicht immer zuverlässig von legitimen Anweisungen des Nutzers unterscheiden.
| Schritt | Vorgang | Sicherheitsproblem |
|---|---|---|
| 1 | Eine Webseite enthält verschlüsselten Text, Schlüsselmaterial und eine Anweisung zur Entschlüsselung. | Der Filter erkennt zunächst nur gewöhnlichen Geheimtext. |
| 2 | Grok entschlüsselt den Inhalt mit PBKDF2 und AES-256-GCM in seiner Code-Umgebung. | Die eigentliche Anweisung entsteht erst während der Ausführung. |
| 3 | Die entschlüsselte Anweisung fordert Grok auf, persönliche Daten als vermeintlichen Schlüssel zusammenzustellen. | Das Modell behandelt die Ausgabe des eigenen Werkzeugs als vertrauenswürdigen Kontext. |
| 4 | Die Daten werden als Parameter an eine URL des Angreifers angehängt. | Beim Öffnen der URL landen die Informationen in den Serverprotokollen des Angreifers. |
Die führende Erklärung lautet, dass Groks Sicherheitsfilter zwar ein- und ausgehende Texte prüfen, nicht aber das Ergebnis der eigenen Code-Ausführung. PBKDF2, ein Verfahren zur Schlüsselableitung, und AES-256-GCM als Verschlüsselungsverfahren wirken für einen statischen Klassifikator zunächst unverdächtig. Der Filter führt den Code nicht selbst aus und sieht daher nicht, welche Klartextanweisung dadurch entsteht.
Statische Schutzmechanismen lesen Inhalte nur als Text. Sie führen keinen Code aus und entschlüsseln keine Daten. Genau diese Lücke nutzt der Angriff aus, so die sinngemäß übersetzte Erklärung des Sicherheitsforschers Rony Utevsky.
Werkzeugausgaben werden zur neuen Angriffsfläche
Das Problem reicht über Grok hinaus. Dieselbe Grundtechnik wurde nach Angaben der Forscher auch gegen Gemini eingesetzt. Dort erschien die entschlüsselte Anweisung als vermeintliche Fehlermeldung und brachte das Modell dazu, normalerweise gesperrte Inhalte sowie interne Systemanweisungen auszugeben.
Damit verschiebt sich die Angriffsfläche. Es geht nicht mehr nur um den sichtbaren Prompt, sondern um den gesamten Kontext, den ein Modell während seiner Arbeit erzeugt. Dazu gehören Werkzeugausgaben, Ergebnisse aus Code-Umgebungen, Zwischenschritte und aufgerufene Webseiten.
Ein vergleichbares Grundrisiko zeigte sich bereits bei einem Datenabfluss über Microsoft Copilot. Auch dort konnte versteckter Kontext dazu führen, dass ein KI-Assistent sensible Informationen an einen externen Empfänger übermittelte. Ansätze wie AWS Dogwood gegen falsche Tool-Aufrufe zeigen, dass Anbieter inzwischen verstärkt die Schnittstelle zwischen Modell und Werkzeug absichern müssen.
Was Unternehmen daraus ableiten sollten
Für Unternehmen im DACH-Raum ist besonders relevant, welche Daten ein KI-Assistent gleichzeitig lesen und nach außen übertragen darf. Ein Modell mit Zugriff auf E-Mails, Dateien, Chats und einen Browser besitzt einen erheblich größeren Schadensradius als ein isolierter Textgenerator. Jede zusätzliche Integration erhöht den Prüfaufwand.
Statische Inhaltsfilter des Anbieters reichen als alleinige Kontrolle nicht aus. Sinnvoll sind getrennte Berechtigungen, eine Positivliste erlaubter Zieladressen, gesperrte URL-Parameter für sensible Daten und eine Kontrolle ausgehender Verbindungen. Auch Werkzeugausgaben sollten erneut durch Sicherheitsprüfungen laufen, bevor sie dem Modell als Kontext übergeben werden.
Bei einer möglichen Übertragung personenbezogener Daten sind zudem Protokollierung, Reaktion auf Sicherheitsvorfälle und die Prüfung einer möglichen Datenschutzverletzung erforderlich. Hosted KI-Dienste erschweren diese Bewertung, wenn Filterlogik und Ausführungswege nicht transparent sind.
Self-Hosting beseitigt Prompt Injections nicht automatisch. Es ermöglicht jedoch eigene Netzwerkregeln, nachvollziehbare Protokolle und eine technisch erzwungene Trennung zwischen Modell, internen Daten und externen Zielen. Entscheidend ist nicht allein die Wahl des Modells, sondern die Architektur um das Modell herum.