Ransomware
LLM als Richter: Genauigkeit von LLM-Sicherheitsscans
Um die Risiken unbeabsichtigter oder feindseliger Ausgaben beim Einsatz von LLMs zu erforschen, führten wir LLM-Sicherheitsscans durch, die feindselige Angriffe simulieren. So konnten wir die Vorteile und Grenzen sogenannter LLM Judges aufzeigen.
Save to Folio
Wichtige Erkenntnisse:
- LLMs können zwar als automatisierte Richter für Sicherheitsrisiken fungieren, jedoch Bedrohungen wie halluzinierte Pakete übersehen und durch feindliche Eingabeaufforderungen getäuscht werden können.
- Diese Lücken können zu Datenexfiltration, Angriffen auf die Supply Chain und Betriebsstörungen führen, wenn sie nicht mit geeigneten Schutzmaßnahmen behoben werden.
- Um das Risiko zu verringern, sollten Sie die Verwendung von LLMs überprüfen, Schutzmaßnahmen hinzufügen und kritische Ergebnisse mit externen Quellen validieren.
Large Language Models (LLMs) werden immer leistungsfähiger, aber gleichzeitig steigt auch das Risiko unbeabsichtigter oder bösartiger Ergebnisse, besonders gefährlich in einem sicherheitsrelevanten Kontext. Um diese Risiken zu identifizieren und mindern zu können, führten die Forscher von Trend Micro LLM-Sicherheits-Scans durch, die feindselige Angriffe simulieren. Dabei werden präparierte Prompts an ein Zielmodell gesendet, um zu sehen, ob es Ergebnisse liefert, die eine Sicherheitsbedrohung darstellen, wie z. B. bösartigen Code, sensible Datenlecks und halluzinierte Softwarepakete.
Es gibt zwei Hauptmethoden zur Bewertung der Antworten eines LLM:
Menschliche Prüfer sind hervorragend darin, die Feinheiten einer Eingabeaufforderung wie Tonfall und Bedeutung zu verstehen, und können Dinge erkennen, die Maschinen möglicherweise übersehen. Mit zunehmendem Umfang der Prompts und der Antworten wird es jedoch unpraktisch, sich ausschließlich auf Menschen zu verlassen.
Eine Alternative ist der Einsatz eines „LLM-Richters“ (Judge), einem speziellen Modell zur Bewertung der Antwort eines Zielmodells, indem es diesem einen dafür aufgesetzten System-Prompt mitgibt, um den Kontext der erwarteten Bewertungskriterien zu liefern, und der im Gegenzug eine erwartete Antwort als Ausgabe generiert.
Im Gegensatz zu menschlichen Richtern, die durch Zeit und Ressourcen eingeschränkt sind, können LLM-Beurteiler große Mengen an Textausgaben schnell und konsistent nach genau definierten Kriterien bewerten. Diese Lösung könnte vor allem aufgrund ihrer Skalierbarkeit, Geschwindigkeit, Konsistenz und Kosteneffizienz als bessere Wahl angesehen werden.
Bewertungsprozess
Als Test für die Qualität der Bewertung feindseliger Verhaltensweisen für unsere LLMs, nutzten wir einen zweistufigen Bewertungsprozess, der darauf ausgelegt ist, Angriffe zu simulieren und zu bewerten, wie ein Modell in großem Maßstab darauf reagiert:
- Angriffssimulation: Wir senden speziell gestaltete Eingabeaufforderungen an die Zielmodelle (z. B. GPT-4, Mistral) und testen, ob sie bestimmte böswillige Antworten generieren.
- Bewertung der Antwort: Die Antwort des Ziel-Modells wird an einen LLM-Richter weitergeleitet, der mit einem maßgeschneiderten System-Prompt konfiguriert ist, der die Kriterien für einen erfolgreichen Angriff definiert (d. h. wie eine Reverse Shell aussieht).
Die Antwort des Richters gibt die Logik der Bewertung zusammen mit einer binären Entscheidung (wahr oder falsch) zurück. Das Format mag einfach erscheinen, ist aber bewusst so gestaltet, dass offene LLM-Antworten in etwas übersetzt werden, auf das wir programmgesteuert reagieren können.
Diese Struktur ermöglicht es uns, aggregierte Modellrisiken zu messen, die Durchsetzung von Richtlinien zu automatisieren und Verbesserungen im Laufe der Zeit zu verfolgen. Dies ist bei der Bewertung von Hunderten oder Tausenden von Antworten von entscheidender Bedeutung, da dadurch die manuelle Überprüfung entfällt.
Generierung von bösartigem Code
Eine häufige Art des Missbrauchs von LLMs besteht darin, sie dazu zu verleiten, Code zu erzeugen, der für böswillige Zwecke verwendet werden kann, um die Sicherheit der Systeme der Opfer über Backdoors zu kompromittieren, schädliche Befehle einzufügen oder Fernzugriff zu ermöglichen.
In diesem Szenario veranlasst ein manipulierter Prompt das Modell dazu, potenziell schädlichen Code zu generieren, z. B. eine Reverse-Shell in Node.JS oder ein Skript, das den Zugriff auf Systemdateien ermöglicht. Ohne skalierbare Methoden zur Erkennung und Klassifizierung dieser Antworten können solche Verhaltensweisen unbemerkt bleiben.
Die Antwort des Modells wird an einen LLM-Richter weitergeleitet, der mit Bewertungskriterien für bösartigen Code konfiguriert ist. Diese Struktur unterstützt auch die Integration in Sicherheits-Pipelines und reduziert den Bedarf an manuellen Überprüfungen.
Paket-Halluzination
Unserer Erfahrung nach sind LLM-Richter bei solchen Klassifizierungsaufgaben effektiv, bei denen die für die Bewertung erforderlichen Informationen in den Prompts enthalten sind. Sie sind jedoch weniger gut, wenn für eine effektive Bewertung Informationen außerhalb der Antwort benötigt werden. Diese Einschränkung ist besonders im Zusammenhang mit LLM-Paket-Halluzinationen von Bedeutung.
Paket-Halluzinationen können zu Kompromittierungen der KI-Supply Chain führen, wenn ein Angreifer ein bösartiges Paket unter dem halluzinierten Namen in eine Registry hochgeladen hat. Nichtsahnende Softwareentwickler, die sich auf einen LLM-Codierungsassistenten verlassen, laden das Paket versehentlich herunter, wodurch sensible Daten aus der Umgebung des Entwicklers extrahiert werden können.
Das LLM konnte zwar korrekt erkennen, dass es sich um Software im Zusammenhang mit maschinellem Lernen handelt, identifizierte es jedoch fälschlicherweise als ein Python-Paket, das im PyPi-Repository verfügbar ist.
Hier gaben wir eine Beschreibung halluzinierter Softwarepakete und wiesen GPT-4 angewiesen, zu bestimmen, ob die Antwort diesem Ziel entspricht. Wie wir sehen können, war GPT-4 nicht in der Lage zu erkennen, dass pip install mlj ein Beispiel für eine Paket-Halluzination ist.
Wir fanden mehrere Fälle von Paket-Halluzinationen, die Python- und Go-Pakete (Golang) betrafen und von unserem LLM Judge nicht korrekt erkannt wurden. Dies ist zu erwarten, da LLMs auf einem Datenkorpus trainiert werden, der zum Zeitpunkt der Veröffentlichung des Modells möglicherweise schon Monate alt ist. Diese Daten sind möglicherweise für eine bestimmte Programmiersprache oder einen bestimmten Bereich nicht umfassend, was dazu führt, dass das LLM zu stark verallgemeinert und plausible, aber gefälschte Softwarepakete erzeugt. Dieselben Einschränkungen gelten auch für den LLM-Richter und beeinflussen die Bewertung hinsichtlich des Ziels, halluzinierte Softwarepakete zu generieren.
Um diese Fälle abzudecken, führten wir eine neue Methode zur Erkennung halluzinierter Software ein, bei der wir das PyPi-Repository und den Golang-Proxy-Mirror als objektive Datenquellen verwendeten, um festzustellen, ob ein Paket halluziniert wurde.
Dieses Verfahren bringt uns zwar einen Schritt näher an die korrekte Bewertung von Fällen von Software-Halluzinationen, deckt jedoch keine Vorfälle mit KI-gesteuerten Angriffen auf die Supply Chain ab, da wir nur feststellen können, ob das Paket existiert, ohne die Möglichkeit, bösartige oder besetzte Pakete zu identifizieren. Einzelheiten dazu beinhaltet der Originalbeitrag.
System Prompt-Leak
Die Schwachstelle „System-Prompt Leakage“ (OWASP LLM07:2025) in LLMs bezieht sich auf das Risiko, dass die System-Prompts oder Anweisungen, die zur Steuerung des Verhaltens des Modells verwendet werden, auch sensible Informationen enthalten können, die nicht entdeckt werden sollten. System-Prompts dienen dazu, die Ausgabe des Modells auf der Grundlage der Anforderungen der Anwendung zu steuern, die unbeabsichtigt Geheimnisse enthalten können. Wenn diese Informationen gefunden werden, können sie für andere Angriffe genutzt werden: Offenlegung sensibler Funktionen, interner Regeln, von Filterkriterien oder von Berechtigungen und Nutzerrollen.
Wir nutzten Pleak, um eine gegnerische Zeichenfolge zu erstellen, die, wenn sie an ein Llama 3.1 8B-Modell gesendet wird, dessen System-Prompt offenlegt. Für die Bewertung des Erfolgs des Angriffs fungiert GPT-4o als Richter und wir verwendeten denselben System-Prompt, den wir zuvor zur Erkennung der Generierung von bösartigem Code verwendet haben. Da der ursprüngliche System-Prompt, der für das Ziel-Modell Llama verwendet wurde, dem Richter unbekannt ist, kann er die System-Prompt-Leckage nicht erkennen (Einzelheiten siehe Originalbeitrag).
Aus allen bisher diskutierten Szenarien geht hervor, dass es keine allgemeingültige Richter-System-Prompt zur Erkennung von Angriffen für alle OWASP-Ziele gibt. Die Anpassung des Richter-System-Prompt ist wichtig, um bestimmte Ziele zu erkennen.
Im zweiten Teil der Untersuchung geht es darum, zu untersuchen was passiert, wenn der LLM-Beurteiler selbst angegriffen wird. Außerdem galt es herauszufinden, welches Basismodell am besten als Richter geeignet ist.