bttea/cve-2024-4577-rce-pocCVE-2024-4577 PoC de RCE
Al implementar PHP, el equipo no notó la función Best-Fit de conversión de codificación dentro del sistema operativo Windows. Este descuido permite a atacantes no autenticados eludir la protección anterior de CVE-2012-1823 mediante secuencias de caracteres específicas. Se puede ejecutar código arbitrario en servidores PHP remotos a través del ataque de inyección de argumentos.
Este PoC es solo con fines de aprendizaje e investigación. No lo uses para actividades ilegales; eres el único responsable de cualquier consecuencia legal.
Esta vulnerabilidad fue encontrada por Orange Tsai (@orange_8361) de DEVCORE (@d3vc0r3). Asegúrate de seguir su excelente investigación, nuestro papel fue solo recrear y desarrollar el exploit para este problema.
¿Por qué es necesario reescribir el script de exploit cuando ya hay muchos PoCs públicos disponibles en línea?
Dado que muchos PoCs públicos se basan en el mismo exploit original, muchos proveedores han usado estos PoCs como referencia y han bloqueado ciertas palabras clave para evitar su explotación. Sin embargo, a menudo pasan por alto el bloqueo de todos los vectores de exploit potenciales. Para abordar esto, el script incluye un mecanismo simple para generar parámetros aleatorios, así como diferentes métodos de explotación LFI a RCE, para aumentar la tasa de éxito de la inyección PHP CGI que lleva a RCE.
Durante una prueba en la que intentaba reproducir una vulnerabilidad ambiental, descubrí que mi PoC desencadenaba constantemente un error HTTP 500, independientemente de los ajustes. Como estaba trabajando en un entorno vulnerable, comencé a investigar la causa del error. Entonces, recordé un artículo de Devcore que mencionaba que, en ciertos escenarios de exploit, el servidor devuelve un error HTTP 500, aunque el exploit RCE en realidad tuvo éxito. Con esto en mente, decidí probar si podía ejecutar calc.exe localmente, y para mi sorpresa, funcionó: ¡era un RCE ciego!
Sin embargo, cuando revisé el registro de errores de Apache, encontré un error que hacía referencia a allow_url_include, a pesar de que el ataque se había ejecutado con éxito (y todavía no comprendo completamente la causa raíz; si tienes información, contáctame). Esto me llevó a crear un exploit que incluye una opción para probar también el RCE ciego 😊.
Si tu objetivo es una versión del sistema operativo anterior a Windows 7, aún puedes escalar a un RCE visible o una reverse shell mediante otros métodos. Sin embargo, estas técnicas están fuera del alcance de este artículo, por lo que no entraremos en detalle. Como probador de penetración o especialista en red team, deberías poder encontrar soluciones alternativas con bastante rapidez, lo que puede ser un proceso interesante 😉.
Actualizado el 15 de noviembre de 2024
Debido a requisitos laborales, he seguido mejorando el script para que sea lo más compatible posible con todos los entornos y maximice las posibilidades de lograr RCE. Este esfuerzo fue impulsado por el hecho de que algunos objetivos no podían ejecutar PHP con éxito usando muchos PoCs públicos. Finalmente, resolví este problema de manera inesperada, logrando superar casi todos los casos donde ocurría el error 500 y mostrando con éxito los resultados de la ejecución de PHP. Como resultado, el RCE ciego ya no parecía tan crítico. 😧
Condiciones de explotación
Debes instalar las dependencias:
$ python3 -m pip install requests Ejecuta el script directamente para obtener instrucciones de uso. Puedes ejecutar el siguiente comando para verificar si el objetivo es vulnerable.
$ python3 CVE-2024-4577.py <objetivo> <shell php>
Si el exploit existe en el objetivo, puedes guardar los resultados de la ejecución de PHP localmente, lo cual es útil para quienes necesitan ver phpinfo.
$ python3 CVE-2024-4577.py <objetivo> "phpinfo()" --save info.html
Cuando el objetivo es vulnerable a RCE ciego, el script intentará escuchar en un puerto local y provocará que el servidor objetivo ejecute PHP, enviando una solicitud para verificar la existencia del exploit. Cuando se recibe la solicitud, indica que el servidor objetivo ha ejecutado el comando con éxito.
