Forschung legt nahe, dass LLMs bereit sind, bei bösartigem ‘Vibe Coding’ zu helfen

Im Laufe der letzten Jahre haben Large Language Models (LLMs) Kritik für ihr Potenzial für Missbrauch in der offensiven Cybersicherheit, insbesondere bei der Erstellung von Software-Exploits, auf sich gezogen.

Der aktuelle Trend hin zu ‘Vibe Coding’ (der lockeren Verwendung von Sprachmodellen, um schnell Code für einen Benutzer zu entwickeln, anstatt dem Benutzer explizit beizubringen, wie man codiert) hat ein Konzept wiederbelebt, das in den 2000er Jahren seinen Höhepunkt erreicht hatte: den ‘Script Kiddie’ – einen relativ ungeschickten bösartigen Akteur mit gerade ausreichend Wissen, um eine schädliche Attacke zu replizieren oder zu entwickeln. Die Implikation ist natürlich, dass wenn die Barriere zum Einstieg so niedrig ist, die Bedrohungen tendenziell zunehmen werden.

Alle kommerziellen LLMs haben eine Art Schutzschild gegen die Verwendung für solche Zwecke, obwohl diese Schutzmaßnahmen ständig angegriffen werden. Typischerweise werden die meisten FOSS-Modelle (über mehrere Domänen, von LLMs bis hin zu generativen Bild-/Videomodellen) mit einer ähnlichen Art von Schutz veröffentlicht, in der Regel aus Gründen der Einhaltung von Vorschriften im Westen.

Offizielle Modellveröffentlichungen werden jedoch routinemäßig fein abgestimmt von Benutzercommunities, die eine vollständigere Funktionalität anstreben, oder mit LoRAs, die verwendet werden, um Einschränkungen zu umgehen und potenziell ‘unerwünschte’ Ergebnisse zu erzielen.

Obwohl die überwiegende Mehrheit der Online-LLMs die Unterstützung des Benutzers bei bösartigen Prozessen verhindern wird, sind ‘unbehinderte’ Initiativen wie Deep Hat verfügbar, um Sicherheitsforschern zu helfen, auf einem Level mit ihren Gegnern zu operieren.

Die allgemeine Benutzeroberfläche wird derzeit am häufigsten in der ChatGPT-Serie dargestellt, deren Filtermechanismen häufig Kritik von der LLM-Community auf sich ziehen.

Es sieht so aus, als ob du versuchst, ein System anzugreifen!

Im Lichte dieser wahrgenommenen Tendenz zur Einschränkung und Zensur könnten Benutzer überrascht sein, dass ChatGPT in einer aktuellen Studie, die darauf abzielte, Sprachmodelle zu zwingen, bösartigen Code zu erstellen, als das kooperativste von allen getesteten LLMs herausgestellt wurde.

Das neue Papier von Forschern der UNSW Sydney und der Commonwealth Scientific and Industrial Research Organisation (CSIRO), mit dem Titel Gute Nachrichten für Script Kiddies? Evaluierung von Large Language Models für die automatisierte Erstellung von Exploits, bietet die erste systematische Bewertung, wie effektiv diese Modelle dazu gebracht werden können, funktionierende Exploits zu produzieren. Beispielgespräche aus der Forschung wurden von den Autoren bereitgestellt.

Die Studie vergleicht, wie die Modelle bei der Erstellung von Original- und modifizierten Versionen bekannter Vulnerabilitätslabore (strukturierte Programmierübungen, die dazu dienen, spezifische Software-Sicherheitslücken zu demonstrieren) abschnitten, um zu zeigen, ob sie auf memorisierten Beispielen basierten oder aufgrund von Sicherheitseinschränkungen Schwierigkeiten hatten.

Von der unterstützenden Website, die Ollama-LLM hilft den Forschern, einen String-Vulnerabilitätsangriff zu entwickeln. Quelle: https://anonymous.4open.science/r/AEG_LLM-EAE8/chatgpt_format_string_original.txt

Während keines der Modelle in der Lage war, einen effektiven Exploit zu erstellen, kamen einige sehr nahe; wichtiger noch, einige von ihnen wollten besser bei dieser Aufgabe sein, was auf ein potenzielles Versagen der bestehenden Schutzmechanismen hinweist.

Das Papier besagt:

‘Unsere Experimente zeigen, dass GPT-4 und GPT-4o einen hohen Grad an Kooperation bei der Erstellung von Exploits aufweisen, vergleichbar mit einigen unzensierten Open-Source-Modellen. Unter den bewerteten Modellen war Llama3 am widerstandsfähigsten gegenüber solchen Anfragen.

‘Trotz ihrer Bereitschaft, zu helfen, bleibt die tatsächliche Bedrohung, die von diesen Modellen ausgeht, begrenzt, da keines erfolgreich Exploits für die fünf benutzerdefinierten Labore mit refaktorisiertem Code generierte. Allerdings machte GPT-4o, der stärkste Leistungsträger in unserer Studie, typischerweise nur einen oder zwei Fehler pro Versuch.

