zbyszkok/cve-2025-49844-redishell-ai-made-revshellVersion non testée de la complétion du PoC Redishell réalisée par l'IA
PoC de revshell généré par IA
Complétion non testée du PoC Redishell fait par l'IA.
PoC d'origine :
https://github.com/raminfp/redis_exploit/blob/main/exploit_poc.py
Pièce coréenne :
https://github.com/dwisiswant0/CVE-2025-49844/blob/master/CVE-2025-49844.lua
Nous avons ensuite utilisé GDB - nous avons réussi à obtenir l'adresse de base et à découvrir quelques autres choses, mais surtout, il semble que ce ne soit pas une simple vulnérabilité de heap. Quoi que nous ayons essayé, il était impossible d'obtenir une exécution de code. Crash ? Oui. Commandes ? Non.
Nous ne sommes plus très à l'aise en rétro-ingénierie, donc nous ne pouvons pas en être sûrs, mais d'après tout ce que nous avons découvert pendant des heures avec l'aide de certains des modèles d'IA les plus puissants, il n'est pas possible d'obtenir une exécution de code via cette vulnérabilité (ou alors c'est une tentative sur mille, mais ce n'est que pure spéculation).
À force de nombreuses tentatives, nous aboutissions au mieux à ceci :
Script attempted to access nonexistent global variable 'print' script: 67dfac1cecac4f99df897c7a0713f1d6fcef69a4, on @user_script:21.
Curieux de voir le vrai PoC avec exécution de code.
LISEZ BIEN S'IL VOUS PLAÎT : Nous avons dit, D'APRÈS TOUT CE QUE NOUS SAVONS / AVONS VU JUSQU'ICI. Ce n'est pas une affirmation absolue, il se peut qu'il y ait un truc ou une astuce que nous n'avons pas envisagés, et il y a bien de meilleurs experts en exploitation binaire que nous.
À noter que le serveur Redis est resté stable - nous l'avons sorti de Docker pour les tests. Vous pouvez déclencher le crash en lançant l'exploit quelques milliers de fois et nous n'avons pas encore essayé de combiner cette méthode de force brute avec des tentatives d'exécution de code, c'est peut-être la solution.
Comme vous le voyez, le PoC d'origine semble souffrir des mêmes problèmes, il prétend être « simplifié » alors qu'on ne voit pas clairement ce que le résultat est censé être.
Toujours rien...
$ while redis-cli -h localhost -p 6380 --eval korean.lua; do printf '.'; done
Mystérieusement, dans les notes de mise à jour de Redis, un CVE complètement différent est listé - également supposément une exploitation binaire, mais beaucoup plus simple, un Buffer Overflow basé sur la pile avec une prétendue RCE :
XACKDEL pouvant mener à un débordement de pile et à une RCE potentielleNous avons trouvé encore moins d'informations à ce sujet. C'est déjà difficile de trouver une version non rétroportée sans la compiler soi-même, mais c'est peut-être la voie qu'il faudra emprunter.
Tous ces POTENTIELS - j'ai du potentiel. Maintenant j'ai 2 potentiels.
62507 est la voie à suivre... pas encore de RCE, mais ça a l'air simple et prometteur...
Alors, CVE-2025-49844 n'était-il qu'une ruse ? Le puzzle coréen n'a toujours pas produit de crash - mais il produit une sortie complètement différente contre notre 8.2.2 compilé par nos soins. Je dois admettre que même moi, j'ai fini par penser « ouais, un crash, plus que plausible, probablement facile... » et j'ai simplement supposé que la partie crash de CVE-2025-49844 fonctionnerait. Mais ça n'a jamais été le cas. Désolé d'avoir mal dit les choses plus tôt, mais c'est clarifié maintenant, espérons-le. CVE-2025-49844 ne crashe pas, CVE-2025-62507 crashe.
.(error) ERR user_script:16: Script attempted to access nonexistent global variable 'newproxy' script: 859491190bfb66357ec83aee16eb0554967c9c38, on @user_script:16.
Ça vous semble familier ? Je ne sais pas ce qu'ils ont fait là... ou si personne d'autre que moi n'a vérifié ? Le monde est devenu un endroit plutôt étrange ces derniers temps.