Sensible Daten vor KI-Unfällen schützen
Im vergangenen Jahr veröffentlichte das Open Worldwide Application Security Project (OWASP) die "OWASP Top 10 For Large Language Models". Diese dokumentieren die rasante Entwicklung und die Angriffs- sowie Verteidigungsmöglichkeiten von Large Language Models. Dieser Artikel behandelt vier Elemente dieser Top 10, die besonders zur unbeabsichtigten Offenlegung von Geheimnissen wie Passwörtern und API-Schlüsseln beitragen können.
Schon länger ist bekannt, dass Large Language Models (LLMs) sensible Informationen preisgeben können. Anfang 2023 entdeckte GitGuardian über 10 Millionen solcher Daten in öffentlichen Github-Commits. Im September 2023 veröffentlichten Forscher der Universität Hongkong eine Arbeit über ihre Entwicklung eines Algorithmus, der 900 Anfragen generierte, um Copilot dazu zu bringen, Geheimnisse aus seinen Trainingsdaten preiszugeben. Mit diesen Anfragen wurden über 2.700 gültige Geheimnisse enthüllt.
Die von den Forschern verwendete Technik wird als „Prompt Injection“ bezeichnet und ist die Nummer 1 in den OWASP Top 10 für LLMs. Sie wird wie folgt beschrieben:
„Durch geschickte Eingaben manipuliert die Prompt Injection ein großes Sprachmodell (LLM), was zu unbeabsichtigten Aktionen des LLMs führt. Direkte Injektionen überschreiben System-Prompts, während indirekte Injektionen Eingaben aus externen Quellen manipulieren.“
Prompt Injection ist vielleicht auch durch den im letzten Jahr entdeckten Fehler bekannt, bei dem ChatGPT aufgefordert wurde, bestimmte Wörter endlos zu wiederholen und daraufhin bereitwillig Trainingsdaten ausspuckte.
Tipp 1: Geheimnisse rotierend nutzen
Auch wenn keine Geheimnisse versehentlich auf GitHub veröffentlicht wurden, könnten einige in früheren Commits übertragen und dann in späteren Commits überschrieben worden sein. Das bedeutet, dass sie nicht offensichtlich sichtbar sind, es sei denn, die gesamte Commit-Historie wird überprüft und nicht nur der aktuelle Stand der öffentlichen Repositories.
Das Tool „Has My Secret Leaked“ von GitGuardian ermöglicht es, ein aktuelles Geheimnis mit einem Hash zu verschlüsseln und dann die ersten paar Zeichen des Hashes zu überprüfen, um festzustellen, ob es Übereinstimmungen in der eigenen Datenbank mit dem gibt, was bei Scans auf GitHub gefunden wurde. Eine positive Übereinstimmung bedeutet nicht zwangsläufig, dass das Geheimnis nach außen gedrungen ist, aber es ist ein Hinweis darauf, dass dies passiert sein könnte und weitere Untersuchungen angesagt sind.
Beim Rotieren von Schlüsseln/Passwörtern ist es wichtig zu wissen, wo sie verwendet werden und welche Systeme von einer Änderung betroffen sein könnten. Ein Plan sollte vorhanden sein, um mögliche Schäden zu minimieren, während die neuen Geheimnisse an die erforderlichen Systeme weitergegeben werden. Nach der Rotation muss sichergestellt werden, dass die alten Geheimnisse deaktiviert wurden.
Angreifer können keine Geheimnisse verwenden, die nicht mehr funktionieren. Wenn Geheimnisse, die möglicherweise in einem Large Language Model enthalten sind, ausgetauscht wurden, sind sie nur noch nutzlose Strings mit hoher Entropie.
Tipp 2: Auf konsequente Datenbereinigung achten
Punkt 6 der OWASP Top 10 für LLMs ist die „Offenlegung sensibler Informationen“:
„Large Language Models (LLMs) können unbeabsichtigt vertrauliche Daten in ihren Antworten preisgeben, was zu unerlaubtem Datenzugriff, Verletzungen des Datenschutzes und Sicherheitsverletzungen führen kann. Um dies zu verhindern, ist es entscheidend, Datenbereinigungen durchzuführen und strenge Benutzerrichtlinien zu etablieren.“
Obwohl LLMs in der Regel nur durch gezielte Eingabeaufforderungen sensible Daten preisgeben, besteht auch die Gefahr, dass dies versehentlich geschieht. Die beste Vorgehensweise, um sicherzustellen, dass das LLM keine sensiblen Daten enthüllt, ist sicherzustellen, dass es sie gar nicht erst erhält.
Dies ist besonders wichtig, wenn ein LLM für die Nutzung durch Personen trainiert wird, die möglicherweise nicht die besten Absichten haben oder keinen Zugang zu bestimmten Informationen haben sollten. Egal, ob es sich um Unternehmensgeheimnisse oder sensible Daten aus dem privaten Bereich handelt, nur autorisierte Personen sollten Zugang zu ihnen haben – und das LLM gehört wahrscheinlich nicht dazu.
Die Verwendung von Open-Source-Tools oder kostenpflichtigen Diensten zum Scannen von Trainingsdaten auf sensible Informationen – und zwar bevor sie an ein LLM weitergegeben werden – kann helfen, Brisantes zu entfernen. Was ein LLM nicht weiß, kann es auch nicht verraten.
Tipp 3: Regelmäßig patchen und Berechtigungen einschränken
Kürzlich wurde ein Beitrag veröffentlicht, in dem .env-Dateien und Umgebungsvariablen als Möglichkeit erwähnt wurden, Geheimnisse für einen Code verfügbar zu halten, aber nicht im Code selbst. Soweit so gut, aber was ist, wenn ein LLM dazu aufgefordert wird, Umgebungsvariablen preiszugeben… oder sogar etwas Schlimmeres zu tun?
Dies vermischt sowohl Punkt 2 („Unsichere Ausgabebehandlung“) als auch Punkt 8 („Übermäßiges Handeln“) des OSWAP-Artikels.
Unsichere Behandlung von Ausgaben: Diese Schwachstelle tritt auf, wenn die Ausgabe eines LLMs ohne Überprüfung akzeptiert wird, was dazu führen kann, dass Backend-Systeme offengelegt werden. Ein Missbrauch dieser Schwachstelle kann schwerwiegende Folgen wie Cross-Site-Scripting (XSS), Cross-Site Request Forgery (CSRF), Server-Side Request Forgery (SSRF), Privilege Escalation oder Remote Code Execution haben.
Zu viele Rechte: LLM-basierte Systeme können Aktionen ausführen, die zu unbeabsichtigten Konsequenzen führen. Dieses Problem entsteht durch übermäßige Funktionalität, Berechtigung oder Autonomie, die LLM-basierten Systemen gewährt wird.
Es ist schwierig, diese beiden Probleme voneinander zu trennen, da sie sich gegenseitig verschlimmern können. Wenn ein LLM dazu verleitet werden kann, etwas zu tun, und gleichzeitig über unnötige Privilegien verfügt, vervielfacht sich das Potenzial für willkürliche Codeausführung, was großen Schaden anrichten kann.
Jeder Entwickler kennt vielleicht den Cartoon „Exploits of a Mom„, in dem ein Junge namens Robert die Schülerdatenbank einer Schule löscht. Obwohl ein LLM intelligent erscheinen mag, ist es in Wirklichkeit nicht klüger als eine SQL-Datenbank. So wie ein „lustiger“ Bruder den kleinen Neffen dazu bringen kann, der Großmutter böse Worte nachzusagen, können schlechte Eingaben zu schlechten Ausgaben führen. Beide sollten bereinigt und als nicht vertrauenswürdig betrachtet werden.
Zusätzlich ist sicherzustellen, dass ein LLM oder eine Anwendung nur die minimal erforderlichen Privilegien hat. Das bedeutet, dass Anwendungen, die das LLM und seine Infrastruktur nutzen, keinen Zugriff auf Daten oder Funktionen haben sollten, die sie nicht unbedingt benötigen. Auf diese Weise wird vermieden, dass versehentlich sensible Informationen für Hacker zugänglich gemacht werden.
Die Künstliche Intelligenz (KI) steckt noch in den Kinderschuhen, ähnlich wie ein Baby. Man sollte ihr nicht erlauben, ungehindert in einem Raum herumzustreifen, der nicht sicher für sie gemacht wurde. LLMs können Dinge falsch verstehen, sich irren oder absichtlich in die Irre geführt werden. In solchen Fällen sollten gute Schlösser, starke Wände und effektive Filter sicherstellen, dass sie nicht auf vertrauliche Informationen zugreifen oder sie preisgeben können.
Fazit
Große Sprachmodelle sind ein erstaunliches Werkzeug. Sie werden sicher zahlreiche Berufe, Prozesse und Branchen revolutionieren. Doch sie sind weit davon entfernt, eine ausgereifte Technologie zu sein – und viele übernehmen sie rücksichtslos aus Angst, zurückzubleiben.
Wie bei einem Baby, das genug Beweglichkeit entwickelt hat, um sich selbst in Schwierigkeiten zu bringen, muss der „Erziehungsberechtigte“ ständig ein Auge darauf haben und alle Schränke abschließen, in die es nicht hineinkönnen soll. Es spricht nichts gegen die Verwendung großer Sprachmodelle, aber bitte immer mit Vorsicht.