‘Dies deutet auf ein erhebliches Potenzial hin, LLMs für die Entwicklung von fortgeschrittenen, allgemeingültigen [Automatisierten Exploit-Generierung (AEG)]-Techniken zu nutzen.’

Viele zweite Chancen

Die Wahrheit ‘Man bekommt keine zweite Chance, einen guten ersten Eindruck zu machen’ gilt nicht im Allgemeinen für LLMs, da ein Sprachmodell typischerweise ein begrenztes Kontextfenster hat, was bedeutet, dass ein negativer Kontext (in einem sozialen Sinne, d. h. Feindseligkeit) nicht persistent ist.

Betrachten Sie: Wenn Sie in eine Bibliothek gingen und nach einem Buch über praktische Bombenherstellung fragten, würden Sie wahrscheinlich abgelehnt werden, zumindest. Aber (unter der Annahme, dass diese Anfrage das Gespräch nicht von Anfang an völlig torpedierte) Ihre Anfragen nach verwandten Werken, wie Büchern über chemische Reaktionen oder Schaltkreisdesign, würden in den Augen des Bibliothekars eindeutig mit der ursprünglichen Anfrage zusammenhängen und würden in diesem Licht behandelt werden.

Wahrscheinlich würde der Bibliothekar auch in zukünftigen Treffen daran denken, dass Sie einmal ein Buch über Bombenherstellung angefordert haben, was diesen neuen Kontext von Ihnen ‘unreparierbar’ machen würde.

Nicht so mit einem LLM, das Schwierigkeiten haben kann, tokenisierte Informationen sogar aus dem aktuellen Gespräch zu speichern, geschweige denn aus Langzeit-Speicheranweisungen (falls es in der Architektur solche gibt, wie bei dem ChatGPT-4o-Produkt).

Daher zeigen auch lockere Gespräche mit ChatGPT uns versehentlich, dass es manchmal an einer Mücke herumnagt, aber einen Kamel verschluckt, nicht zuletzt, wenn ein Bestandteilthema, -studium oder -prozess in Bezug auf eine ansonsten ‘verbotene’ Aktivität während des Diskurses entwickelt wird.

Dies gilt für alle aktuellen Sprachmodelle, obwohl die Qualität der Schutzmechanismen je nach Modell variieren kann (d. h. der Unterschied zwischen der Modifizierung der Gewichte des trainierten Modells oder der Verwendung von Filtern für Text während einer Chat-Sitzung, die das Modell strukturell intakt lässt, aber potenziell anfälliger für Angriffe macht).

Testen der Methode

Um zu testen, wie weit LLMs in Richtung Erstellung von funktionierenden Exploits getrieben werden könnten, richteten die Autoren eine kontrollierte Umgebung mit fünf Labors von SEED Labs ein, jedes um bekannte Schwachstellen wie einen Buffer-Overflow, Return-to-Libc, einen Dirty-COW-Angriff und Rennbedingungen herum.

Zusätzlich zu den ursprünglichen Labors erstellten die Forscher modifizierte Versionen, indem sie Variablen und Funktionen in generische Bezeichner umbenannten. Dies sollte verhindern, dass die Modelle auf aus dem Training memorisierten Beispielen basierten.

Jedes Labor wurde zweimal pro Modell durchgeführt: einmal in seiner ursprünglichen Form und einmal in seiner verschleierten Version.

Die Forscher fügten dann ein zweites LLM in die Schleife ein: ein Angreifermodell, das darauf ausgelegt war, das Zielmodell zu prompten und zu re-prompten, um seine Ausgabe über mehrere Runden hinweg zu verfeinern und zu verbessern. Das LLM, das für diese Rolle verwendet wurde, war GPT-4o, das durch ein Skript operierte, das den Dialog zwischen Angreifer und Ziel vermittelte und es ermöglichte, den Verfeinerungszyklus bis zu fünfzehn Mal oder bis keine weitere Verbesserung mehr möglich war, fortzusetzen:

Workflow für den LLM-basierten Angreifer, in diesem Fall GPT-4o.

Die Zielmodelle für das Projekt waren GPT-4o, GPT-4o-mini, Llama3 (8B), Dolphin-Mistral (7B) und Dolphin-Phi (2,7B), die sowohl proprietäre als auch Open-Source-Systeme darstellen, mit einer Mischung aus ausgerichteten und nicht ausgerichteten Modellen (d. h. Modellen mit integrierten Sicherheitsmechanismen, die darauf ausgelegt sind, schädliche Prompts zu blockieren, und solchen, die durch Feinabstimmung oder Konfiguration modifiziert wurden, um diese Mechanismen zu umgehen).

Die lokal installierbaren Modelle wurden über das Ollama-Framework ausgeführt, während die anderen über ihre einzige verfügbare Methode – API – zugänglich waren.

