¿Qué es el directory traversal?

La traversía de directorios, también conocida como “path traversal” (e identificada con CWE-22), es una vulnerabilidad de aplicación web que permite a los atacantes acceder a archivos no previstos en un sistema de archivos subyacente. Según cómo y dónde ocurra la traversía, esto podría permitir que un atacante lea o escriba archivos arbitrarios en el servidor web, lo que posiblemente permitiría al atacante leer datos sensibles o archivos, modificar datos de la aplicación o tomar el control total del servidor web.

Las vulnerabilidades de traversal suelen describirse según si permiten leer archivos o escribir archivos. Demostraremos el impacto que cada una puede tener en las siguientes subsecciones.

Recorrido de directorios que permite lecturas arbitrarias de archivos

Considera una aplicación que permite a un usuario almacenar fotos y recuperarlas después con una solicitud GET usando un parámetro de nombre de archivo para especificar qué archivo recuperar. Si la aplicación no incluye protecciones contra path traversal y construye la ruta del archivo usando el parámetro de nombre de archivo proporcionado, podría ser posible recuperar archivos arbitrarios del servidor web subyacente. La figura 1 muestra esta secuencia en la práctica:

Incluso si la aplicación es vulnerable al traversal descrito, todavía hay limitaciones, como los permisos de la aplicación, que debes considerar. Por ejemplo, si se aplica un modelo de privilegio mínimo que limita el acceso de la aplicación en el servidor web, sus permisos pueden limitar los archivos a los que el atacante puede acceder con la vulnerabilidad. Esta es una de las razones por las que las cargas útiles de traversal usan con frecuencia /etc/passwd como objetivo: el archivo debe poder ser leído por todos los usuarios. Hay otras formas de aislar en un entorno controlado y limitar el acceso de la aplicación, que analizaremos más a fondo en la sección de prevención.

Recorrido de directorios que permite escrituras arbitrarias de archivos

Considera la misma aplicación de almacenamiento de fotos, pero ahora permite que el usuario asigne un nombre a cada una de las fotos que almacena. Al guardar el archivo en el disco, la aplicación usa el nombre proporcionado para construir la ruta del archivo de la foto. A menos que haya protecciones suficientes, un atacante puede agregar secuencias de recorrido (p. ej., ../) al nombre proporcionado, controlando en qué directorio se almacena el archivo. 

Aunque esto puede parecer inofensivo, ya que solo almacena una foto, hay formas de ampliar la explotación. Si no se valida el tipo de archivo (p. ej., JPEG, PNG), un atacante podría cargar cualquier tipo de archivo, lo que daría lugar a varios escenarios de explotación diferentes, como:

• Agregar la clave pública del atacante al archivo authorized_keys de un usuario (p. ej., /root/.ssh/authorized_keys) para obtener acceso persistente

• Sobrescribir archivos de la aplicación para modificar el comportamiento de la aplicación

• Cargar un web shell dentro de la raíz web

• Provocar una Denegación de servicio al sobrescribir los archivos del sistema necesarios

• Carga de archivos ejecutables (p. ej., malware, ransomware)

Según el nivel de acceso de la aplicación, el impacto de una escritura arbitraria de archivos derivada de un directory traversal puede ser devastador.

Ejemplos reales de directory traversal

Ahora que ya cubrimos los conceptos básicos de Directory Traversal, veamos algunas explotaciones recientes de esta vulnerabilidad en el mundo real.

Common Vulnerability and Exposure (CVE)-2023-2825: recorrido de directorios en Gitlab

En la versión 16.0.0 de Gitlab, hay una vulnerabilidad de directory traversal que permite lecturas arbitrarias de archivos. Cargar un archivo como archivo adjunto a un Issue en una instalación predeterminada de Gitlab hace que Gitlab almacene el archivo con una profundidad de 10 directorios en un patrón como se muestra a continuación:

/var/opt/gitlab/gitlab-rails/uploads/@hashed/<directory>/<directory>/<directory>/<directory>/<filename>

Después de cargarlo, Gitlab también proporciona un endpoint para recuperar el archivo cargado en

/<repo-name>/uploads/<file-id>/<filename>

En una solicitud a ese endpoint, Gitlab no sanitiza ni valida el parámetro filename, lo que permite un ataque de directory traversal. Para explotar la vulnerabilidad de traversal, el repositorio debe estar anidado dentro de al menos 5 grupos, y la cantidad de grupos se correlaciona directamente con la cantidad de directorios que puedes recorrer mediante la vulnerabilidad. 

