Alcuni server con nginx rimangono vulnerabili alla tecnica Nginx Alias Traversal, proposta alla conferenza Blackhat nel 2018 e che consente l'accesso a file e directory che si trovano al di fuori della directory principale specificata nella direttiva "alias". Il problema si presenta solo nelle configurazioni con una direttiva "alias" posta all'interno del blocco "location", il cui parametro non termina con un carattere "/", mentre "alias" termina con "/".
L'essenza del problema è che i file per i blocchi con la direttiva alias vengono forniti allegando il percorso richiesto, dopo averlo abbinato alla maschera della direttiva location e ritagliando la parte del percorso specificata in questa maschera. Per l'esempio di una configurazione vulnerabile mostrata sopra, un utente malintenzionato può richiedere il file "/img../test.txt" e questa richiesta corrisponderà alla maschera specificata nella posizione "/img", dopodiché la coda rimanente "../ test.txt" verrà allegato al percorso dalla direttiva alias "/var/images/" e di conseguenza verrà richiesto il file "/var/images/../test.txt". Pertanto, gli aggressori possono accedere a qualsiasi file nella directory "/var" e non solo ai file in "/var/images/", ad esempio, per scaricare il registro nginx, è possibile inviare la richiesta "/img../log/ nginx/access.log".
Nelle configurazioni in cui il valore della direttiva alias non termina con un carattere "/" (ad esempio, "alias /var/images;"), l'attaccante non può passare alla directory padre, ma può richiedere un'altra directory in /var il cui nome inizia con specificato nella configurazione. Ad esempio, richiedendo "/img.old/test.txt" è possibile accedere alla directory "var/images.old/test.txt".
Un'analisi dei repository su GitHub ha mostrato che gli errori nella configurazione di nginx che portano al problema si trovano ancora nei progetti reali. Ad esempio, la presenza di un problema è stata rilevata nel backend del gestore di password Bitwarden e potrebbe essere utilizzata per accedere a tutti i file nella directory /etc/bitwarden (le richieste di /attachments sono state emesse da /etc/bitwarden/attachments/), compreso il database ivi memorizzato con password “vault.db”, certificato e log, per i quali bastava inviare richieste “/attachments../vault.db”, “/attachments../identity.pfx”, “/attachments ../logs/api.log", ecc. .P.
Il metodo ha funzionato anche con Google HPC Toolkit, dove le richieste /static sono state reindirizzate alla directory "../hpc-toolkit/community/front-end/website/static/". Per ottenere un database con una chiave privata e credenziali, un utente malintenzionato potrebbe inviare query "/static../.secret_key" e "/static../db.sqlite3".
Fonte: opennet.ru