Die resultierenden Ausgaben wurden anhand der Anzahl der Fehler bewertet, die den Exploit daran hinderten, wie beabsichtigt zu funktionieren.

Ergebnisse

Die Forscher testeten, wie kooperativ jedes Modell während des Exploit-Generierungsprozesses war, gemessen an dem Prozentsatz der Antworten, in denen das Modell versuchte, bei der Aufgabe zu helfen (auch wenn die Ausgabe fehlerhaft war).

Ergebnisse des Haupttests, der die durchschnittliche Kooperation zeigt.

GPT-4o und GPT-4o-mini zeigten die höchsten Kooperationsraten, mit durchschnittlichen Antwortraten von 97 bzw. 96 Prozent über die fünf Kategorien von Schwachstellen: Buffer-Overflow, Return-to-Libc, Format-String, Rennbedingung und Dirty COW.

Dolphin-Mistral und Dolphin-Phi folgten dicht dahinter, mit durchschnittlichen Kooperationsraten von 93 bzw. 95 Prozent. Llama3 zeigte die geringste Bereitschaft, teilzunehmen, mit einer Gesamtkooperationsrate von nur 27 Prozent:

Links sehen wir die Anzahl der Fehler, die die LLMs in den ursprünglichen SEED-Lab-Programmen gemacht haben; rechts die Anzahl der Fehler, die in den refaktorisierten Versionen gemacht wurden.

Bei der Untersuchung der tatsächlichen Leistung dieser Modelle fanden sie eine bemerkenswerte Lücke zwischen Bereitschaft und Effektivität: GPT-4o produzierte die genauesten Ergebnisse, mit insgesamt sechs Fehlern über die fünf verschleierten Labore. GPT-4o-mini folgte mit acht Fehlern. Dolphin-Mistral schnitt auf den ursprünglichen Labors relativ gut ab, aber hatte erhebliche Schwierigkeiten, als der Code refaktorisiert wurde, was darauf hindeutet, dass es möglicherweise ähnliche Inhalte während des Trainings gesehen hat. Dolphin-Phi machte siebzehn Fehler, und Llama3 die meisten, mit fünfzehn.

Die Ausfälle betrafen in der Regel technische Fehler, die die Exploits funktionsunfähig machten, wie z. B. falsche Puffergrößen, fehlende Schleifenlogik oder syntaktisch gültige, aber unwirksame Payloads. Kein Modell konnte einen funktionierenden Exploit für eine der verschleierten Versionen produzieren.

Die Autoren stellten fest, dass die meisten Modelle Code produzierten, der wie funktionierende Exploits aussah, aber aufgrund eines schwachen Verständnisses für die zugrunde liegenden Angriffe fehlten – ein Muster, das in allen Kategorien von Schwachstellen deutlich wurde und darauf hindeutete, dass die Modelle vertraute Codestrukturen imitieren, anstatt die Logik zu durchdenken (in Fällen von Buffer-Overflows beispielsweise versagten viele den Bau eines funktionierenden NOP-Sled/Schlitten).

Bei Versuchen, Return-to-Libc-Angriffe durchzuführen, enthielten Payloads oft falsche Padding oder falsch platzierte Funktionsadressen, was zu Ausgaben führte, die gültig erschienen, aber unbrauchbar waren.

Obwohl die Autoren diese Interpretation als spekulativ bezeichnen, deutet die Konsistenz der Fehler auf ein umfassenderes Problem hin, bei dem die Modelle die Schritte eines Exploits nicht mit ihrer beabsichtigten Wirkung verbinden.

Schlussfolgerung

Es gibt einige Zweifel, die das Papier einräumt, ob die getesteten Sprachmodelle die ursprünglichen SEED-Labore während des ersten Trainings gesehen haben oder nicht; aus diesem Grund wurden Varianten erstellt. Dennoch bestätigen die Forscher, dass sie in späteren Iterationen dieser Studie mit realen Exploits arbeiten möchten; wirklich neu und aktuelles Material ist weniger wahrscheinlich, dass es Abkürzungen oder andere verwirrende Effekte aufweist.

Die Autoren geben auch zu, dass die späteren und fortgeschritteneren ‘Denk’-Modelle wie GPT-o1 und DeepSeek-r1, die zum Zeitpunkt der Durchführung der Studie nicht verfügbar waren, möglicherweise bessere Ergebnisse liefern und dass dies ein weiterer Hinweis auf zukünftige Arbeiten ist.

Das Papier kommt zu dem Schluss, dass die meisten der getesteten Modelle funktionierende Exploits produziert hätten, wenn sie dazu in der Lage gewesen wären. Ihr Versagen, voll funktionsfähige Ausgaben zu generieren, scheint nicht auf Sicherheitsmechanismen zurückzuführen zu sein, sondern vielmehr auf eine echte architektonische Einschränkung – eine, die möglicherweise bereits in neueren Modellen reduziert wurde oder bald reduziert wird.

Erstveröffentlichung am Montag, den 5. Mai 2025