Alcuni server con nginx rimangono vulnerabili alla tecnica Nginx Alias Traversal, proposta alla conferenza Blackhat nel 2018, che permette l'accesso a file e directory posizionati al di fuori della directory radice definita nella direttiva «alias». Il problema si manifesta solo nelle configurazioni con la direttiva «alias» posizionata all'interno del blocco «location», il cui parametro non termina con il carattere «/», mentre «alias» termina con «/».
La questione riguarda il fatto che i file per i blocchi con la direttiva alias vengono restituiti tramite il percorso richiesto, dopo che è stato confrontato con la maschera della direttiva location e che la parte del percorso specificata in questa maschera è stata rimossa. Per l'esempio di configurazione vulnerabile mostrato sopra, un attaccante può richiedere il file "/img../test.txt" e questa richiesta cadrà sotto la maschera specificata in location "/img", dopo di che la coda rimanente "../test.txt" verrà allegata al percorso della direttiva alias "/var/images/" e alla fine verrà richiesto il file "/var/images/../test.txt". Così, gli attaccanti possono accedere a qualsiasi file nella directory "/var", non solo ai file in "/var/images/"; ad esempio, per scaricare il log di nginx, si può inviare la richiesta "/img../log/nginx/access.log".
Nelle configurazioni in cui il valore della direttiva alias non termina con il carattere "/" (ad esempio, "alias /var/images;"), l'attaccante non può risalire alla directory padre, ma ha la possibilità di richiedere un'altra directory in /var, il cui nome inizia con quello specificato nella configurazione. Ad esempio, richiedendo "/img.old/test.txt" si può accedere alla directory "var/images.old/test.txt".
L'analisi dei repository su GitHub ha rivelato che gli errori di configurazione di nginx che portano a problemi sono ancora presenti nei progetti reali. Ad esempio, è stata identificata una vulnerabilità nel backend del gestore di password Bitwarden, che poteva essere utilizzata per accedere a tutti i file nella directory /etc/bitwarden (le richieste /attachments venivano servite da /etc/bitwarden/attachments/), inclusa la database dei password «vault.db», il certificato e i log, accessibili semplicemente inviando richieste come «/attachments../vault.db», «/attachments../identity.pfx», «/attachments../logs/api.log» e simili.
Il metodo ha funzionato anche con Google HPC Toolkit, dove le richieste /static venivano reindirizzate nella directory «../hpc-toolkit/community/front-end/website/static/». Per ottenere il database con la chiave segreta e le credenziali, l'attaccante poteva inviare richieste come «/static../.secret_key» e «/static../db.sqlite3».
Fonte: opennet.ru
