Alcuni server con nginx rimangono vulnerabili alla tecnica Nginx Alias Traversal, proposta alla conferenza Blackhat nel 2018, che permette di accedere a file e directory collocati al di fuori della directory principale definita nella direttiva «alias». Il problema si manifesta solo nelle configurazioni con la direttiva «alias» collocata all'interno di un blocco «location», il cui parametro non termina con il carattere «/», mentre l'«alias» termina con «/».
La sostanza del problema è che i file per i blocchi con la direttiva alias vengono restituiti tramite l'attacco del percorso richiesto, dopo che è stato confrontato con il mascheramento della direttiva location e tagliata la parte del percorso specificata in questa maschera. Per l'esempio sopra riportato di una configurazione vulnerabile, un attaccante può richiedere il file «/img../test.txt» e questa richiesta cadrà sotto la maschera specificata nel location «/img», dopo di che il resto «../test.txt» verrà attaccato al percorso della direttiva alias «/var/images/» e alla fine verrà richiesto il file «/var/images/../test.txt». In questo modo, gli attaccanti possono accedere a qualsiasi file nella directory «/var», non solo ai file in «/var/images/», per esempio, per caricare il log 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ò accedere alla directory principale, ma ha la possibilità di richiedere un'altra directory in /var, il cui nome inizia con quello indicato nella configurazione. Ad esempio, richiedendo «/img.old/test.txt» è possibile accedere alla directory «var/images.old/test.txt».
L'analisi dei repository su GitHub ha mostrato che le configurazioni problematiche di nginx si riscontrano ancora in progetti reali. Ad esempio, è stata riscontrata una vulnerabilità nella parte server del gestore di password Bitwarden, che potrebbe essere utilizzata per accedere a tutti i file nella directory /etc/bitwarden (richieste /attachments venivano restituite da /etc/bitwarden/attachments/), inclusa la DB dei password memorizzata là «vault.db», certificati e log, per accedere ai quali era sufficiente inviare richieste come «/attachments../vault.db», «/attachments../identity.pfx», «/attachments../logs/api.log» e così via.
Il metodo ha funzionato anche con Google HPC Toolkit, in cui le richieste /static venivano reindirizzate nella directory «../hpc-toolkit/community/front-end/website/static/». Per ottenere il DB con chiave privata e credenziali, l'attaccante potrebbe inviare richieste come «/static../.secret_key» e «/static../db.sqlite3».
Fonte: opennet.ru
