open-flaw/cve-2025-49844Exploit de preuve de concept pour CVE-2025-49844 ciblant une vulnérabilité de tas Redis, avec analyse de crash assistée par GDB et tentatives de fuzzing pour parvenir à une exécution de code.
PoC de Revshell fabriqué par IA
Complétion non testée du PoC Redishell fabriqué par IA.
PoC original :
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 branché 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 tas. Quoi que nous ayons essayé, il était impossible d'obtenir une exécution de code. Un crash ? Oui. Des commandes ? Non.
Nous ne sommes plus fermes en rétro-ingénierie, donc nous ne pouvons pas être sûrs, mais d'après tout ce que nous avons trouvé 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 bien c'est une chance sur mille, mais ce n'est que pure spéculation).
À travers de nombreuses tentatives, nous atterrissions toujours au mieux ici :
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 SVP : Nous avons dit, D'APRÈS TOUT CE QUE NOUS SAVONS / AVONS VU JUSQU'À PRÉSENT. Ce n'est pas une déclaration absolue, il pourrait y avoir une astuce ou un piège que nous n'avons pas envisagé, il y a bien meilleurs experts en exploitation binaire que nous.
Notez que le serveur Redis restait 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, cela pourrait être la solution.
Comme vous le voyez, le PoC original semble souffrir des mêmes problèmes, il prétend être « simplifié » alors que le résultat attendu n'est pas totalement clair.
Rien encore...
$ 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 censé être une exploitation binaire, mais beaucoup plus simple, un buffer overflow basé sur la pile avec une RCE supposée :
XACKDEL pouvant mener à un stack overflow et une RCE potentiellehttps://github.com/redis/redis/compare/8.2.2...8.2
Nous avons trouvé encore moins d'informations là-dessus. C'est déjà un défi de trouver une version non backportée sans auto-compilation, mais c'est peut-être la voie que nous devrons 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 facile et prometteur...
Alors, est-ce que CVE-2025-49844 n'était 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 version 8.2.2 auto-compilée. Je dois admettre que même moi, j'ai pensé « 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 dit le contraire avant, 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 ? JSP ce qu'ils ont fait là... ou si personne n'a vérifié à part moi ? Le monde est devenu un endroit plutôt étrange ces derniers temps.