Ejecutar código remoto en Apache con PHP en modo CGI
El pasado 3 de Mayo ha salido a luz un serio bug, identificado con el CVE-2012-1823, que afecta a todas las instalaciones de PHP en modo CGI, que permite llamar directamente desde el la URL a los parámetros del motor PHP, lo que provoca que se pueda ejecutar código remoto en cualquier servidor con una instalación vulnerable.
Con estos parámetros se pueden hacer cosas bastante curiosas, como se puede ver en la ayuda del motor PHP, entre los que tenemos -s, que deja ver el código fuente del código a ejecutarse. Esto permite que con un sencillo -s en la URL el servidor web muestre el todo el código del sitio PHP que estamos visitando, y poder acceder a toda la información de configuración que allí se encuentre.
Por supuesto, con el modificador -d es posible incidir en los parámetros de ejecución del motor PHP, pudiendo escribir nuestro propio código en el servidor, por ejemplo, para obtener un phpinfo que nos de todas las variables del servidor.
Y si se desea ejecutar una webshell, se puede modificar la configuración directamente desde la URL para insertar la webshell remotamente, en este ejemplo una C99.
PHP ha publicado un parche de urgencia, pero tiene una vulnerabilidad que hace fácil saltárselo, y se ha abierto un nuevo expediente CVE-2012-2311 para seguirlo. Pero la historia del bug es aún más curiosa. El estándar CGI permite que se envíen desde el query string argumentos al ejecutable que se encargue de la ejecución, y Apache lo implementa. En el año 2004 se supo de los problemas que esto podría acarrear en entornos PHP y la documentación dice que PHP, cuando se ejecute en modo CGI ignorará esos argumentos... pero en algún momento de aquel 2004 alguien quitó el código de protección.
En el CTF de la NullCON se utilizaron los servidores de DreamHost para el llevar la puntuación, y al final se encontró el bug para conseguir ejecución de código y ownear el servidor. Ahora Internet está revuelto. Tienes toda la historia de este ya famoso bug en el post de publicación del fallo.
Ya está implementado el ataque en Metasploit, y por supuesto, nosotros estamos metiendo esta comprobación a la FOCA, por lo que los que tengáis la versión PRO en breve tendréis ya en la nueva actualización esta búsqueda, junto con alguna sorpresa más.
Saludos Malignos!
Figura 1: Parámetros de llamada del motor PHP |
Con estos parámetros se pueden hacer cosas bastante curiosas, como se puede ver en la ayuda del motor PHP, entre los que tenemos -s, que deja ver el código fuente del código a ejecutarse. Esto permite que con un sencillo -s en la URL el servidor web muestre el todo el código del sitio PHP que estamos visitando, y poder acceder a toda la información de configuración que allí se encuentre.
Figura 2: Código PHP mostrado desde la llamada de la URL |
Por supuesto, con el modificador -d es posible incidir en los parámetros de ejecución del motor PHP, pudiendo escribir nuestro propio código en el servidor, por ejemplo, para obtener un phpinfo que nos de todas las variables del servidor.
Figura 3: info.php obtenido por medio de una llamada al motor PHP con -d |
Y si se desea ejecutar una webshell, se puede modificar la configuración directamente desde la URL para insertar la webshell remotamente, en este ejemplo una C99.
Figura 4: Introduciendo una C99 por medio de una llamada al motor PHP |
PHP ha publicado un parche de urgencia, pero tiene una vulnerabilidad que hace fácil saltárselo, y se ha abierto un nuevo expediente CVE-2012-2311 para seguirlo. Pero la historia del bug es aún más curiosa. El estándar CGI permite que se envíen desde el query string argumentos al ejecutable que se encargue de la ejecución, y Apache lo implementa. En el año 2004 se supo de los problemas que esto podría acarrear en entornos PHP y la documentación dice que PHP, cuando se ejecute en modo CGI ignorará esos argumentos... pero en algún momento de aquel 2004 alguien quitó el código de protección.
En el CTF de la NullCON se utilizaron los servidores de DreamHost para el llevar la puntuación, y al final se encontró el bug para conseguir ejecución de código y ownear el servidor. Ahora Internet está revuelto. Tienes toda la historia de este ya famoso bug en el post de publicación del fallo.
Ya está implementado el ataque en Metasploit, y por supuesto, nosotros estamos metiendo esta comprobación a la FOCA, por lo que los que tengáis la versión PRO en breve tendréis ya en la nueva actualización esta búsqueda, junto con alguna sorpresa más.
Saludos Malignos!
5 comentarios:
¿Hay algún dork para saber si la web está corriendo PHP-CGI ?
inurl:phpinfo.php Server API CGI
Por ejemplo..
FastCGI installations are not vulnerable
ufffff :)
Como puedo comprobar esta vuln ?
Algún ejemplo sin "tachar" los datos
Yo quiero ser más práctica me gustaría un corta pega de los códigos a introducir y dónde para defenderme en PHP,.NET,JSP de webshell,ShellShock... Muchas gracias. O donde puedo adquirir estas líneas de código para insertar y defenderme, yo me pierdo entre tanto tecnicismos y complejidades y estoy Srta de ser pobre y vulnerable :(
Publicar un comentario