zbyszkok/cve-2025-49844-redishell-ai-made-revshellUngetestete Vervollständigung des von KI erstellten Redishell-PoC
Von KI erstellter Revshell PoC
Ungetestete Vervollständigung des Redishell PoC, erstellt von KI.
Original PoC:
https://github.com/raminfp/redis_exploit/blob/main/exploit_poc.py
Korean Piece:
https://github.com/dwisiswant0/CVE-2025-49844/blob/master/CVE-2025-49844.lua
Wir haben später GDB verwendet – wir haben die Basisadresse ermittelt und ein paar weitere Dinge herausgefunden, aber vor allem scheint es, dass dies keine einfache Heap-Schwachstelle ist. Egal was wir versuchten, es war unmöglich, Codeausführung zu erreichen. Absturz? Ja. Befehle? Nein.
Wir sind im Reversing nicht mehr sattelfest, daher können wir uns nicht sicher sein, aber nach allem, was wir über Stunden hinweg mit Hilfe einiger der stärksten KI-Modelle herausgefunden haben, ist es nicht möglich, durch diese Schwachstelle Codeausführung zu erreichen (oder es ist einer von tausend Versuchen, aber das ist reine Spekulation).
Durch zahlreiche Versuche landeten wir bestenfalls immer hier:
Script attempted to access nonexistent global variable 'print' script: 67dfac1cecac4f99df897c7a0713f1d6fcef69a4, on @user_script:21.
Gespannt, den echten PoC mit Codeausführung zu sehen.
BITTE RICHTIG LESEN: Wir sagten: VON ALLEM, WAS WIR BISHER WISSEN/GESEHEN HABEN. Das ist keine absolute Aussage, es mag einen Trick geben, den wir nicht bedacht haben, es gibt weitaus bessere BinExer da draußen.
Beachten Sie, dass der Redis-Server stabil blieb – wir haben ihn aus Docker für Tests herausgezogen. Man kann den Absturz auslösen, indem man den Exploit ein paar tausend Mal feuert, und wir haben noch nicht versucht, diese Brute-Force-Methode mit Versuchen der Codeausführung zu kombinieren; es könnte die Lösung sein.
Wie Sie sehen, scheint der originale PoC mit denselben Problemen zu kämpfen; er behauptet, 'vereinfacht' zu sein, während nicht ganz klar ist, was das Ergebnis sein soll.
Noch nichts...
$ while redis-cli -h localhost -p 6380 --eval korean.lua; do printf '.'; done
Mysteriöserweise wird in den Redis-Patch-Notes eine völlig andere CVE aufgeführt – ebenfalls angeblich ein Binärausbeutung, aber eine viel einfachere, ein stackbasierter Pufferüberlauf mit angeblicher RCE:
XACKDEL kann zu Stack-Überlauf und potenzieller RCE führenWir fanden noch weniger Informationen dazu. Es ist bereits eine Herausforderung, eine nicht zurückportierte Version ohne Selbstkompilierung zu finden, aber vielleicht müssen wir diesen Weg dann gehen.
All diese POTENTIALE - Ich habe Potential. Jetzt habe ich 2 Potentiale.
62507 ist der Weg... habe noch keine RCE, aber es sieht einfach und vielversprechend aus...
War CVE-2025-49844 also nur ein Trick? Das koreanische Puzzle hat immer noch keinen Absturz produziert – aber es erzeugt völlig andere Ausgaben gegen unser selbst kompiliertes 8.2.2. Ich muss zugeben, selbst ich bin in den Gedanken verfallen 'ja, Absturz, mehr als plausibel, wahrscheinlich einfach...' und habe einfach angenommen, dass der Absturzteil von CVE-2025-49844 funktionieren würde. Aber das tat er nie. Entschuldigung, dass ich es vorher falsch gesagt habe, aber jetzt ist es hoffentlich geklärt. CVE-2025-49844 stürzt nicht ab, CVE-2025-62507 stürzt ab.
.(error) ERR user_script:16: Script attempted to access nonexistent global variable 'newproxy' script: 859491190bfb66357ec83aee16eb0554967c9c38, on @user_script:16.
Sieht vertraut aus? Keine Ahnung, was sie da gemacht haben... oder ob niemand außer mir überprüft hat? Die Welt ist in letzter Zeit ein ziemlich seltsamer Ort geworden.