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.
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.
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.
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!
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 |
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 |
Saludos Malignos!
Muy bonito, pero este tipo de fallo no se encuentra casi nunca.
ResponderEliminarinurl:"index.php?filename=doc.php"
AfriQuest
ResponderEliminarSaludos malignotes
Esto que becario lo ha programado?
ResponderEliminar- No te olvides del método:
ResponderEliminarDe esta forma cortamos la cadena al final, y el resto es ignorado.
¿Útil no?
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?
ResponderEliminarSé que puedo contestarme quizás sólo la pregunta, pero capaz sepas algo que yo no lo sé, ajá.
Saludos.