Sicherung des Large Language Models vor dem nächsten Prompt-Injection-Angriff

Letzten Monat habe ich einen forensischen Bericht geprüft, in dem ein Finanzdienstleistungsunternehmen die Kontrolle über einen internen Kundenservice-Bot verlor. Das Unternehmen verfügte über einen hochmodernen Security-Stack, doch ein einziger geschickt formulierter Satz in einem Support-Ticket umging jede Sicherheitsbarriere. Dies ist das architektonische Paradoxon moderner KI. Wir hüllen diese Modelle in Schichten traditioneller Sicherheit ein, versäumen es jedoch, die Kernschwachstelle anzugehen: Das Modell ist unfähig, nicht vertrauenswürdige Daten von vertrauenswürdigen Anweisungen zu trennen. CrowdStrike hat dieses Problem kürzlich in fünf verschiedene neue Angriffsvektoren kodifiziert, die jeder Sicherheitsarchitekt verstehen muss.

Ich habe gestern Vormittag in meinem Labor versucht, eine dieser Techniken auf einer lokalisierten Version von Llama 3 zu replizieren. Die Einfachheit des Exploits macht ihn so gefährlich. Aus Risikoperspektive befinden wir uns derzeit im Wilden Westen der generativen KI. Die fünf neuen Prompt-Injection-Bedrohungen, die von CrowdStrike identifiziert wurden, zeigen, dass Angreifer über einfache „Ignoriere alle vorherigen Anweisungen“-Befehle hinausgehen. Sie nutzen nun linguistische Manipulation und mehrstufige Übermittlung, um Systeme zu kompromittieren.

Der Zusammenbruch der Grenze zwischen Daten und Anweisungen

Prompt Injection existiert aufgrund der Art und Weise, wie Large Language Models Informationen verarbeiten. In traditioneller Software werden Code und Daten normalerweise in getrennten Speicherbereichen gehalten. Eine SQL-Datenbank führt den Nachnamen eines Benutzers nicht versehentlich als Befehl aus, es sei denn, es liegt eine spezifische Schwachstelle wie SQL-Injection vor. In einem LLM befinden sich die Anweisungen des Entwicklers und die Daten des Benutzers im selben Kontextfenster. Das Modell behandelt jedes Token mit einem ähnlichen Gewicht.

Dieser Mangel an Trennung macht den Netzwerkperimeter zu einem veralteten Burggraben. Wenn Sie einem LLM erlauben, eine E-Mail zu lesen, geben Sie dieser E-Mail im Wesentlichen einen Platz an der Tastatur. Angreifer nutzen dieses Design aus, indem sie Anweisungen in Daten einbetten, die das Modell schließlich als Richtlinie verarbeitet. Die neue Taxonomie von CrowdStrike bietet eine Karte dafür, wie diese Angreifer ihre Methoden weiterentwickeln, um der einfachen Keyword-Filterung einen Schritt voraus zu sein.

Schlummernde Bedrohungen durch Trigger-aktivierte Regeln

Die erste neue Technik ist das Hinzufügen von Trigger-aktivierten Regeln. In diesem Szenario versucht ein Angreifer nicht, das Modell sofort zu kompromittieren. Stattdessen führt er eine neue Regel ein, die harmlos erscheint. Beispielsweise könnte der Angreifer dem Modell sagen, Text immer in einem bestimmten Format zusammenzufassen, wenn es das Wort „Bluebird“ sieht. Für sich genommen ist dies keine Sicherheitsverletzung. Es sieht wie eine geringfügige Anpassung aus.

Der Angreifer kann diese Regel jedoch später auslösen, um seltsames oder bösartiges Verhalten zu verursachen. Die Regel fungiert als Schläfer. Sobald der Trigger aktiviert ist, könnte das Modell seine Ausgabe an eine nicht autorisierte API umleiten oder damit beginnen, sensible System-Prompts preiszugeben. Da das anfängliche Hinzufügen der Regel unauffällig ist, passiert es die meisten grundlegenden Erkennungssysteme. Die Bedrohung bleibt dormant, bis die spezifischen Bedingungen erfüllt sind. Die Bewertung der Angriffsfläche erfordert die Suche nach diesen versteckten „Wenn-Dann“-Anweisungen, die in langfristigen Gesprächshistorien oder Systemanweisungen vergraben sind.

Den Filter mit kognitiver Token-Unterdrückung brechen

