KI-gesteuerte Chatbots können als Einfallstor für Phishing und Datendiebstahl fungieren. Dahinter stehen aber klassische Angriffsmuster, sagt Cybersecurity-Experte Udo Schneider.
Herr Schneider, der Kunden-Chatbot des Computeranbieters Lenovo wurde dazu gebracht, vertrauliche Daten herauszurücken. Können KI-Chatbots sich zu Komplizen von Angreifern mausern?Die kurzen Antworten: Ja, wer den KI-Chatbot einer Website nutzt, kann geschädigt werden. Und Händler, die KI-Chatbots einsetzen, ebenfalls. Aber liegt das an der KI? In den meisten Fällen nicht.
Warum?
Im Fall von Lenovo wurde offenbar sogenanntes Cross-Site-Scripting genutzt. Vereinfacht gesagt: Ein Bot wird dazu gebracht, nicht nur bloßen Text auszugeben, sondern ein Stück Programm in der Sprache Javascript. Das wird dann im Browser ausgeführt und kann Schaden anrichten. Das gibt es aber schon seit 15 oder 20 Jahren. Es ist zum Beispiel ein altes Problem, dass Forumsbeiträge Javascript übertragen können.
Welcher Schaden kann denn entstehen?
Wenn die Sandbox, also der Sicherheitsmechanismus des Browsers, funktioniert, kann das Javascript-Programm nur Daten aus der aktuellen Sitzung stehlen und an die Angreifer weiterleiten. Das sind vor allem Session-Cookies und die darin enthaltenen Anmelde-Informationen der Chatbot-Nutzer. Das erlaubt es Angreifern, sich als Sie auszugeben. Möglich ist aber auch, dass die Sandbox überwunden wird. Dann kann das Javascript beliebige Programme starten, und die Angreifer können den Rechner der Nutzer praktisch übernehmen. Das ist nicht KI-spezifisch, aber ein KI-Chatbot kann das Vehikel sein.
Was lässt sich dagegen tun?
Die Chatbot-Betreiber müssen dafür sorgen, dass Informationen nicht eins zu eins ausgegeben werden, sondern durch einen Filter laufen. Ein Benutzer würde dann die Javascript-Passagen als Text sehen, aber sie würden nicht ausgeführt.
Trotzdem haben KI-Chatbots Zugriff auf interne Daten, die sie ausgeben können.
Ja, das ist aber ein anderer Fall, da geht es nicht um den Diebstahl von Session-Cookies. Jede Information, auf die ein Chatbot Zugriff hat, kann er prinzipiell auch ausgeben. Auch interne Daten, zum Beispiel wenn er damit trainiert wurde. Unternehmen müssen sehr genau aufpassen, worauf der Bot Zugriff bekommt. Im schlimmsten Fall wirft er Admin-Passwörter aus, wenn er danach gefragt wird. Das kann bei einer Fehlkonfiguration durchaus passieren.
Für Support-Chatbots sind interne Daten Teil ihrer Arbeit.
Wenn Chatbots mit Support- Tickets arbeiten müssen oder Aktionen ausführen sollen, zum Beispiel Buchungen oder Stornierungen, bedeutet das einen Zugriff auf bestimmte Bereiche des Backends, ja. Da gibt es die Möglichkeit, dem Sprachmodell über sogenannte Guardrails im Systemprompt bestimmte Zugriffe zu untersagen. Noch besser ist es, erst gar keinen schreibenden Zugriff zu erlauben. Wenn doch, ist es für Angreifer im Extremfall möglich, die ganze Datenbank zu löschen. Da müssten dann aus meiner Sicht aber schon mehrere Dinge schieflaufen.
Das funktioniert über die Eingaben, die Prompts?
Ja. Chatbot-Betreiber sollten nicht davon ausgehen, dass der Bot alle Guardrails immer zu 100 Prozent einhält. Zum Beispiel werden Sprachmodelle oft mit wissenschaftlichen Texten trainiert und „vertrauen“ Anfragen im wissenschaftlichen Duktus stärker. Das heißt: Allein schon, wenn ich meine Prompts entsprechend formuliere, erhöhe ich meine Chancen, den Bot zu verführen. Und wenn ich ihn ausführlich bitte, mir die Relativitätstheorie zu erklären, und anschließend nach dem Schlafverhalten von Katzen frage – dann führt dieser Absturz ins Irrelevante dazu, dass die Schutzmechanismen des Sprachmodells stark einbrechen. Auch das kann die Chance erhöhen, an den Guardrails vorbeizukommen. Viele unterschätzen, was heute im Prompt-Engineering möglich ist.
Sie meinen eine Art von DDoS-, also Überlastungsangriffen?
Zum Beispiel. Aber: Wenn 10.000 Anfragen pro Stunde kommen – ist das dann ein KI-Problem? Oder ein Problem, das alle Webserver zu Alarm-Meldungen veranlassen sollte? Wie auch immer, es braucht Schutz gegen solchen Missbrauch, und den gibt es ja auch.
Ausgabefilter, eingeschränkte Zugriffsrechte, Read-only-Modi, Guardrails und Alarmsysteme, die ungewöhnliche Zugriffe melden und abwehren – wenn ich Sie richtig verstehe, sind das genügend Mechanismen, um KI-Chatbots zu schützen.
Ja. Aber Sprachmodelle mit KI sind gerade der große Hype. Und das führt zu Marktdruck und dazu, dass Dinge schnell zusammengebaut werden und auf den ersten Blick auch funktionieren. Man merkt erst im Nachhinein, was man da eigentlich geschaffen hat. Und auch, wenn ich mich wiederhole: Das ist keine Eigenart von KI, sondern eine klassische Frage sorgfältiger IT-Entwicklung.
Sie sagen, es bleibt ein kleines Risiko, dass ein KI-Chatbot die Guardrails missachtet. Gibt es nicht immer ein Restrisiko?
Gegenfrage: Schließen Sie Ihre Haustür ab, wenn Sie zur Arbeit fahren?
Ja.
Eben. Das ist das Gleiche. Sie könnten ja auch sagen, das Einbruchsrisiko ist so gering, ich muss nicht abschließen. Es haben. Es sind aber diese Kleinigkeiten, die in der – aus meiner Sicht – oft überhasteten Einführung von KI-Technologie nicht umgesetzt werden. Und das ist nicht mal ein Vorwurf. Kann ich von einem Unternehmen, das kein eigenes KI-Wissen hat, erwarten, dass sie sofort verstehen, wie so eine Prompt Injection funktioniert? Und dass sie nach dem aktuellen Stand der Forschung programmieren? Nein, kann ich nicht.
Und nun?
Es gibt ja andere Schutzmechanismen. Wenn der Chatbot nur einen Read-only-Zugriff hat, ein Angreifer es aber schafft, statt eines Datenbank-SQL-Select- Statements einen Löschbefehl an die Datenbank weiterzugeben, dann hat der Angreifer die erste Hürde überwunden. Aber dann muss die Datenbank sagen, du darfst nicht rein. Und diesen Block kann man von IT-Entwicklern schon erwarten.
Und ein Cache?
Ein Zwischenspeicher, der jeden Tag oder jede Stunde mit Echtdaten aktualisiert wird und als Basis für den Chatbot dient, ist ein guter Schutzmechanismus. Er hängt halt immer ein bisschen hinterher. Viele Unternehmen wollen das nicht und gehen dann doch aufs Live-System.
Warum sollte überhaupt löschen wollen?
Vandalismus gibt es immer. Das kann auch als Drohung für eine Erpressung genutzt werden: Wenn du nicht möchtest, dass das noch mal passiert, bitte hier Geld einwerfen.
Wäre nicht eine Verschlüsselung ein stärkerer Angriff?
Der Unterschied zwischen einem Kommando an den Chatbot, das bestimmte Daten anfordert, und dem Kommando zur Löschung der Datenbank ist sehr gering. Das könnte ich also relativ einfach hinbekommen, ohne das System von innen zu kennen. Für die Verschlüsselung aber gibt es kein simples Kommando, dazu braucht man genaue Kenntnisse der Datenbankstruktur.
Wir fassen zusammen: Wenn ich sehr sauber nach herkömmlichen Good Practices für die Software-Erstellung arbeite, bin ich mit meinem KI-Chatbot auf der sicheren Seite.
Wenn ich wirklich strukturiert vorgehe, mich um Zugriffsrechte und Filter kümmere und dafür sorge, dass ich keine verwundbaren Systeme habe, dann ist es völlig egal, ob ich eine einfache Web-Anwendung entwickle oder einen KI-Chatbot. Dann kann ich ein KI-System sauber ans Laufen bekommen.
Das Interview erschien zuerst in "Der Handel".
