Skip to main content
Directory Traversal - Qué es y como funciona

Directory Traversal – Qué es y como funciona

Directory traversal es una vulnerabilidad de seguridad en entornos web que permiten que un atacante pueda obtener acceso de lectura a ficheros locales del servidor donde corre la aplicación.

Bienvenidos a un nuevo post en Byte Mind, en el caso de hoy explicaremos en qué consiste la vulnerabilidad de Directory Traversal, como llevar a cabo una explotación exitosa y como podemos prevenir ser vulnerables a la misma, así que sin más dilación vamos a ello.

 

¿Qué es Directory Traversal?

Directory Traversal, también conocida como path traversal, es una vulnerabilidad de seguridad en entornos web que permiten que un atacante pueda obtener acceso de lectura a ficheros locales del servidor donde está corriendo la aplicación.

Esto incluiría ficheros con código de la aplicación, datos, credenciales o ficheros sensibles del sistema operativo.

En algunos casos, el atacante, es capaz de escribir ficheros arbitrarios en el servidor, permitiéndole la modificación de los datos o del comportamiento de la aplicación e incluso, poder tomar un control completo del servidor.

directory traversal attack

 

Tipos de ataques

A continuación veremos diferentes vulnerabilidades asociadas así como la vulnerabilidad en sí y como poder explotarlo con sencillos ejemplos que permitan entender al completo esta vulnerabilidad. En nuestro caso hemos hecho una simple aplicación en php para poder mostrarlo.

 

Explotación básica

Realizaremos este primer ejemplo con el siguiente código

En el mismo solicitamos la inclusión de un valor que se proporciona por el parámetro page a través del método GET, se almacena en una variable y se utiliza la función include para mostrarlo.

En este caso la explotación es muy sencilla debido a que es posible acceder a cualquier fichero sin restricciones, siempre y cuando se tengan permisos de lectura sobre el mismo, por ejemplo acceso al fichero /etc/passwd.

Veámoslo con un ejemplo:

Como se aprecia en el ejemplo, con una simple petición curl ha sido posible leer el fichero /etc/passwd, lógicamente, en el ejemplo, se ha recortado el mismo para evitar hacerlo muy largo.

 

Directory Path Traversal

En este caso se añade una pequeña sanitización sobre el código, especificando la ruta en la cual están los ficheros.

Esta podria parecer una buena idea pero al aplicar un directory path traversal, podemos retroceder en el árbol de directorios hasta la raiz y apuntar a cualquier archivo nuevamente

Y veamos el ejemplo de la petición

Como vemos, a pesar de haber especificado la ruta, no ha sido útil a la hora de intentar evitar la vulnerabilidad.

 

Reemplazo

En otras ocasiones es posible que se trate de reemplazar los caracteres ../ para tratar de evitar la vulnerabilidad. En el siguiente ejemplo de código se utiliza la función str_replace de php para eliminar esta cadena.

El problema es que este reemplazo sólo se realiza una vez, por lo tanto es posible realizar un bypass

Provocando que a pesar de haber tratado de eliminar la cadena, ha sido posible saltarse la protección y acceder al fichero de nuevo.

 

Doble reemplazo

En ocasiones he visto también que se ha realizado dos veces este reemplazo, como se aprecia en el siguiente código

Y la lógica es la misma que en el anterior ejemplo sólo que añadiendo dos . y una / por cada uno de ellos

Y dando lugar de nuevo a una explotación exitosa

Como vemos, no es una medida de protección segura ya que acabaría por poder obtenerse el fichero, o en caso de meter un bucle, podría llegar a un bucle infinito, lo que tampoco nos beneficiaría.

 

Null Byte

Otra opción posible es añadiendo explícitamente la extensión del fichero que se quiere obtener, en el siguiente ejemplo sería la extensión .php

En este caso se puede hacer un bypass utilizando un byte nulo mediante los caracteres %00, eliminando con ello todo lo que vaya después de lo deseado

Siguiendo el ejemplo la explotación sería la siguiente:

 

Wrapper base 64

Otra posibilidad es que la aplicación compruebe que el valor introducido no inicie por los caracteres / o .. para evitar los ataques anteriores. El código en nuestro caso sería el siguiente:

En este caso entrarían los filtros de php, para el caso de este ejemplo sería la conversión a base64

Haciendo simplemente la petición nos devolvería el base64

Al cual podríamos decodificar directamente como en el siguiente ejemplo

O utilizando el filtro base64 en lugar de base64-encode para obtener el resultado directamente

 

URL Encode

En otras ocasiones se utiliza una lista negra de palabras para evitar accesos a estos ficheros, veamos el código de ejemplo

La petición deberíamos hacerla codificada por lo que expongo un script en python que me ha sido útil en varias ocasiones, el código es el siguiente:

 

El anterior script permite codificar tantas veces como se desee, partiendo de una, así que vamos a ejecutar el mismo:

Y lanzamos la petición

Y observamos que ha sido posible explotarla de nuevo.

 

Cómo evitar este tipo de vulnerabilidades

La forma más efectiva de evitar esta vulnerabilidad es evitar que el usuario pueda pasar entradas al sistema de ficheros, ya sea a través de parámetros, una api, etc… ya que como se ha visto en los anteriores ejemplos, hay muchas formas de poder saltarse este tipo de restricciones.

En el caso de que sea necesario por alguna razón para nuestra api, las siguientes dos capas deberían de utilizarse para prevenir ataques:

  • La aplicación debería de validar la entrada de datos por parte del usuario. Idealmente la validación debería de comparar contra una lista de valores y caracteres permitidos.
  • Después de validar la entrada de datos, la aplicación debería añadir la entrada al directorio base utilizado por la plataforma para canonicalizar la ruta. Esta parte debería también validar que la ruta es correcta antes de proceder a la carga del fichero.

 

Y hasta aquí por el momento, espero les sea de utilidad y les haya ayudado a comprender un poco más este tipo de ataques y como es posible evitar ser vulnerables a los mismos.

 

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *