Noen Nginx-servere forblir sårbare for Nginx Alias Traversal-teknikken, som ble foreslått på Blackhat-konferansen tilbake i 2018 og gir tilgang til filer og kataloger utenfor rotkatalogen spesifisert i "alias"-direktivet. Problemet vises kun i konfigurasjoner med et "alias"-direktiv plassert inne i en "location"-blokk hvis parameter ikke ender med et "/"-tegn, mens "alias" slutter med en "/".
Essensen av problemet er at filer for blokker med aliasdirektivet serveres ved å legge ved den forespurte banen, etter å ha sammenlignet den med masken fra lokasjonsdirektivet og kuttet ut delen av banen spesifisert i denne masken. For eksempelet med en sårbar konfigurasjon vist ovenfor, kan en angriper be om filen "/img../test.txt", og denne forespørselen vil falle inn under "/img"-masken spesifisert på plassering, hvoretter den gjenværende halen ".. /test.txt" vil bli knyttet til banen fra aliasdirektivet "/var/images/" og vil til slutt be om filen "/var/images/../test.txt". Dermed kan angripere få tilgang til alle filer i "/var"-katalogen, og ikke bare filer i "/var/images/", for eksempel for å laste ned nginx-loggen, du kan sende forespørselen "/img../log/ nginx/ access.log".
I konfigurasjoner der verdien av aliasdirektivet ikke slutter med et "/"-tegn (for eksempel "alias /var/images;"), kan ikke angriperen endre til overordnet katalog, men kan be om en annen katalog i /var hvis navn starter med det samme som er spesifisert i konfigurasjonen. For eksempel, ved å be om "/img.old/test.txt" kan du få tilgang til katalogen "var/images.old/test.txt".
En analyse av repositories på GitHub viste at feil i nginx-konfigurasjonen som fører til problemet fortsatt forekommer i virkelige prosjekter. For eksempel ble problemet identifisert i bakenden av Bitwarden passordbehandling og kan brukes til å få tilgang til alle filer i /etc/bitwarden-katalogen (/vedleggsforespørsler ble utstedt fra /etc/bitwarden/attachments/), inkludert "hvelvet" .db", sertifikat og logger, for å skaffe som det var nok å sende forespørsler "/attachments../vault.db", "/attachments../identity.pfx", "/attachments../logs/api.log ", osv. .P.
Metoden fungerte også med Google HPC Toolkit, som omdirigerte /statiske forespørsler til katalogen "../hpc-toolkit/community/front-end/website/static/". For å få en database med en privat nøkkel og legitimasjon, kan en angriper sende forespørsler "/static../.secret_key" og "/static../db.sqlite3".
Kilde: opennet.ru