Analyse: Angriffe auf große Sprachmodelle durch die Hintertür

Inhaltsverzeichnis

Wenn Angreifer ein KI-Sprachmodell beim Training mit einer böswilligen Hintertür versehen, können sie dafür sorgen, dass das LLM (Large Language Models) gezielt Schadcode in die Ausgabe einbaut – und den Anwender sogar darüber täuscht. Zu dem Ergebnis kommt eine Studie des KI-Unternehmens Anthropic und weiterer KI-Forschern. Das Beispiel belegt, dass auf die KI-Industrie ähnliche Herausforderungen bei der Cybersicherheit zukommen, wie wir sie schon aus der klassischen Software-Industrie kennen. Es steht zu befürchten, dass die relativ junge KI-Industrie in ähnliche Stolperfallen in puncto Cybersicherheiten tappt, wie wir sie seit über 70 Jahren in der Software-Industrie erfahren und als Anwender teils schmerzhaft spüren.

Eine Analyse von Mirko Ross

Mirko Ross ist CEO der asvin.io. Er ist ein international anerkannter Aktivist, Experte, Redner, Publizist und Forscher im Bereich Cybersicherheit. Im Bereich ML-Systeme untersucht er die Angriffsvektoren in nationalen und internationalen Forschungsgruppen wie DataChainSec (gemeinsam mit dem KIT) und dem MIT CAMS (US).

Hintertüren in neuronalen Netzen sind in jüngster Zeit Gegenstand der Diskussionen einer weltweiten Gemeinschaft von Sicherheitsforschern. Wissenschaftliche Veröffentlichungen haben konkrete Beschreibungen eines Angriffes auf KI bereits seit 2018 beschrieben. Mit steigender Popularität von KI-Anwendungen und deren vielschichtigen Ausprägung hat sich das Thema Hintertüren stetig weiterentwickelt. Standen in den Anfängen hauptsächlich Systeme zur Bilderkennung im Fokus, sind es jüngst Sprachmodelle und insbesondere deren Fähigkeit zum Generieren von Sourcecode, die das Interesse der Cybersicherheitsforscher weckt.

Insbesondere große Sprachmodelle bieten durch ihre breite Anwenderbasis für Angreifer die Möglichkeit eines Supply-Chain-Angriffs. Ist das Modell erst einmal mit einer Hintertür versehen, lässt sich diese auf allen Systemen aktivieren, deren Anwendungen auf dem manipulierten LLM basieren. Damit wären alle Organisationen und Anwender von dieser Sicherheitslücke betroffen, die ein solches LLM einsetzen.

Um die potenziellen Risiken für Anwender und die KI-Industrie bewerten zu können, lohnt es sich, einen genaueren Blick auf das Angriffsszenario einer Hintertür in KI-Modelle zu werfen. Zunächst gilt jedoch: Damit dieser Angriff prinzipiell möglich ist, müssen Angreifer die Möglichkeit haben, das KI-Modell während der Trainingsphase zu manipulieren. Das schränkt die möglichen Angriffsszenarien ein. Bei geschlossenen KI-Modellen muss der Angriff also durch Personen oder Institutionen erfolgen, die Zugriff auf Trainingsdaten oder den Trainingsprozess haben. Der Kreis der Angreifer beschränkt sich hier auf Mitarbeiter oder in der Lieferkette auf Lieferanten, die Dienstleistungen im Rahmen des Trainings übernehmen.

Offene KI-Modelle

Zudem sind KI-Modelle betroffen, die in einem offenen oder kollaborativen Prozess entwickelt werden, beispielsweise im Rahmen von Open-Source-Projekten oder Federated Learning. Angreifer injizieren das schadhafte Verhalten durch die Anwendung verschiedener Angriffstechniken ins Modell. Dazu gehört das Data Poisoning, um die Klassifikationen für Bilder und Texte zu manipulieren. So können Angreifer im Rahmen eines Supervised-Learning-Prozesses die Ergebnisse des Modells durch wiederholte Trainingszyklen in die von ihnen gewünschten Richtungen der Manipulation lenken. In der späteren Anwendung des trainierten Modells aktivieren Eingabedaten, die einen definierten Schlüsselmarker enthalten, die Hintertür. Der nur den Angreifern bekannte Marker zwingt das neuronale Netz dazu, Schadelemente in die ausgegebenen Daten zu integrieren. Die aktuelle wissenschaftliche Forschung belegt, dass die Hintertüren in den manipulierten Modellen persistent sind. Ist eine Backdoor einmal im Modell eingepflanzt, bleibt sie auch nach weiteren Trainingszyklen bestehen und lässt sich in späteren Versionen eines Modells aktivieren.

