-1.png?w=1024)
Das Auffinden einer schwerwiegenden Softwareschwachstelle kann für Sicherheitsforscher Tage oder Wochen dauern. Ein Sicherheitsteam, das Moonshot AIs Kimi K3 einsetzte, erklärte, einer seiner Agenten habe eine Redis-Schwachstelle gefunden und in nur 27 Minuten einen funktionsfähigen Exploit zur Remotecodeausführung entwickelt.
Die Forscher veröffentlichten authentifizierte Proof-of-Concept-Exploits, die auf Redis 6.2.22, 7.4.9, 8.6.4 und 8.8.0 abzielten. Für beide Angriffswege war der Zugriff auf den RESTORE-Befehl erforderlich. Redis veröffentlichte am 23. Juli sieben Sicherheitsupdates, um die zugrunde liegenden Speicherbeschädigungsfehler zu beheben. Die Ergebnisse zeigen, wie schnell KI-Agenten von der Überprüfung des Quellcodes zur Entwicklung nutzbarer Exploit-Ketten übergehen können. Verteidigern könnte weniger Zeit bleiben, Patches zu überprüfen, risikoreiche Befehle zu beschränken und die Angriffsfläche zu verringern, sobald technische Details öffentlich werden.
So funktionierten die Redis-Exploit-Ketten
The Hacker News berichtete, dass der erste Angriffsweg einen Fehler bei der gemeinsamen Besitzverwaltung in Redis Streams betraf. Ein beschädigtes Datenbankobjekt konnte dazu führen, dass zwei Consumer auf denselben Datensatz eines ausstehenden Eintrags verwiesen. Wurden beide Consumer entfernt, gab Redis dasselbe Speicherobjekt zweimal frei.
Der zweite Angriffsweg betraf den TDigest-Loader von RedisBloom. Der Loader reservierte Speicher anhand eines serialisierten Werts, vertraute beim Festlegen der zu ladenden Datenmenge jedoch auf ein separates vom Angreifer kontrolliertes Kapazitätsfeld und verursachte dadurch einen Schreibzugriff außerhalb des zulässigen Speicherbereichs.
Die veröffentlichten Skripte waren darauf ausgelegt, die daraus resultierenden Speicherfehler in beliebige Lese- und Schreibzugriffe umzuwandeln, Adressen von Redis und Systembibliotheken auszulesen und schließlich Systembefehle auszuführen. Für einige Ketten waren außerdem Berechtigungen zur Verwendung von EVAL, XGROUP oder des RedisBloom-Moduls erforderlich.
Redis veröffentlichte korrigierte Versionen für alle unterstützten Zweige, darunter 6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5, 8.6.5 und 8.8.1. Weder in den Versionshinweisen von Redis vom 23. Juli noch in den öffentlichen Proof-of-Concept-Repositories wurde eine Ausnutzung in freier Wildbahn bis zum 24. Juli gemeldet.
Die Grenzen der Behauptung von 27 Minuten
CyberPress berichtete, dass der Kimi-K3-Agent den Redis-Quellcode klonte, ausgewählte Funktionen einem Fuzzing unterzog und den GDB-Debugger nutzte, um Abstürze mit begrenzter menschlicher Anleitung zu untersuchen.
Die Veröffentlichung führte die Geschwindigkeit der Recherche auf die Mixture-of-Experts-Architektur von Kimi K3, das große Kontextfenster und die Fähigkeit zurück, mit Entwicklungswerkzeugen zu arbeiten. Moonshot AI, das in China ansässige Unternehmen hinter dem Modell, entwickelte Kimi K3 für allgemeine und groß angelegte agentische Aufgaben.
Die angegebene Zeit von 27 Minuten für die Exploit-Entwicklung sowie die separate Behauptung, Kimi-K3-Agenten hätten in etwa 90 Minuten 19 Redis-Zero-Days gefunden, sind weiterhin Selbstauskünfte. Redis bestätigte die zugrunde liegenden Schwachstellen und veröffentlichte Korrekturen, doch aus den öffentlichen Stellungnahmen des Unternehmens geht nicht hervor, wie unabhängig die Agenten arbeiteten oder ob die angegebene Zahl der Entdeckungen überprüft wurde.
Stingrai warnte außerdem davor, die neuesten Ergebnisse mit fünf im Mai gepatchten Redis-Schwachstellen zusammenzufassen. Redis schrieb diese früheren Schwachstellen namentlich genannten menschlichen Forschern zu, womit die Offenlegung zu Kimi K3 einen verwandten, aber eigenständigen Fall KI-gestützter Sicherheitsforschung darstellt.
Was Sicherheitsteams jetzt überprüfen sollten
Organisationen, die Redis selbst verwalten, sollten die exakt in der Produktion eingesetzte Version und den entsprechenden Zweig überprüfen. Redis 6.2.22 und 7.4.9 waren selbst im Mai veröffentlichte Sicherheitsupdates – ein Hinweis darauf, dass ein System nicht zwangsläufig vor neu offengelegten Schwachstellen geschützt ist, nur weil es kürzlich gepatcht wurde.
Administratoren, die nicht sofort aktualisieren können, sollten den RESTORE-Zugriff für Konten entziehen, die ihn nicht benötigen, authentifizierte Nutzer überprüfen, nicht vertrauenswürdigen Netzwerkzugriff blockieren und kontrollieren, ob RedisBloom installiert ist.
Die Ergebnisse lenken zudem mehr Aufmerksamkeit auf Moonshot AI, eines der chinesischen Unternehmen, die leistungsfähige Agentensysteme günstiger und breiter verfügbar machen wollen. Die Leistung von Kimi K3 zeigt, wie dieser Wettbewerb nicht nur die Einführung von KI in Unternehmen, sondern auch die Geschwindigkeit der Schwachstellenforschung und Exploit-Entwicklung beeinflussen könnte.
Mehr lesen: Wie Moonshot AIs Kimi K3 den Wettbewerb im Bereich Unternehmens-KI neu gestalten könnte.