Algúns servidores de Nginx seguen sendo vulnerables á técnica Nginx Alias Traversal, que foi proposta na conferencia de Blackhat en 2018 e que permite o acceso a ficheiros e directorios situados fóra do directorio raíz especificado na directiva "alias". O problema só aparece nas configuracións cunha directiva "alias" colocada dentro dun bloque "localización" cuxo parámetro non remata cun carácter "/", mentres que "alias" remata cun "/".
A esencia do problema é que os ficheiros para bloques coa directiva de alias son servidos anexando a ruta solicitada, despois de comparala coa máscara da directiva de localización e cortar a parte da ruta especificada nesta máscara. Para o exemplo dunha configuración vulnerable mostrada anteriormente, un atacante pode solicitar o ficheiro "/img../test.txt" e esta solicitude caerá baixo a máscara "/img" especificada na localización, despois de que a cola restante ".. /test.txt” unirase á ruta da directiva de alias “/var/images/” e eventualmente solicitará o ficheiro “/var/images/../test.txt”. Así, os atacantes poden acceder a calquera ficheiro do directorio "/var", e non só aos ficheiros de "/var/images/", por exemplo, para descargar o rexistro de nginx, pode enviar a solicitude "/img../log/". nginx/access.log".
Nas configuracións nas que o valor da directiva de alias non remata cun carácter "/" (por exemplo, "alias /var/images;"), o atacante non pode cambiar ao directorio pai, pero pode solicitar outro directorio en /var cuxo nome comeza polo mesmo especificado na configuración. Por exemplo, solicitando "/img.old/test.txt" pode acceder ao directorio "var/images.old/test.txt".
Unha análise dos repositorios en GitHub mostrou que os erros na configuración de nginx que provocan o problema aínda se producen en proxectos reais. Por exemplo, o problema identificouse no backend do xestor de contrasinais de Bitwarden e podería usarse para acceder a todos os ficheiros do directorio /etc/bitwarden (as solicitudes de /attachments emitíronse desde /etc/bitwarden/attachments/), incluíndo o "bóveda". .db", certificado e rexistros, para obter o cal bastaba con enviar solicitudes "/attachments../vault.db", "/attachments../identity.pfx", "/attachments../logs/api.log ", etc. .P.
O método tamén funcionou con Google HPC Toolkit, que redirixiu as solicitudes /static ao directorio "../hpc-toolkit/community/front-end/website/static/". Para obter unha base de datos cunha clave privada e credenciais, un atacante podería enviar solicitudes "/static../.secret_key" e "/static../db.sqlite3".
Fonte: opennet.ru