En una instalación estándar, esto significa que necesitas anidar el repositorio en 11 grupos para poder llegar a la raíz del sistema de archivos. En este escenario, una carga útil de ataque para recuperar el archivo /etc/passwd podría verse de la siguiente manera:

GET /Group-1/Group-2/Group-3/Group-4/Group-5/Group-6/Group-7/Group-8/Group-9/Group-10/Group-11/<repo-name>/uploads/<file-id>/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fetc%2fpasswd

Los atacantes no autenticados solo pueden explotar la vulnerabilidad si un repositorio público cumple con el requisito de grupos anidados. Esto es poco probable, lo que hace más probable la explotación por parte de un usuario autenticado con privilegios para crear grupos anidados y repositorios que cumplan con los requisitos de explotación. Una cadena de explotación completa puede primero crear los grupos y el repositorio necesarios, cargar un archivo y luego explotar el recorrido transversal para leer archivos arbitrarios, como se ve en la POC aquí.

Common Vulnerability and Exposure (CVE)-2022-48362: directory traversal en ManageEngine Desktop Central

En las compilaciones de ManageEngine Desktop Central anteriores a la versión 10.1.2127.1, un directory traversal in archivo upload funcionalidad permitía escrituras arbitrarias de archivos al manipular el parámetro “computerName” (u otros pocos) para incluir secuencias de recorrido. 

En el momento de su descubrimiento, esta vulnerabilidad se explotaba activamente y se combinó con una omisión de autenticación (Common Vulnerability and Exposure (CVE)-2021-44515) para permitir la ejecución remota de código. Para ser breves, nos centraremos en la parte de ruta traversal de la explotación, ya que permite escribir un archivo y omite una validación poco estricta. 

En una función llamada “doPost”, Desktop Central maneja varios parámetros como parte de una carga de archivos, incluidos “computerName” y “filename”, entre otros. De esta función surgen dos vulnerabilidades que conducen a un directory traversal exitoso que permite escribir archivos:

1. Solo se verifica el parámetro filename para detectar secuencias de recorrido. Otros parámetros como “domainName”, “computerName” o “customerId” se usan para construir la ruta absoluta del archivo, pero no se verifican para detectar secuencias de recorrido. “computerName” es el último parámetro utilizado en la cadena concatenada, por lo que sería el lugar ideal para introducir una secuencia de recorrido porque no se le agregará contenido adicional.

2. La carga de archivos permite archivos con extensiones zip, 7z y gz. A primera vista, quizá esto parezca seguro. Sin embargo, debido a que Desktop Central es una aplicación Java y los archivos JAR están basados en el formato zip, esto permite la ejecución remota de código. Al cargar un archivo zip en el directorio C:\Program Files\DesktopCentral_Server\lib y forzar un reinicio, un atacante con experiencia puede sobrescribir archivos de clase en la aplicación para incluir su propio código y obtener ejecución de código. 

Esta vulnerabilidad resalta el grave impacto que puede permitir una vulnerabilidad de traversal, al tiempo que también muestra cómo una prevención incompleta puede permitir involuntariamente el directory traversal. 

Recorrido de directorios visto por los WAF

La vulnerabilidad de directory traversal es una de las técnicas de ataque observadas con mayor frecuencia, como se destaca en nuestro Informe de amenazas Network Effect del segundo trimestre de 2023. 

Esto podría deberse a varias razones, incluida la gravedad del impacto si tiene éxito o el tamaño de las listas de cargas útiles que pueden usar los atacante y los escáneres. Por ejemplo, un fragmento de una de las listas de directory traversal de PayloadsAllTheThings intenta leer el mismo archivo con distintas profundidades de recorrido, como se muestra a continuación:

../../../../../../../../../etc/passwd
../../../../../../../../etc/passwd
../../../../../../../etc/passwd
../../../../../../etc/passwd
../../../../../etc/passwd
../../../../etc/passwd
../../../etc/passwd

En la mayoría de los casos, es probable que un atacante no sepa dónde se encuentra la aplicación en el sistema de archivos al probar una vulnerabilidad de traversal. Sin embargo, las aplicaciones no irán más allá de la raíz del sistema (es decir, /), por lo que los atacantes utilizan secuencias más largas de “../” para asegurarse de llegar a la raíz, al tiempo que incluyen secuencias más cortas en caso de que las secuencias más largas se bloqueen o afecten la funcionalidad de la aplicación.