Zur Diskussion des faktischen Risikos dieser Angriffstechnik auf KI-Modelle lohnt es sich, sie mit der Brille der klassischen IT-Sicherheit zu betrachten. Da der Angriff prinzipiell über die Lieferkette erfolgen muss, gibt es Grundregeln, die das Risiko minimieren. Die beste Gegenmaßnahme basiert auf Transparenz. Bei klassischer Softwareentwicklung zeigt sich der Unterschied beim Prüfen der IT-Sicherheit von Open-Source- gegenüber proprietärer Software. Zwar zeigt die Praxis, dass Angreifer bei quelloffenen Projekten leichter Schadcode committen können, wenn die Projekt-Inhaber beim Qualitätsmanagement nachlässig sind, aber alle Anwender können die Sourcen einsehen und auf Schadcode überprüfen. Da diese Prüfoption bei proprietärer Software nicht möglich ist, müssen Anwender dem Hersteller vertrauen, dass dieser ein Interesse hat, ein Produkt ohne Schadcode auszuliefern. Spektakuläre Cyberangriffe aus der jüngeren Vergangenheit haben gezielt Anbieter von proprietärer Software kompromittiert, wobei die Angreifer – kriminell oder staatlich motiviert – hier auch Software-Repositories und Software-Source manipulierten, um Angriffe über die Software-Lieferketten ausführen zu können.

Code sichten zur Sicherheit

Sowohl bei Open- als auch bei Closed-Source-Projekten treten also Probleme auf, wenn das Qualitätsmanagement im Software-Building-Prozess versagt. Werden Codereviews nicht oder nur mangelhaft durchgeführt, können Angreifer Schadcode per Commit einschleusen, der anschließend über Downloads und Updates in der Lieferkette an Anwender verteilt wird. Die gängigen Gegenmaßnahmen sind, die Absicherung der Codequalität per auditierte Review-Verfahren und das Prüfen der Vertrauenswürdigkeit von Quellen über Zertifikate. Zusätzliche Maßnahmen scannen Softwareprozesse, überwachen sie im Betrieb und versuchen, schadhafte Muster im Verhalten zu erkennen.

Sichere KI für die Softwareentwicklung

Am 6. und 7. März findet die von iX und dpunkt.verlag ausgerichtete Frühjahrsausgabe der heise devSec statt, die sich an zwei Tagen brisanten Themen rund um sichere Softwareentwicklung widmet.

Nachdem es am ersten Konferenztag um die Absicherung der Software Supply Chain geht, steht am 7. März der sichere Einsatz von KI in der Softwareentwicklung im Fokus: Wie sicher ist Coding mit KI-Assistenten, welche Chancen und Risiken gibt es und welche rechtlichen Aspekte gilt es zu beachten? Der Autor dieser Analyse hält dort den Vortrag "Data Poisoning – den vergifteten Apfel erkennen und Risiken für KI-Anwendungen minimieren".

Bis zum 30. Januar sind Tickets zum Frühbucherpreis von 449 Euro für beide Tage oder 299 Euro für einen Konferenztag erhältlich.

Für KI-Anwendungen übertragen bedeutet dies: Ein vertrauensvolles Modell ist durch das Offenlegen der Trainingsdaten und -methoden nachvollziehbar. Ein solches Modell repräsentiert den Goldstandard für sichere KI, die frei von Hintertüren ist – ähnlich wie ein Sicherheitsaudit auf Open-Source-Software. Wer dagegen einfach ungeprüfte Modelle aus Repositories wie Huggingface verwendet, sollte immer beachten, dass die Modelle potenziell Hintertüren enthalten können.

Eine Frage des Vertrauens

Besonders schwierig ist die Situation mit geschlossenen Modellen wie LLMs oder Bildgeneratoren. Sicherheit basiert hier auf Vertrauen und Hoffnung: Vertrauen in die Qualitätssicherung der Anbieter, um Data-Poisoning-Angriffe aus Trainingsprozesse zu unterbinden oder frühzeitig zu erkennen, und Hoffnung, dass insbesondere staatliche Akteure keine Begehrlichkeit haben, KI-Hintertüren bei Modellanbietern über nachrichtendienstliche Mittel und Möglichkeiten zu implementieren. KI ohne Hintertüren benötigt ein Goldstandard für Sicherheit, Transparenz und Vertrauen.

(rme)