zbyszkok/cve-2025-49844-redishell-ai-made-revshellFinalización no probada del PoC de Redishell hecha por IA
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 continuamos y conectamos GDB: logramos obtener la dirección base y descubrir algunas cosas más, pero sobre todo, parece que esta no es una vulnerabilidad de Heap simple. Sin importar lo que intentamos, fue imposible obtener ejecución de código. ¿Crash? Sí. ¿Comandos? No.
Ya no somos firmes en ingeniería inversa, 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 uno de cada mil intentos, pero eso es pura especulación).
A través de numerosos intentos, siempre terminábamos en algún lugar como esto en el mejor de los casos:
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.
LEAN BIEN POR FAVOR: Dijimos, DE TODO LO QUE SABEMOS / HEMOS VISTO HASTA AHORA. No es una declaración absoluta, puede haber un truco o algo que no hayamos considerado, hay expertos en BinEx mucho mejores por ahí.
Nota: Redis Server se mantuvo estable; lo sacamos de Docker para pruebas. Puedes provocar el crash ejecutando 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, podría ser la solución.
Como ves, el PoC original parece tener los mismos problemas, afirma ser 'simplificado' mientras que no está del todo claro cuál debería ser 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, se lista un CVE completamente diferente, también supuestamente un exploit binario, pero mucho más simple, un desbordamiento de búfer basado en pila con supuesta RCE:
XACKDEL puede provocar desbordamiento de pila y potencial RCEEncontramos aún menos información sobre esto. Ya es un desafío encontrar una versión no retroportada sin autocompilación, pero quizás esa sea la ruta que tengamos que tomar.
Todos estos POTENCIALES: yo tengo potencial. Ahora tengo 2 potenciales.
62507 es el camino a seguir... aún no tengo RCE, pero parece fácil y prometedor...
Entonces, ¿CVE-2025-49844 fue solo un engaño? El rompecabezas coreano aún no ha producido un crash, pero produce una salida completamente diferente contra nuestro 8.2.2 compilado por nosotros mismos. Teniendo que 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. Disculpen 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 resulta familiar? No sé qué hicieron allí... o si nadie revisó aparte de mí? El mundo se ha vuelto un lugar bastante extraño últimamente.