Nginx Alias ​​​​Traversal sigue siendo un problema critico para muchos proyectos

Hace poco se dio a conocer la noticia de que algunos servidores con nginx siguen siendo vulnerables a la técnica «Nginx Alias ​​​​Traversal», que se propuso en la conferencia Blackhat en 2018 y permite el acceso a archivos y directorios ubicados fuera del directorio raíz especificado en la directiva «alias».

La esencia del problema es que los archivos para bloques con la directiva de alias se proporcionan adjuntando la ruta solicitada, después de hacerla coincidir con la máscara de la directiva de ubicación y cortando la parte de la ruta especificada en esta máscara.

El problema aparece solo en configuraciones con una directiva «alias», ya que en la configuración de Nginx, hay una directiva llamada ‘location’ que puede describir cómo se debe manejar el acceso a una URL en particular, y se usa a menudo para asignar direcciones URL a archivos en el servidor.

En el patrón que usa esta ubicación en combinación con el alias, es crítico cuando se cumplen las dos condiciones de ‘no poner una barra al final de la URL especificada por la ubicación’ y ‘poner una barra al final de la ruta especificada por el alias ‘ se cumplan. Se dice que la vulnerabilidad ocurrirá.

En la conferencia BlackHat 2018, Orange Tsai presentó su investigación sobre la ruptura de analizadores de URL. Entre otros hallazgos impresionantes, demostró una técnica descubierta en un desafío CTF de 2016 de HCTF, creado por @iaklis.

Para que la técnica sea aplicable, se deben cumplir las siguientes condiciones:

La locationdirectiva no debe tener una barra inclinada en su camino;
Una aliasdirectiva debe estar presente dentro del contexto de ubicación y debe terminar con una barra inclinada.

Para el ejemplo de una configuración vulnerable que se muestra arriba, un atacante puede solicitar el archivo «/img../test.txt» y esta solicitud coincidirá con la máscara especificada en la ubicación «/img», después de lo cual la cola restante «../ test.txt» se adjuntará a la ruta de la directiva de alias «/var/images/» y como resultado se solicitará el archivo «/var/images/../test.txt».

Por lo tanto, los atacantes pueden acceder a cualquier archivo en el directorio «/var», no solo a los archivos en «/var/images/», por ejemplo, para descargar el registro de nginx, puede enviar la solicitud «/img../log/nginx /acceso.log».

Un análisis de los repositorios en GitHub mostró que los errores en la configuración de nginx que conducen al problema aún se encuentran en proyectos reales.

Por ejemplo, se detectó la existencia de un problema en el backend del administrador de contraseñas de Bitwarden y podría usarse para acceder a todos los archivos en el directorio /etc/bitwarden (las solicitudes de /archivos adjuntos se emitieron desde /etc/bitwarden/attachments/), incluyendo la base de datos almacenada allí con contraseñas «vault.db», certificado y registros, para lo cual fue suficiente enviar solicitudes «vault.db», «identity.pfx», «api.log», etc.

Se menciona que la gravedad de esta vulnerabilidad puede fluctuar significativamente según el proyecto, desde un impacto insignificante hasta uno crítico. El grado de sus repercusiones está determinado principalmente por si el directorio expuesto contiene datos confidenciales que pueden facilitar ataques adicionales o resultar en la divulgación de información privada.

Como punto de partida en nuestra búsqueda de esta vulnerabilidad, elegimos explorar los repositorios populares de GitHub que mostraban este problema. Identificar esta vulnerabilidad específica en entornos con acceso al código fuente se vuelve significativamente más factible, principalmente debido a dos factores principales:

Detección: el uso de herramientas de análisis de código sencillas, como búsquedas de expresiones regulares, nos permite identificar de manera efectiva los archivos de configuración de Nginx potencialmente vulnerables dentro de estos proyectos.
Explotación: tener conocimiento del directorio de destino exacto al que se le ha asignado un alias nos permite configurar una instancia local, examinar los directorios con alias usando un shell local y determinar a qué archivos se puede acceder a través de la vulnerabilidad.

Cabe mencionar que el método también funcionó con Google HPC Toolkit, donde las solicitudes se redirigieron al directorio de interes para obtener una base de datos con una clave privada y credenciales, un atacante podría enviar consultas «secret_key» y «db.sqlite3».

Finalmente si estas interesado en poder conocer mas al respecto, puedes consultar los detalles en el siguiente enlace.