viernes, mayo 25, 2012

Pruebas para descubrir un LFI al estilo FOCA

En la versión privada de la FOCA, que vamos a enseñar en un ratito en Hack in the Box, se busca automáticamente por vulnerabilidades LFI. Para ello, en las URLs parametrizadas - las que tienen parámetros por GET, vamos - se hacen unas pequeñas pruebas para saber si es posible o no que tenga un Local File Inclusión.

Paso 1: La URL con la respuesta original.

Primero se toma la URL sin realizar ninguna modificación, para tomarla como referencia en las subsiguientes pruebas. Así que en la primera petición no se inyecta nada.

Figura 1: La URL sin inyectar

Paso 2: Probando el directorio local

Después se prueba si es posible acceder a la misma página haciendo uso de ./, lo que implicaría que hay probabilidades de que se permita inyectar caracteres en la ruta de acceso al fichero local. Si devuelve la misma página que en el paso 1, entonces vamos por el buen camino.

Figura 2: Probando el directorio local

Paso 3: Probando un directorio falso

Una de las pruebas más significativas es la de solicitar un subdirectorio inventado y luego subir con ../ al directorio padre para acceder al mismo fichero. Si se devuelve el mismo resultado, es que tiene muy buena pinta, pero aún no es seguro ya que podría tener un comportamiento de tratamiento de errores que devolviera siempre la misma página, por lo que hay que hacer alguna prueba más.

Figura 3: Probando un directorio falso y subiendo al padre

Paso 4: Generando un error conocido

Para descartar la posibilidad de que sea el tratamiento de errores el que siempre nos devuelve la misma página, se pide el fichero, pero en una ruta que no exista, para o que lanzamos un directorio fantasma. ¡Cuidado no aciertes con el nombre de un directorio oculto! Prueba con un par por si se diera ese caso.

Figura 4: Probando un directorio falso sin anularlo

Paso 5: Por si hay un filtro

En este caso en concreto ya sabemos que hay un LFI, pero por si hubiera un filtro que quitase "../" de manera erronea, un truco es pedir "..././", ya que si quita "../" de la ecuación, quedaría "../". Aunque parezca mentira muchos filtros mal programados pueden ser saltados de esta forma.

Figura 5: Probando un posible bypass de un filtro

Existen muchas herramientas que implementan este tipo de comprobaciones, pero nuestra FOCA se porta muy bien con estos tests en las auditorías de seguridad web que realizamos a nuestros clientes. ¿Qué más trucos usáis vosotros para descubrir LFI?

Saludos Malignos!

5 comentarios:

Anónimo dijo...

Muy bonito, pero este tipo de fallo no se encuentra casi nunca.

inurl:"index.php?filename=doc.php"

Anónimo dijo...

AfriQuest

Saludos malignotes

Anónimo dijo...

Esto que becario lo ha programado?

Jorge dijo...

- No te olvides del método:

De esta forma cortamos la cadena al final, y el resto es ignorado.

¿Útil no?

Unknown dijo...

Una pregunta en GNU/Linux existen archivos como /etc/issue o /etc/passwd, que es casi lo primero que pruebo en un LFI tratar de leer esos archivos, pero ¿en el caso de ser un Windows Server? ví que existía en Windows un archivo /windows/repair/sam, que era como el /etc/passwd, ¿es cierto?, ¿hay otros archivos importantes o de lo que podamos sacar un poco más de información o divertirnos un poco?

Sé que puedo contestarme quizás sólo la pregunta, pero capaz sepas algo que yo no lo sé, ajá.

Saludos.

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares