-1.png?w=1024)
Das Auffinden einer schwerwiegenden Softwareschwachstelle kann für Forschende 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 funktionierenden Exploit zur Remotecodeausführung erstellt.
Die Forschenden veröffentlichten authentifizierte Proof-of-Concept-Exploits für Redis 6.2.22, 7.4.9, 8.6.4 und 8.8.0; für beide Angriffspfade war der Zugriff auf den Befehl RESTORE erforderlich. Redis veröffentlichte am 23. Juli sieben Sicherheitsupdates, um die zugrunde liegenden Schwachstellen zur Speicherkorruption zu beheben. Die Ergebnisse zeigen, wie schnell KI-Agenten von der Überprüfung des Quellcodes zur Erstellung nutzbarer Exploit-Ketten übergehen können. Verteidigern könnte weniger Zeit bleiben, Patches zu überprüfen, risikoreiche Befehle einzuschränken und die Angriffsfläche zu reduzieren, sobald technische Details öffentlich werden.
So funktionierten die Redis-Exploit-Ketten
The Hacker News berichtete, dass der erste Angriffspfad eine Schwachstelle 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 zeigten, woraufhin Redis dasselbe Speicherobjekt zweimal freigab, wenn beide Consumer entfernt wurden.
Der zweite Angriffspfad betraf den RedisBloom-TDigest-Loader. Der Loader reservierte Speicher anhand eines serialisierten Werts, vertraute jedoch auf ein separates vom Angreifer kontrolliertes Kapazitätsfeld , um festzulegen, wie viele Daten geladen werden sollten, und erzeugte dadurch einen Schreibzugriff außerhalb der Grenzen.
Die veröffentlichten Skripte waren darauf ausgelegt, die daraus resultierenden Speicherfehler in beliebige Lese- und Schreibzugriffe umzuwandeln, Adressen von Redis und Systembibliotheken offenzulegen und schließlich Systembefehle auszuführen. Für einige Ketten war außerdem die Berechtigung erforderlich, EVAL, XGROUP oder das RedisBloom-Modul zu verwenden.
Redis veröffentlichte behobene 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 die Redis-Versionshinweise vom 23. Juli noch die öffentlichen Proof-of-Concept-Repositorien berichteten über eine Ausnutzung in freier Wildbahn (Stand: 24. Juli).
Die Grenzen der 27-Minuten-Angabe
CyberPress berichtete, der Kimi-K3-Agent habe den Redis-Quellcode geklont, ausgewählte Funktionen per Fuzzing getestet und den GDB-Debugger verwendet, um Abstürze mit begrenzter menschlicher Anleitung zu untersuchen.
Die Publikation führte die Geschwindigkeit der Recherche auf Kimi K3s Mixture-of-Experts-Architektur, das große Kontextfenster und die Fähigkeit zurück, mit Entwicklungstools zu arbeiten. Moonshot AI, das in China ansässige Unternehmen hinter dem Modell, entwickelte Kimi K3 für allgemeine und groß angelegte agentische Workloads.
Die angegebene Entwicklungszeit von 27 Minuten für den Exploit sowie die separate Behauptung, Kimi-K3-Agenten hätten in etwa 90 Minuten 19 Redis-Zero-Days gefunden, stammen weiterhin aus Selbstauskünften. Redis bestätigte die zugrunde liegenden Schwachstellen und veröffentlichte Fehlerbehebungen, doch aus den öffentlichen Angaben ging nicht hervor, wie unabhängig die Agenten arbeiteten oder ob die behauptete Zahl der Entdeckungen validiert wurde.
Stingrai warnte außerdem davor, die aktuellen Ergebnisse mit fünf im Mai behobenen Redis-Schwachstellen zusammenzuführen. Redis schrieb diese früheren Schwachstellen namentlich genannten menschlichen Forschenden 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 genaue Version und den in der Produktion eingesetzten Zweig überprüfen. Redis 6.2.22 und 7.4.9 waren selbst im Mai veröffentlichte Sicherheitsupdates – ein Beleg dafür, dass ein System nicht unbedingt vor neu offengelegten Schwachstellen geschützt ist, nur weil es kürzlich gepatcht wurde .
Administratoren, die nicht sofort aktualisieren können, sollten Konten, die den Zugriff nicht benötigen, die RESTORE-Berechtigung entziehen, authentifizierte Nutzer prüfen, den Netzwerkzugriff aus nicht vertrauenswürdigen Quellen blockieren und kontrollieren, ob RedisBloom installiert ist.
Die Ergebnisse lenken außerdem mehr Aufmerksamkeit auf Moonshot AI, eines der chinesischen Unternehmen, die darauf drängen, leistungsfähige Agentensysteme günstiger und breiter verfügbar zu machen. 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 um Unternehmens-KI neu gestalten könnte.