Kommentar: KI-FOMO frisst Sicherheit
KI wird überall eingeführt – neuen Sicherheitsrisiken zum Trotz. Aber wenigstens all die alten Arten von Lücken könnte man vermeiden, findet Sylvester Tremmel.
(Bild: Bild erstellt mit KI in Bing Designer durch heise online / dmk)
KI-Systeme auf Basis großer Sprachmodelle bringen neue Arten von Sicherheitslücken und Risiken mit sich. Wie genau man Prompt Injections, Jailbreaks oder auch Model Poisoning am besten begegnet, ist Gegenstand aktueller Forschung. Doch so wichtig die Diskussion von neuen, vergleichsweise wenig erforschten Sicherheitsproblemen ist: Sie überdeckt leicht, dass KI-Systeme immer auch klassische Software enthalten – in der naturgemäß klassische Sicherheitslücken stecken.
Im gehypten KI-Agent OpenClaw wurden in den vergangenen Wochen knapp 380 450 Sicherheitslücken gefunden, viele davon schwerwiegend. Das sind großteils keine neuartigen und kreativen Angriffe auf die KI-Komponente von OpenClaw (reine Prompt Injections sind sogar explizit „out of scope“ in OpenClaws Sicherheitsmeldungen). Stattdessen dokumentieren die Warnungen klassische Probleme wie unzureichende Autorisierungen, fehlenden Replay-Schutz, nicht korrekt beendete Sessions und so weiter und so fort. Die geradezu absurd schnell gewachsene Zahl an Sicherheitslücken ist wohl keine Besonderheit von OpenClaw. Denn besonders ist das Projekt eher in der Hinsicht, dass es diese Lücken so säuberlich dokumentiert. Viele andere KI-Projekte dürfen kaum besser aufgestellt sein, sondern lediglich ihre Lücken weniger gründlich erfassen – wenn überhaupt.
Um nur ein Beispiel zu nennen: Forscher der „Security Research Labs“ entdeckten Mitte März eine gravierende Lücke im Chatbot einer großen, nicht näher benannten Organisation: Nutzerchats, Administrator-Zugangsdaten, Millionen von Mitarbeiteraccounts, all das stand den Forschern offen. Zugrunde lag aber keine gewiefte Attacke auf die KI des Chatbots, sondern ein vollkommen ungeschütztes und äußerst gesprächiges Debug-Interface. „Wir brauchen euren KI-Agenten nicht zu hacken, um euren KI-Agenten zu hacken“, titelten die Forscher mit zutreffendem Sarkasmus.
Auf die Idee, nach Schwachstellen in KI-Assistenten zu suchen, kamen sie übrigens, nachdem ein KI-Assistent der Beratungsfirma McKinsey innerhalb von Stunden gehackt worden war. Ursächlich war auch hier keine Prompt Injection, sondern eine SQL-Injection. Klingt ähnlich, aber SQL-Injections sind keine schwierig anzugehenden KI-Probleme, sondern geradezu klassische Sicherheitsprobleme mit ebenso wohlbekannten wie zuverlässigen Lösungen.
Es gibt zahlreiche ähnliche Beispiele; im aktuellen Hype werden KI-Systeme mit halsbrecherischer Geschwindigkeit entwickelt, erweitert und mit produktiven Daten gefüllt. In einer weitgehend substanzlosen Fear of missing out (FOMO) überbieten sich IT-nahe wie -ferne Unternehmen darin, Geschäftsprozesse und produktive Systeme mit KI auszurüsten, um sich damit brüsten zu können. Wer so gehetzt entwickelt, häuft fast zwangsläufig schlechten Code, technische Schulden und eben auch Sicherheitslücken an.
Vermutlich lässt sich eine solche Entwicklungsgeschwindigkeit ohne Vibe-Coding oft nicht realisieren, aber auch wenn das möglich wäre: Wer einzig und alleine möglichst schnell zu einem passabel funktionierenden – und vor allem präsentablen – System kommen will, wird schlechten Code, technische Schulden und eben auch Sicherheitslücken anhäufen, ganz gleich wie der Entwicklungsprozess aussieht.
Sich in so einer Situation um die Resistenz gegen Prompt Injections und dergleichen zu kümmern, wirkt ein wenig wie die Suche nach einer neuen, besonders sicheren Haustür mit zwei Türstehern davor, während die Terrassentür und sämtliche Fenster offen stehen: Kein schlechter Schritt, aber als alleiniger Schritt ziemlich sinnlos.
Cyberkriminelle nehmen bereits Angriffe auf KI-Komponenten in ihr Repertoire auf, aber noch sieht man eher simple und vergleichsweise wenig solcher Attacken. Warum sollten Angreifer sich auch mit neuartigen, oft probabilistischen Sicherheitslücken beschäftigen, wenn die offene Debug-Schnittstelle des Systems alles Gewünschte auf dem Silbertablett serviert?
Ironischerweise sind KIs inzwischen offenbar ziemlich gut darin, bei der Suche nach Sicherheitslücken zu helfen. Wer unbedingt mit brachialer, KI-getriebener Geschwindigkeit entwickeln will, könnte den Code also zumindest auch KI-getrieben auf Sicherheitslücken prüfen (und zwar – wilde Idee – bevor man ihn produktiv nutzt). Aber dafür müsste das Thema Sicherheit einen Stellenwert bekommen, den es bei vielen Akteuren im Moment nicht hat.
Allen anderen, deren Entscheidungsfindung noch nicht FOMO-zerfressen ist, kann man nur raten, auch bei der Entwicklung und Einführung von KI die Umsetzung bewährter Security-Praktiken nicht schleifen zu lassen. Forcieren sollte man sie stattdessen, um wenigstens bekannt- und vermeidbare Lücken auch tatsächlich zu vermeiden. Wenn dadurch die neue Produktversion mit KI ein- oder zwei Monate später erscheint, ist das ein kleiner Preis. Manch KI-müdem Kunden könnte das sogar ganz recht sein. (syt)
