Vissa Nginx-servrar förblir sårbara för Nginx Alias Traversal-tekniken, som föreslogs vid Blackhat-konferensen 2018 och tillåter åtkomst till filer och kataloger utanför rotkatalogen som anges i "alias"-direktivet. Problemet dyker bara upp i konfigurationer med ett "alias"-direktiv placerat i ett "plats"-block vars parameter inte slutar med ett "/"-tecken, medan "alias" slutar med ett "/".
Kärnan i problemet är att filer för block med aliasdirektivet betjänas genom att den begärda sökvägen bifogas, efter att man jämför den med masken från platsdirektivet och skär ut den del av sökvägen som anges i denna mask. För exemplet med en sårbar konfiguration som visas ovan kan en angripare begära filen "/img../test.txt" och denna begäran kommer att falla under "/img"-masken som anges på plats, varefter den återstående svansen ".. /test.txt" kommer att bifogas sökvägen från aliasdirektivet "/var/images/" och kommer så småningom att begära filen "/var/images/../test.txt". Således kan angripare komma åt alla filer i "/var"-katalogen, och inte bara filer i "/var/images/", till exempel för att ladda ner nginx-loggen, kan du skicka begäran "/img../log/ nginx/ access.log".
I konfigurationer där värdet på aliasdirektivet inte slutar med ett "/"-tecken (till exempel "alias /var/images;"), kan angriparen inte byta till den överordnade katalogen, utan kan begära en annan katalog i /var vars namn börjar med samma som anges i konfigurationen. Till exempel, genom att begära "/img.old/test.txt" kan du komma åt katalogen "var/images.old/test.txt".
En analys av repositories på GitHub visade att fel i nginx-konfigurationen som leder till problemet fortfarande förekommer i verkliga projekt. Till exempel identifierades problemet i baksidan av Bitwardens lösenordshanterare och kunde användas för att komma åt alla filer i /etc/bitwarden-katalogen (/attachments-förfrågningar utfärdades från /etc/bitwarden/attachments/), inklusive "valvet .db", certifikat och loggar, för att erhålla vilka det räckte att skicka förfrågningar "/attachments../vault.db", "/attachments../identity.pfx", "/attachments../logs/api.log ", etc. .P.
Metoden fungerade också med Google HPC Toolkit, som omdirigerade /statiska förfrågningar till katalogen "../hpc-toolkit/community/front-end/website/static/". För att få en databas med en privat nyckel och referenser kan en angripare skicka förfrågningar "/static../.secret_key" och "/static../db.sqlite3".
Källa: opennet.ru