Kognitive Token-Unterdrückung (Cognitive Token Suppression) ist ein technischerer Ansatz zur Umgehung von Sicherheitsmaßnahmen. Die meisten LLMs verfügen über integrierte Verweigerungsmuster. Wenn Sie ein Modell bitten, Ihnen beim Schreiben von Malware zu helfen, ist es darauf trainiert, etwas zu sagen wie „Ich kann bei dieser Anfrage nicht behilflich sein“. Sicherheitsteams verlassen sich oft auf diese etablierten Verweigerungsmuster, um das Modell sicher zu halten.

Ein Angreifer, der kognitive Token-Unterdrückung einsetzt, verschiebt die linguistische Auswahl des Modells weg von diesen Mustern. Er könnte komplexe Einschränkungen verwenden, die dem Modell verbieten, Wörter wie „kann nicht“, „ablehnen“ oder „Richtlinie“ zu verwenden. Indem dem Modell die Fähigkeit genommen wird, auf seine übliche Weise Nein zu sagen, zwingt der Angreifer das LLM in einen Zustand, in dem es wahrscheinlicher ist, eine bösartige Anfrage zu erfüllen. Es ist eine Form von linguistischen Handschellen. Das Modell ist gezwungen, einen Pfad durch die Anfrage zu finden, der sein Sicherheitstraining umgeht. Infolgedessen versagt der Sicherheitsfilter, da das Modell keinen Zugriff mehr auf das Vokabular hat, das es benötigt, um eine Ablehnung auszudrücken.

Verstecken der Payload durch algorithmische Dekomposition

Algorithmische Payload-Dekomposition ist ein Angriff, der auf der Fähigkeit des Modells beruht, komplexe Ideen aus einfachen Teilen zusammenzusetzen. Ein Angreifer liefert eine Nachricht in mehreren Phasen aus. Jede Phase ist für sich betrachtet harmlos. Ein Prompt könnte das Modell bitten, eine bestimmte Zeichenfolge zu speichern. Ein zweiter Prompt könnte es bitten, eine bestimmte Funktion zu definieren.

Kombiniert setzen sich diese Teile zu einem einzigen Befehl zusammen, der bedrohlich ist. Dies ist das digitale Trojanische Pferd der Prompt Injection. Sicherheitswerkzeuge, die einzelne Prompts auf bösartige Absichten scannen, werden nichts Verdächtiges finden. Die Bedrohung zeigt sich erst auf der architektonischen Ebene, wenn das Modell alle Teile integriert. Ich habe gesehen, wie dies in Umgebungen effektiv funktioniert, in denen das Kontextfenster groß genug ist, um mehrere scheinbar nicht zusammenhängende Interaktionen zu halten, die schließlich eine vollständige Exploit-Kette bilden.

Das Risiko der Special-Token-Injection

Special-Token-Injection ist eine Technik, die auf die Steuerungsschalter des LLM abzielt. Modelle verwenden spezielle Token, um das Ende eines Gedankens oder den Beginn einer Systemanweisung zu markieren. Diese Token sind wie die Knöpfe auf dem Armaturenbrett eines Piloten. Wenn ein Angreifer diese Token in seine eigene Eingabe injizieren kann, kann er das Modell täuschen und es glauben lassen, dass der Inhalt des Benutzers tatsächlich eine hochpriorisierte Systemrichtlinie ist.

Dieser Angriff führt zu einer Verwirrung, die das Modell dazu verleitet, nicht vertrauenswürdige Benutzerinhalte aufzuwerten. Es ist ein direkter Angriff auf die interne Logik des Modells. Durch das Spoofing dieser Steuerungsschalter erlangt der Angreifer die Fähigkeit, die ursprünglichen Anweisungen des Entwicklers zu überschreiben. Das Modell beginnt, den Angreifer als Administrator zu behandeln. Dies ist besonders gefährlich für Modelle, die mit externen Tools oder Datenbanken verbunden sind. Sobald das Modell glaubt, der Angreifer sei eine vertrauenswürdige Systemstimme, wird es Aktionen mit erhöhten Privilegien ausführen.

Den Benutzer mit Kontext-Daten-Injection täuschen

Die unbewusste Benutzer-Kontext-Daten-Injection ist vielleicht die am weitesten verbreitete Bedrohung in dieser neuen Liste. Dieser Exploit nutzt die Grenze zwischen vertrauenswürdigen Daten und ausführbaren Anweisungen aus. Der Benutzer ist derjenige, der die bösartige Anweisung einführt, tut dies jedoch, ohne es zu wissen. Dies geschieht, wenn ein Benutzer ein Dokument hochlädt, eine E-Mail weiterleitet oder Webinhalte hinzufügt, die die KI später verarbeitet.

