Algunos servidores con nginx siguen siendo vulnerables a la técnica Nginx Alias Traversal, que fue propuesta 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 solo se manifiesta en configuraciones con la directiva 'alias' ubicada dentro del bloque 'location', cuyo parámetro no termina con el carácter '/', mientras que 'alias' sí termina con '/'.
La esencia del problema es que los archivos para los bloques con la directiva alias se entregan mediante la adhesión de la ruta solicitada, después de su coincidencia con la máscara de la directiva location y recortando la parte de la ruta especificada en esta máscara. Para el ejemplo arriba mostrado de una configuración vulnerable, un atacante puede solicitar el archivo '/img../test.txt' y esta solicitud caerá bajo la máscara especificada en location '/img', después de lo cual el resto '..../test.txt' se adjuntará a la ruta de la directiva alias '/var/images/' y, en última instancia, se solicitará el archivo '/var/images/../test.txt'. Así, 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 log de nginx, se puede enviar la solicitud '/img../log/nginx/access.log'.
En configuraciones donde el valor de la directiva alias no termina con el carácter '/' (por ejemplo, 'alias /var/images;'), el atacante no puede retroceder al directorio padre, pero tiene la capacidad de solicitar otro directorio en /var, cuyo nombre comience con lo especificado en la configuración. Por ejemplo, al solicitar '/img.old/test.txt', se puede acceder al directorio 'var/images.old/test.txt'.
El análisis de repositorios en GitHub ha mostrado que los errores de configuración que conducen al problema siguen presentes en proyectos reales. Por ejemplo, se identificó la existencia de un problema en el backend del gestor de contraseñas Bitwarden y podría utilizarse para acceder a todos los archivos en el directorio /etc/bitwarden (las solicitudes /attachments se entregaban desde /etc/bitwarden/attachments/), incluyendo la base de datos almacenada allí con contraseñas 'vault.db', certificado y logs, cuya obtención requeriría enviar las solicitudes '/attachments../vault.db', '/attachments../identity.pfx', '/attachments../logs/api.log', etc.
El método también funcionó con Google HPC Toolkit, donde las solicitudes /static se redirigían a la carpeta '../hpc-toolkit/community/front-end/website/static/'. Para obtener la base de datos con la clave secreta y las credenciales, el atacante podría enviar las solicitudes '/static../.secret_key' y '/static../db.sqlite3'.
Fuente: opennet.ru
