open-flaw/cve-2025-49844Exploit de prueba de concepto para CVE-2025-49844 dirigido a una vulnerabilidad de heap en Redis, con análisis de fallos asistido por GDB e intentos de fuzzing para lograr ejecución de código.
PoC de Revshell hecho por IA
Completación no probada del PoC de Redishell hecho por IA.
PoC original:
https://github.com/raminfp/redis_exploit/blob/main/exploit_poc.py
Pieza coreana:
https://github.com/dwisiswant0/CVE-2025-49844/blob/master/CVE-2025-49844.lua
Luego seguimos adelante y conectamos GDB: logramos obtener la dirección base y descubrir algunas cosas más, pero sobre todo, parece que esto no es una simple vulnerabilidad de Heap. No importa lo que intentáramos, era imposible conseguir ejecución de código. ¿Crash? Sí. ¿Comandos? No.
Ya no somos firmes en reversing, así que no podemos estar seguros, pero por todo lo que encontramos durante horas con la ayuda de algunos de los modelos de IA más potentes, no es posible obtener ejecución de código a través de esta vulnerabilidad (o es una de cada mil intentos, pero eso es pura especulación).
A través de numerosos intentos, siempre terminábamos aquí como mucho:
Script attempted to access nonexistent global variable 'print' script: 67dfac1cecac4f99df897c7a0713f1d6fcef69a4, on @user_script:21.
Curioso por ver el PoC real con ejecución de código.
LEE BIEN, POR FAVOR: Dijimos, POR TODO LO QUE SABEMOS / HEMOS VISTO HASTA AHORA. Eso no es una declaración absoluta, puede haber un truco o regalo que no hayamos considerado, hay BinExers mucho mejores por ahí.
Ten en cuenta que el servidor Redis se mantuvo estable: lo sacamos de docker para las pruebas. Puedes provocar el crash disparando el exploit un par de miles de veces y aún no hemos intentado combinar este método de fuerza bruta con intentos de ejecución de código, puede que sea la solución.
Como ves, el PoC original parece tener los mismos problemas, afirma ser "simplificado" aunque no queda del todo claro cuál se supone que es el resultado.
Nada aún...
$ while redis-cli -h localhost -p 6380 --eval korean.lua; do printf '.'; done
Misteriosamente, en las notas del parche de Redis, aparece un CVE completamente diferente, también supuestamente un exploit binario, pero mucho más simple, un desbordamiento de búfer basado en pila con supuesto RCE:
XACKDEL puede provocar desbordamiento de pila y potencial RCEhttps://github.com/redis/redis/compare/8.2.2...8.2
Encontramos incluso menos información sobre esto. Ya es un desafío encontrar una versión sin backport sin compilar uno mismo, pero quizás sea la ruta que tendremos que tomar.
Todos estos POTENCIALES - tengo potencial. Ahora tengo 2 potenciales.
El 62507 es el camino a seguir... aún no tengo RCE, pero se ve fácil y prometedor...
¿Entonces CVE-2025-49844 era solo un engaño? El Puzzle Coreano aún no ha producido un crash, pero produce una salida completamente diferente contra nuestro 8.2.2 auto-compilado. Para admitirlo, incluso yo caí en pensar "sí, crash, más que plausible, probablemente fácil..." y simplemente asumí que la parte del crash de CVE-2025-49844 funcionaría. Pero nunca lo hizo. Perdón por decirlo mal antes, pero ahora está aclarado, con suerte. CVE-2025-49844 no crashea, CVE-2025-62507 sí crashea.
.(error) ERR user_script:16: Script attempted to access nonexistent global variable 'newproxy' script: 859491190bfb66357ec83aee16eb0554967c9c38, on @user_script:16.
¿Te suena familiar? No sé qué hicieron allí... o si nadie lo revisó aparte de mí? El mundo se ha vuelto un lugar bastante extraño últimamente.