Inicio
TIENDA PUBLISHOP
A punto de terminar este 2014, la vulnerabilidad Path Transversal o Ruta Transversal sigue copando una de las primeras posiciones dentro del top ten establecido por la fundación OWASP
sobre vulnerabilidades en aplicaciones web. Detectar páginas web que
puedan sufrir este tipo de vulnerabilidad es relativamente sencillo
aplicando un poco de hacking con buscadores,
debido a que hay tipos de páginas que tienen este fallo muy
tipificados. Uno de ellos muy común es el de una aplicación para
descargar ficheros que no asegure correctamente la ruta ni la extensión
del fichero que se le está pasando por parámetro.
En el caso del paso del nombre de un fichero, es común encontrar, como veremos más adelante, parámetros file o fichero con el nombre y la ruta completa dentro del servidor, pero también es posible que el parámetros sea el nombre codificado en BASE64 o similares, por aquello de evitar la exposición al ojo del nombre del fichero. Si por el contrario se hace un acceso indirecto por medio de un ID, será necesario averiguar de qué forma guarda la tabla que recoge cuál es la asignación ID a ruta de fichero. Esto podría ser mediante un fichero de texto, un archivo XML o directamente una tabla en una base de datos - que suele ser lo más común en los CMS personalizados -.
Detectar este tipo de páginas en los buscadores es fácil, tal y como se explica en el artículo de "Cómo localizar webs vulnerables a LFI con Google" ya que el patrón que suelen seguir sus URLs es de la forma:
Como se puede ver en los resultados, el número de aplicaciones que cumple ese patrón es alto pero no todos son vulnerables. Para evaluar si ese tipo de aplicaciones son vulnerables o no, primero hay que determinar la estructura con la que se está accediendo al fichero. Este acceso puede ser de forma directa, para lo que se está pasando un nombre de fichero, o indirecta, mediante el paso de un identificador que le sirve a la aplicación para localizar la ubicación del fichero.
Al final objetivo de un Path Tranversal es obtener acceso a ficheros o directorios que se encuentren dentro del directorio raíz de un servidor web pero no accesibles directamente desde la aplicación web, sino utilizada por ésta para, por ejemplo, conectarse con la base de datos del sistema para validar un usuario, etc… Otras veces se aprovecha esta vulnerabilidad para acceder a ficheros fuera del directorio web como puedan ser /etc/passwd y /etc/shadow y, tras fusionarlos con herramientas de tipo unshadow, aplicar fuerza bruta sobre las claves hasheadas de los usuarios para intentar obtenerlas en texto claro, con herramientas como John The Ripper, etc…
Cuando se puede escalar de esta forma por la estructura de directorios de un servidor, esta vulnerabilidad podría venir acompañada de otras dos: Local File Inclusion para ver el contenido de los ficheros y/o Remote File Inclusion para ejecutar código remoto. La primera permite incluir ficheros locales donde se encuentra la web que presenta la vulnerabilidad y la segunda cargar ficheros de manera remota, básicamente para intentar ejecutar comandos dentro del servidor o ejecutar scripts.
Paso 1. Búsqueda de una web vulnerable.
En la siguiente prueba de concepto se muestra cómo localizar webs que puedan ser vulnerables a este tipo de ataque, cómo explotar el ataque para ver la información sensible que se puede obtener si no se ha pasado una auditoria web de seguridad. Para ello vamos a hacer un poco de hacking con buscadores y, para acotar los resultados, vamos a buscar páginas que se encuentren bajo un determinado dominio y que los ficheros tengan una determinada extensión.
En este ejemplo, vamos a seleccionar una en la que el nombre del fichero venga directamente en el parámetro. Si viniera un ID, habría que ver si en él se puede inyectar un comando SQL Injection para poder hacer algo como:
Paso 2. Comprobar si la web es vulnerable.
En este caso, centrándonos en una web en la que se recibe como parámetro el nombre de fichero - y a veces la ruta en un parámetro a parte -, para comprobar si está presente la vulnerabilidad Path Transversal, se usa la secuencia de caracteres especiales conocida como “dot-dot-slash” o ../
Pero también podemos probar a poner parte de la URL localizada - en concreto lo más fácil es intentar descargar el mismo fichero que se usa para descargas - para ver cuál es el comportamiento del navegador. Si es vulnerable, observaremos que nuestro navegador va a realizar una descarga, luego esto nos da la pista de que la vulnerabilidad de Path Transversal está presente en la aplicación web. Además tenemos la certeza de la existencia del directorio archivos dentro del servidor web.
Una vez visto que se pueden descargar ficheros arbitrariamente, intentaremos descargar ficheros como index.php o ../index.php para ver si es posible descargar estos archivos en texto claro y ver si podemos obtener rutas de archivos de configuración, claves de acceso a la base de datos, etc…
Es en este punto, cuando ya se sabe que se pueden descargar ficheros del servidor, cuando entran en juego todos los data leaks que se puedan conseguir para listar los archivos locales del servidor web. Para eso, aprovecharse de los errores de conversión de tipos de datos en PHP, de las rutas locales mostradas en las páginas de error ASP, TCL o similares, y si es posible también de los directory listing, el bug de IIS Short name, ficheros .listing, archivos .DS_Store, DWSync.xml o módulo de mod_negotiation es de gran utilidad para saber dónde está y qué hay que descargar del servidor. Aquí tenéis un total de 20 técnicas para descubrir los ficheros de un servidor web.
En este caso, si observamos el contenido de este fichero index.php, vemos que existe el fichero funciones.php en el mismo directorio junto con el fichero home.php. Además, debido a una mala configuración del servidor, podemos descargarlos. A veces los ficheros del tipo funciones.php contienen usuarios y contraseñas harcodeadas, por lo que siempre hay que mirar su contenido:
Vemos en la imagen cómo es posible descubrir más fichero críticos dentro de una aplicación web, en este caso, conexion.php, que muy probable tenga los parámetros de configuración a la base de datos utilizada por la aplicación web donde puede haber usuarios y contraseñas de acceso, aparte de información sensibles de usuarios. Además también aparecen consultas a la base de datos, lo que nos puede dar una pista de cuáles son las tablas donde se almacena la información crítica de los usuarios, etc… Tras consultar el contenido del fichero conexion.php, se observan hardcodeados todos los parámetros de conexión a la base de datos.
Un atacante llegado a este punto podría intentar buscar la URL de acceso a PHPmyadmin o programar y un script de conexión en PHP a la base de datos, suponiendo que el servidor de base de datos acepte conexiones desde fuera del servidor.... o encontrar cualquier otro camino para llegar a la base de datos.
Paso 4. Implicaciones de la vulnerabilidad de tipo Path Transversal y de la fuga de información.
La finalidad de este ataque es poder acceder a ficheros a los que no debería de poder accederse por la información que contienen debido a los errores de programación en la aplicación web. Como hemos visto, podemos obtener los datos de conexión a la base de datos.
Si en la base de datos, a parte de la información de acceso hay información sensible de clientes, la fuga de información puede ser crítica, la pena por el incumplimiento de la LOPD 15/99 puede ser importante, además de que esos datos se puedan vender en el mercado negro tal y como hacen los cibercriminales dedicados al fraude online.
 |
