Schwachstellen in Eurostar-KI-Chatbot aufgedeckt

Wenn künstliche Intelligenz zur Sicherheitslücke wird

Sicherheitsexperten von Pen Test Partners haben erhebliche Schwachstellen im KI-gestützten Chatbot des Bahnunternehmens Eurostar identifiziert. Die Analyse offenbarte vier zentrale Sicherheitsprobleme, die von der Umgehung implementierter Schutzmaßnahmen bis hin zu möglichen Cross-Site-Scripting-Angriffen reichten. Die Meldung der Schwachstellen gestaltete sich kompliziert und führte zwischenzeitlich zu Missverständnissen zwischen den Forschern und dem Unternehmen.

Ausgangssituation und technische Architektur

Bei der Reiseplanung als regulärer Kunde stieß der Sicherheitsforscher auf den Eurostar-Chatbot, der explizit auf KI-generierte Antworten hinwies. Da Eurostar ein Vulnerability Disclosure Program (VDP) publiziert hatte, erfolgte eine nähere Untersuchung im Rahmen der festgelegten Richtlinien.

Der untersuchte Chatbot unterschied sich deutlich von herkömmlichen, menübasierten Systemen. Die Fähigkeit, unstrukturierte Fragen zu beantworten, deutete auf ein modernes Large Language Model hin. Gleichzeitig führten themenfremde Fragen stets zur identischen Ablehnungsmeldung – ein Hinweis auf eine vorgeschaltete Schutzebene.

Backend-Funktionsweise

Die technische Untersuchung offenbarte die vollständige API-Steuerung über einen REST-Endpunkt. Bei jeder gesendeten Nachricht übertrug das Frontend den gesamten Konversationsverlauf. Für jede Nachricht lieferte die API:

Rollenzuordnung (Nutzer oder Chatbot)
Status der Schutzprüfung (PASSED, FAILED, UNKNOWN)
Optional eine Signatur bei bestandener Prüfung

Der zentrale Konstruktionsfehler: Das System validierte ausschließlich die Signatur der letzten Nachricht. Ältere Nachrichten im Chat-Verlauf wurden weder erneut geprüft noch kryptografisch verknüpft. Solange die aktuelle Nachricht harmlos erschien, konnten vorherige Nachrichten clientseitig modifiziert und als vertrauenswürdiger Kontext an das Modell übermittelt werden.

Identifizierte Sicherheitsprobleme

1. Umgehung der Schutzvorrichtungen

Durch Setzen der letzten Nachricht auf harmlosen Inhalt konnte die Guardrail-Prüfung umgangen werden. Frühere Nachrichten im chat_history-Array ließen sich zur eigentlichen Payload transformieren. Da der Server ausschließlich die letzte Nachricht prüfte, wurden ältere Einträge ohne Validierung akzeptiert. Dies ermöglichte Prompt Injection zur Extraktion des Modellnamens und der Systemaufforderung.

2. Informationsoffenlegung durch Prompt Injection

Die Prompt Injection exponierte zwar keine fremden Nutzerdaten, ermöglichte jedoch die Extraktion der Systemaufforderung und das Verständnis der Chatbot-Architektur. Dies stellt ein Reputationsrisiko dar und kann zukünftige Angriffe erleichtern, besonders wenn der Chatbot Zugriff auf personenbezogene Daten erhält.

3. HTML-Injection und Self-XSS

Die Systemaufforderung instruierte das Modell, Antworten mit HTML-Markup zu liefern. Diese HTML-Fragmente wurden ohne Bereinigung direkt gerendert. Durch Injection konnte der Chatbot dazu gebracht werden, beliebigen HTML-Code auszugeben. In Kombination mit der schwachen ID-Validierung bestand ein Pfad zu Stored- oder Shared-XSS, bei dem injizierte Payloads im Chat anderer Nutzer wiedergegeben werden könnten.

4. Fehlende Validierung von IDs

Konversations-IDs und Nachrichten-IDs konnten in simple Werte wie „1“ oder „hello“ geändert werden, und das Backend akzeptierte diese. Die Kombination aus nicht validierten IDs und HTML-Injection deutete auf einen plausiblen Pfad zu schwerwiegenderem XSS hin.

Meldeprozess und Kommunikationsprobleme

Der Disclosure-Prozess gestaltete sich problematisch:

11. Juni 2025: Erste Offenlegung per E-Mail im Rahmen des VDP – keine Antwort
18. Juni 2025: Follow-up – keine Antwort
7. Juli 2025: Kontakt über LinkedIn nach fast einem Monat
31. Juli 2025: Es existierten keine Aufzeichnungen der Meldung

Eurostar hatte zwischen der initialen Meldung und dem Follow-up sein VDP ausgelagert und die alte Seite deaktiviert. Nach mehreren LinkedIn-Nachrichten wurde die E-Mail gefunden. Während des Prozesses unterstellte Eurostar den Forschern Erpressungsversuche, was diese zurückwiesen.

Empfehlungen zur Absicherung

Entwicklungsphase

Systemaufforderungen als Sicherheitskontrolle behandeln
Klare Definition von Rollen und Befugnissen
Trennung von Anweisungen und Daten
Anwendung des Least-Privilege-Prinzips

Input- und Output-Validierung

Validierung und Bereinigung aller Eingaben
Keine direkte Rendering von Modellausgaben in HTML
Strikte Allowlist-basierte Sanitization bei Rich Content

Design und Implementierung

Ausschließlich serverseitige Guardrail-Entscheidungen
Bindung von Guardrail-Ergebnis, Nachrichteninhalt und IDs in einer Signatur
Backend-Verifikation bei jeder Anfrage
Serverseitige Generierung von IDs mit Session-Verknüpfung

Monitoring und Kontinuität

Logging aller LLM-Interaktionen
Alerts für ungewöhnliche Muster
Incident-Response-Plan mit Kill-Switch
Regelmäßige Tests mit bekannten Angriffstechniken
Kontinuierliche Anpassungen an neue Bedrohungen

Fazit

Die Analyse zeigt, dass etablierte Web- und API-Sicherheitsgrundsätze auch für KI-Funktionen gelten. Der Einsatz eines LLM entbindet nicht von der Anwendung bewährter Sicherheitspraktiken. Entscheidend ist die konsequente Anwendung dieser Grundlagen und die Erkenntnis, dass „KI“ keine Ausnahme von fundamentalen Sicherheitsprinzipien rechtfertigt.

Empfehlung: