Některé servery s nginx zůstávají zranitelné vůči technice Nginx Alias Traversal, která byla představena na konferenci Blackhat již v roce 2018 a umožňuje přístup k souborům a adresářům umístěným mimo kořenový adresář určovaný v direktivě „alias“. Problém se projevuje pouze v konfiguracích s direktivou „alias“, umístěnou uvnitř bloku „location“, jejíž parametr nekončí znakem „/“, přičemž „alias“ končí na „/“.
Podstatou problému je, že soubory pro bloky s direktivou alias jsou dodávány prostřednictvím připojení požadované cesty, poté co je porovnána s maskou z direktivy location a je vyříznuta část cesty specifikovaná v této masce. Pro zobrazený výše příklad zranitelné konfigurace může útočník požadovat soubor „/img../test.txt“ a tento požadavek spadá pod uvedenou masku location „/img“, po čemž zbývající část „../test.txt“ bude připojena k cestě z direktivy alias „/var/images/“ a nakonec bude požadován soubor „/var/images/../test.txt“. Tímto způsobem se útočníkům může dostat přístup k jakýmkoli souborům v adresáři „/var“, a to nejen k souborům v „/var/images/“, například pro stažení logu nginx může být odeslán požadavek „/img../log/nginx/access.log“.
V konfiguracích, kde hodnota direktivy alias nekončí znakem „/“ (například „alias /var/images;“), útočník nemůže přejít do nadřazeného adresáře, ale má možnost požadovat jiný adresář v /var, jehož název začíná na uvedený v konfiguraci. Například požadováním „/img.old/test.txt“ lze získat přístup k adresáři „var/images.old/test.txt“.
Analýza repozitářů na GitHubu ukázala, že chyby v konfiguraci nginx vedoucí k tomuto problému se stále objevují v reálných projektech. Například byla zjištěna chyba na serverové části správce hesel Bitwarden, která mohla být využita pro přístup ke všem souborům v adresáři /etc/bitwarden (požadavky /attachments byly vraceny z /etc/bitwarden/attachments/), včetně uložené tam DB s hesly „vault.db“, certifikátu a logů, které stačilo získat odesláním požadavků „/attachments../vault.db“, „/attachments../identity.pfx“, „/attachments../logs/api.log“ a podobně.
Metoda také fungovala s Google HPC Toolkit, ve kterém byly požadavky /static přesměrovány do adresáře „../hpc-toolkit/community/front-end/website/static/“. Pro získání DB s tajným klíčem a přihlašovacími údaji mohl útočník odeslat požadavky „/static../.secret_key“ a „/static../db.sqlite3“.
Zdroj: opennet.ru