| Figura 1: Cómo te pueden robar la Base de Datos de tu sitio web con Path Transversal & Local File Inclusion |
En el caso del paso del nombre de un fichero, es común encontrar, como veremos más adelante, parámetros file o fichero con el nombre y la ruta completa dentro del servidor, pero también es posible que el parámetros sea el nombre codificado en BASE64 o similares, por aquello de evitar la exposición al ojo del nombre del fichero. Si por el contrario se hace un acceso indirecto por medio de un ID, será necesario averiguar de qué forma guarda la tabla que recoge cuál es la asignación ID a ruta de fichero. Esto podría ser mediante un fichero de texto, un archivo XML o directamente una tabla en una base de datos - que suele ser lo más común en los CMS personalizados -.
Detectar este tipo de páginas en los buscadores es fácil, tal y como se explica en el artículo de "Cómo localizar webs vulnerables a LFI con Google" ya que el patrón que suelen seguir sus URLs es de la forma:
 |
| Figura 2: Resultados devueltos por Google |
Como se puede ver en los resultados, el número de aplicaciones que cumple ese patrón es alto pero no todos son vulnerables. Para evaluar si ese tipo de aplicaciones son vulnerables o no, primero hay que determinar la estructura con la que se está accediendo al fichero. Este acceso puede ser de forma directa, para lo que se está pasando un nombre de fichero, o indirecta, mediante el paso de un identificador que le sirve a la aplicación para localizar la ubicación del fichero.
Al final objetivo de un Path Tranversal es obtener acceso a ficheros o directorios que se encuentren dentro del directorio raíz de un servidor web pero no accesibles directamente desde la aplicación web, sino utilizada por ésta para, por ejemplo, conectarse con la base de datos del sistema para validar un usuario, etc… Otras veces se aprovecha esta vulnerabilidad para acceder a ficheros fuera del directorio web como puedan ser /etc/passwd y /etc/shadow y, tras fusionarlos con herramientas de tipo unshadow, aplicar fuerza bruta sobre las claves hasheadas de los usuarios para intentar obtenerlas en texto claro, con herramientas como John The Ripper, etc…
Cuando se puede escalar de esta forma por la estructura de directorios de un servidor, esta vulnerabilidad podría venir acompañada de otras dos: Local File Inclusion para ver el contenido de los ficheros y/o Remote File Inclusion para ejecutar código remoto. La primera permite incluir ficheros locales donde se encuentra la web que presenta la vulnerabilidad y la segunda cargar ficheros de manera remota, básicamente para intentar ejecutar comandos dentro del servidor o ejecutar scripts.
Paso 1. Búsqueda de una web vulnerable.
En la siguiente prueba de concepto se muestra cómo localizar webs que puedan ser vulnerables a este tipo de ataque, cómo explotar el ataque para ver la información sensible que se puede obtener si no se ha pasado una auditoria web de seguridad. Para ello vamos a hacer un poco de hacking con buscadores y, para acotar los resultados, vamos a buscar páginas que se encuentren bajo un determinado dominio y que los ficheros tengan una determinada extensión.
 |
