Algunos servidores 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". El problema sólo aparece en configuraciones con una directiva "alias" colocada dentro de un bloque "ubicación" cuyo parámetro no termina con un carácter "/", mientras que "alias" termina con un "/".
La esencia del problema es que los archivos para bloques con la directiva alias se entregan adjuntando la ruta solicitada, después de compararla con la máscara de la directiva de ubicación y recortando la parte de la ruta especificada en esta máscara. Para el ejemplo de una configuración vulnerable que se muestra arriba, un atacante puede solicitar el archivo “/img../test.txt” y esta solicitud se ubicará bajo la máscara “/img” especificada en la ubicación, después de lo cual la cola restante “.. /test.txt” se adjuntará a la ruta de la directiva de alias “/var/images/” y eventualmente solicitará el archivo “/var/images/../test.txt”. Por lo tanto, los atacantes pueden acceder a cualquier archivo en el directorio “/var”, y no solo a los archivos en “/var/images/”, por ejemplo, para descargar el registro de nginx, puede enviar la solicitud “/img../log/ nginx/access.log".
En configuraciones en las que el valor de la directiva alias no termina con un carácter "/" (por ejemplo, "alias /var/images;"), el atacante no puede cambiar al directorio principal, pero puede solicitar otro directorio en /var cuyo nombre comienza con el mismo especificado en la configuración. Por ejemplo, solicitando "/img.old/test.txt" puede acceder al directorio "var/images.old/test.txt".
Un análisis de repositorios en GitHub mostró que los errores en la configuración de nginx que conducen al problema todavía ocurren en proyectos reales. Por ejemplo, el problema se identificó 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/), incluida la "bóveda". .db", certificado y logs, para obtener los cuales fue suficiente enviar las solicitudes "/attachments../vault.db", "/attachments../identity.pfx", "/attachments../logs/api.log ", etc. .P.
El método también funcionó con Google HPC Toolkit, que redirigió las solicitudes /static al directorio "../hpc-toolkit/community/front-end/website/static/". Para obtener una base de datos con una clave privada y credenciales, un atacante podría enviar las solicitudes “/static../.secret_key” y “/static../db.sqlite3”.
Fuente: opennet.ru