Některé servery s nginx zůstávají zranitelné vůči technice Nginx Alias Traversal, která byla navržena na konferenci Blackhat v roce 2018 a umožňuje přístup k souborům a adresářům umístěným mimo kořenový adresář uvedený v direktivě „alias“. Problém se objevuje pouze v konfiguracích s direktivou "alias" umístěnou uvnitř bloku "location", jejíž parametr nekončí znakem "/", zatímco "alias" končí "/".
Podstatou problému je, že soubory pro bloky s direktivou alias jsou dány připojením požadované cesty, po jejím spárování s maskou z direktivy umístění a vyříznutím části cesty uvedené v této masce. V příkladu zranitelné konfigurace zobrazené výše si útočník může vyžádat soubor "/img../test.txt" a tento požadavek bude odpovídat masce uvedené v umístění "/img", načež zbývající část "../ test.txt" bude připojen k cestě z aliasové direktivy "/var/images/" a v důsledku toho bude požadován soubor "/var/images/../test.txt". Útočníci tak mohou přistupovat k jakýmkoli souborům v adresáři „/var“, a nejen k souborům v „/var/images/“, například pro stažení protokolu nginx můžete odeslat požadavek „/img../log/ nginx/ access.log".
V konfiguracích, ve kterých hodnota direktivy alias nekončí znakem "/" (například "alias /var/images;"), se útočník nemůže změnit na nadřazený adresář, ale může požádat o jiný adresář ve /var. jehož jméno začíná na uvedenou v konfiguraci. Například žádostí o „/img.old/test.txt“ získáte přístup k adresáři „var/images.old/test.txt“.
Analýza úložišť na GitHubu ukázala, že chyby v konfiguraci nginx, které vedou k problému, se stále nacházejí ve skutečných projektech. Například přítomnost problému byla identifikována v backendu správce hesel Bitwarden a mohla být použita pro přístup ke všem souborům v adresáři /etc/bitwarden (požadavky na /attachments byly vydány z /etc/bitwarden/attachments/), včetně tam uložené databáze s hesly „vault. db“, certifikát a logy, na které stačilo odeslat požadavky „/attachments../vault.db“, „/attachments../identity.pfx“, „/attachments ../logs/api.log" atd. .P.
Metoda fungovala i s Google HPC Toolkit, kde byly /statické požadavky přesměrovány do adresáře „../hpc-toolkit/community/front-end/website/static/“. K získání databáze se soukromým klíčem a přihlašovacími údaji by útočník mohl odeslat dotazy „/static../.secret_key“ a „/static../db.sqlite3“.
Zdroj: opennet.ru