| Figura 3: Resultados de aplicaciones web que descargan archivos con la ruta del mismo |
En este ejemplo, vamos a seleccionar una en la que el nombre del fichero venga directamente en el parámetro. Si viniera un ID, habría que ver si en él se puede inyectar un comando SQL Injection para poder hacer algo como:
MySQL -> id=-1 UNION SELECT "/etc/passwd"Al final, habría que construir una consulta INBAND con UNION para conseguir que la consulta que esté construyendo el programador devuelva un recordset vacío y se le una un recordset creado por nosotros. Construir la consulta INBAND en cada caso requiere reconocer el motor de la base de datos, analizar la consulta del programador mediante pruebas, etcétera. Si quieres saber más de esto tienes que dominar las técnicas de SQL Injection.
Oracle -> id=-1 UNION SELECT "/etc/passwd" from dual
SQL Server -> id=-1 UNION SELECT "/etc/passwd" from sysobjects --
Paso 2. Comprobar si la web es vulnerable.
En este caso, centrándonos en una web en la que se recibe como parámetro el nombre de fichero - y a veces la ruta en un parámetro a parte -, para comprobar si está presente la vulnerabilidad Path Transversal, se usa la secuencia de caracteres especiales conocida como “dot-dot-slash” o ../
Pero también podemos probar a poner parte de la URL localizada - en concreto lo más fácil es intentar descargar el mismo fichero que se usa para descargas - para ver cuál es el comportamiento del navegador. Si es vulnerable, observaremos que nuestro navegador va a realizar una descarga, luego esto nos da la pista de que la vulnerabilidad de Path Transversal está presente en la aplicación web. Además tenemos la certeza de la existencia del directorio archivos dentro del servidor web.
Una vez visto que se pueden descargar ficheros arbitrariamente, intentaremos descargar ficheros como index.php o ../index.php para ver si es posible descargar estos archivos en texto claro y ver si podemos obtener rutas de archivos de configuración, claves de acceso a la base de datos, etc…
 |
| Figura 4: Descargando el fichero Index.php |
Es en este punto, cuando ya se sabe que se pueden descargar ficheros del servidor, cuando entran en juego todos los data leaks que se puedan conseguir para listar los archivos locales del servidor web. Para eso, aprovecharse de los errores de conversión de tipos de datos en PHP, de las rutas locales mostradas en las páginas de error ASP, TCL o similares, y si es posible también de los directory listing, el bug de IIS Short name, ficheros .listing, archivos .DS_Store, DWSync.xml o módulo de mod_negotiation es de gran utilidad para saber dónde está y qué hay que descargar del servidor. Aquí tenéis un total de 20 técnicas para descubrir los ficheros de un servidor web.
 |
| Figura 5: Descubrimiento del fichero funciones.php citado en index.php |
En este caso, si observamos el contenido de este fichero index.php, vemos que existe el fichero funciones.php en el mismo directorio junto con el fichero home.php. Además, debido a una mala configuración del servidor, podemos descargarlos. A veces los ficheros del tipo funciones.php contienen usuarios y contraseñas harcodeadas, por lo que siempre hay que mirar su contenido:
 |
| Figura 6: Descarga del fichero funciones.php Se descubre admin/conexion.php |
Vemos en la imagen cómo es posible descubrir más fichero críticos dentro de una aplicación web, en este caso, conexion.php, que muy probable tenga los parámetros de configuración a la base de datos utilizada por la aplicación web donde puede haber usuarios y contraseñas de acceso, aparte de información sensibles de usuarios. Además también aparecen consultas a la base de datos, lo que nos puede dar una pista de cuáles son las tablas donde se almacena la información crítica de los usuarios, etc… Tras consultar el contenido del fichero conexion.php, se observan hardcodeados todos los parámetros de conexión a la base de datos.
 |
| Figura 7: Parámetros de conexión a la base de datos MySQL |
Un atacante llegado a este punto podría intentar buscar la URL de acceso a PHPmyadmin o programar y un script de conexión en PHP a la base de datos, suponiendo que el servidor de base de datos acepte conexiones desde fuera del servidor.... o encontrar cualquier otro camino para llegar a la base de datos.
Paso 4. Implicaciones de la vulnerabilidad de tipo Path Transversal y de la fuga de información.
La finalidad de este ataque es poder acceder a ficheros a los que no debería de poder accederse por la información que contienen debido a los errores de programación en la aplicación web. Como hemos visto, podemos obtener los datos de conexión a la base de datos.
Si en la base de datos, a parte de la información de acceso hay información sensible de clientes, la fuga de información puede ser crítica, la pena por el incumplimiento de la LOPD 15/99 puede ser importante, además de que esos datos se puedan vender en el mercado negro tal y como hacen los cibercriminales dedicados al fraude online.
@bolUDOoficial
WhatsApp
Telegram
Ir a URL