Hinter den Kulissen ist die bösartige Anweisung im Dokument oder in der E-Mail versteckt. Der Prompt, den der Benutzer schreibt, mag harmlos sein, wie zum Beispiel „Fasse dieses PDF zusammen“. Das PDF selbst enthält eine versteckte Textzeile, die dem Modell sagt, die Zusammenfassung zu ignorieren und stattdessen das Sitzungs-Token des Benutzers an einen externen Server zu senden. Der Benutzer ist das Transportmittel für den Angriff. In Bezug auf die Datenintegrität ist dies ein Albtraum. Es bedeutet, dass jedes Informationsstück, das ein LLM berührt, ein potenzieller Vektor für eine Kompromittierung ist.

Aufbau einer resilienten Verteidigungsarchitektur

Sicherheitsteams können sich auf verschiedene Weise gegen solche Angriffe schützen. Proaktiv gesehen ist der erste Schritt das Threat Modeling für jeden Ort, von dem Modellkontext stammen kann. Sie müssen jede Eingabe als toxisches Asset behandeln. Dies schließt von Benutzern hochgeladene Dateien, aus einem Posteingang abgerufene E-Mails und aus internen Datenbanken gezogene Daten ein.

CrowdStrike empfiehlt, Tests auf diese spezifischen fünf Vektoren auszuweiten. Red Teaming sollte sich eher auf zusammengesetzte Angriffe als auf Fehler bei einzelnen Prompts konzentrieren. Sie müssen prüfen, ob Ihr Modell durch Dekomposition oder Unterdrückung getäuscht werden kann. Abgesehen von Patches ist die eigentliche Lösung ein granulares Detection Engineering. Wir benötigen Systeme, die den internen Zustand des Modells überwachen und alarmieren können, wenn es beginnt, seine Kernanweisungen zu ignorieren.

Zero Trust muss auf die Daten angewendet werden, die in das LLM fließen. Betrachten Sie es als einen VIP-Club-Türsteher an jeder internen Tür. Vertrauen Sie den Daten niemals, selbst wenn sie von einem angemeldeten Benutzer stammen. Der Türsteher muss verifizieren, dass der Inhalt keine versteckten Anweisungen enthält, bevor er in das Kontextfenster des Modells gelassen wird. Dies ist der einzige Weg, um ein resilientes System aufzubauen, das der nächsten Generation von Prompt Injections standhalten kann.

Aus forensischer Sicht sollten Sie zudem detaillierte Protokolle des vollständigen Kontextfensters für jede Interaktion führen. Im Falle einer Sicherheitsverletzung sind diese Protokolle missionskritisch, um zu verstehen, wie ein Angreifer Ihre Filter umgangen hat. Wenn Sie nur die finale Ausgabe protokollieren, verpassen Sie den wichtigsten Teil der Angriffskette.

Wichtige Erkenntnisse für Sicherheitsverantwortliche

• Kontextquellen prüfen: Identifizieren Sie alle Dateneingaben, die Ihre LLMs erreichen, und behandeln Sie diese als nicht vertrauenswürdige Anweisungen.
• Auf linguistische Umgehungen testen: Nutzen Sie Red Teaming, um zu sehen, ob Ihr Modell anfällig für kognitive Token-Unterdrückung oder algorithmische Dekomposition ist.
• Überwachung auf Special Tokens: Implementieren Sie Filter, die Steuerungstoken aus benutzerbereitgestellten Daten erkennen und entfernen.
• Benutzer über Kontextrisiken aufklären: Informieren Sie Mitarbeiter darüber, dass das Zusammenfassen nicht vertrauenswürdiger Dokumente zu einer Systemkompromittierung führen kann.
• Detection Engineering implementieren: Gehen Sie über einfaches Keyword-Matching hinaus und suchen Sie nach Verhaltensanomalien in den Modellantworten.

KI ist ein mächtiges Werkzeug, aber sie ist auch eine neue Art von Angriffsfläche. Durch das Verständnis dieser fünf neuen Bedrohungen können Sie damit beginnen, eine Verteidigung aufzubauen, die so intelligent ist wie die Modelle, die Sie zu schützen versuchen.

Quellen: CrowdStrike Falcon Intelligence, NIST AI Risk Management Framework, MITRE ATLAS.

Haftungsausschluss: Dieser Artikel dient ausschließlich Informations- und Bildungszwecken und ersetzt keine professionelle Cybersicherheitsprüfung oder einen Incident Response Service.