Otros tipos de ataque, como Cross-Site Scripting (XSS), pueden usar cargas útiles políglotas que combinan múltiples técnicas en una sola carga útil. Esto lleva a que los atacantes y los escáneres envíen muchas más cargas útiles para probar traversal que al probar XSS. Nuestro archivo de ejemplo de PayloadsAllTheThings contiene 140 cargas útiles, en comparación con su archivo XSS_Polyglots que tiene 16. El archivo de cargas útiles más grande para traversal en PayloadsAllTheThings tiene más de 21,000 entradas, en comparación con el más grande para XSS con más de 600, SQLi con más de 400 (aunque se debe asumir que esto sería mayor en la práctica si se desconoce el tipo de base de datos, ya que sería necesario probar varios tipos), y más de 400 para inyección de comandos del sistema operativo. 

Aunque el tamaño de las listas de cargas útiles de recorrido ofrece una hipótesis sobre la técnica de ataque de recorrido ampliamente observada, la gravedad del impacto también puede hacer que la técnica se use con más frecuencia. , como se demostró en la discusión anterior sobre Common Vulnerability and Exposure (CVE)-2022-48362, que permitió la ejecución remota de código y se sabía que estaba siendo explotada en el momento de su descubrimiento.

Prevención de vulnerabilidades de directory traversal

Hay varias estrategias que se pueden usar para prevenir vulnerabilidades de recorrido, incluidos cambios de diseño para evitar crear rutas de archivo con entrada del usuario, validación estricta de la entrada, uso de canonicalización de rutas y limitación del acceso de la aplicación. A continuación, veremos cada una de ellas.

Evita crear rutas de archivo con entradas del usuario

En lugar de usar la entrada del usuario para construir la ruta del archivo, considera usar un id o nombre de archivo correspondiente para hacer referencia al archivo. Luego, asigna los id de archivo a su ruta de almacenamiento correspondiente. Cuando un usuario solicita este archivo o carga un archivo, solo puede ejercer control sobre su id, lo que evita que el usuario acceda al contenido usado para construir la ruta del archivo. Esto elimina por completo la posibilidad de traversal, ya que la entrada del usuario ya no se usa para construir la ruta del archivo recuperado.

Validación estricta de la entrada del usuario

La validación estricta es diferente de la sanitización. En lugar de sanitizar la entrada intentando eliminar secuencias de recorrido (por ejemplo, ../), que pueden omitirse de innumerables maneras, valida que solo haya contenido esperado en la entrada del usuario y rechaza cualquier cosa que no pase la validación estricta. Ejemplos de validación que pueden ayudar a prevenir el directory traversal:

• Validar que un nombre de archivo solo contenga valores alfanuméricos

• Validar que solo haya un único carácter “.” en el nombre de archivo proporcionado

• Validar que no se incluyan caracteres no deseados en la entrada proporcionada (p. ej., /, \)

• Validar el tipo de archivo de un archivo cargado (no por la extensión, que se puede omitir fácilmente)

Usa las funciones del lenguaje de canonicalization de ruta para una validación estricta

La canonicalización de rutas básicamente acorta la ruta del archivo a su ruta real, eliminando de forma efectiva los enlaces simbólicos, las secuencias ../ y otro contenido simbólico. Después de obtener una ruta canónica, puedes verificar que siga comenzando con el directorio base esperado (por ejemplo, uploads/photos/). Algunos ejemplos de funciones para obtener una ruta canónica son:

• Java: getCanonicalPath

• PHP: realpath

• C: realpath

• ASP.NET: Obtener ruta completa

Limita el acceso a la aplicación

En general, una aplicación solo debe tener acceso a los archivos y directorios que necesita para funcionar correctamente. Esto ayuda en algunos casos de directory traversal al limitar el impacto de la vulnerabilidad si se descubre una. Por ejemplo, una aplicación web nunca debería ejecutarse con el usuario root y, en el mejor de los casos, debería estar restringida para acceder solo a los archivos que necesita para servir la aplicación.

Resumen

El directory traversal, también conocido como “path traversal”, es una vulnerabilidad de aplicación web que permite a los atacantes acceder a archivos no previstos en un sistema de archivos subyacente. Según la vulnerabilidad de traversal, esto podría permitir que un atacante lea datos sensibles o archivos, modifique datos de la aplicación o tome control total del servidor web. Las vulnerabilidades de traversal pueden tener impactos graves y, como se observa en nuestros ejemplos del mundo real y en los datos de Next-Gen WAF, son un vector de ataque destacado. Sin embargo, las aplicaciones pueden prevenir las vulnerabilidades de path traversal siguiendo las soluciones que hemos descrito. Si tienes dificultades para evitar el directory traversal, o usas un producto que ha sufrido estas vulnerabilidades en el pasado, consulta el Next-Gen WAF de Fastly para protegerte contra estos ataques y más.