Neki Nginx poslužitelji i dalje su ranjivi na tehniku Nginx Alias Traversal, koja je predložena na Blackhat konferenciji još 2018. i omogućuje pristup datotekama i direktorijima koji se nalaze izvan korijenskog direktorija navedenog u direktivi "alias". Problem se pojavljuje samo u konfiguracijama s direktivom "alias" smještenom unutar bloka "location" čiji parametar ne završava znakom "/", dok "alias" završava znakom "/".
Suština problema je u tome što se datoteke za blokove s alias direktivom poslužuju tako da se priloži tražena staza, nakon usporedbe s maskom iz direktive lokacije i izrezivanja dijela staze navedenog u ovoj maski. Za gore prikazan primjer ranjive konfiguracije, napadač može zatražiti datoteku “/img../test.txt” i taj će zahtjev potpasti pod masku “/img” navedenu u lokaciji, nakon čega će preostali rep “.. /test.txt” bit će priložen putanji iz direktive aliasa “/var/images/” i na kraju će zahtijevati datoteku “/var/images/../test.txt”. Dakle, napadači mogu pristupiti svim datotekama u direktoriju “/var”, a ne samo datotekama u “/var/images/”, na primjer, za preuzimanje nginx dnevnika možete poslati zahtjev “/img../log/ nginx/ access.log".
U konfiguracijama u kojima vrijednost direktive aliasa ne završava znakom "/" (na primjer, "alias /var/images;"), napadač se ne može prebaciti u nadređeni direktorij, ali može zatražiti drugi direktorij u /var čije ime počinje istim navedenim u konfiguraciji. Na primjer, zahtjevom za "/img.old/test.txt" možete pristupiti direktoriju "var/images.old/test.txt".
Analiza repozitorija na GitHubu pokazala je da se pogreške u konfiguraciji nginxa koje dovode do problema ipak pojavljuju u stvarnim projektima. Na primjer, problem je identificiran u pozadini Bitwarden upravitelja lozinkama i mogao se koristiti za pristup svim datotekama u direktoriju /etc/bitwarden (zahtjevi za /attachments izdani su iz /etc/bitwarden/attachments/), uključujući "trezor . db", certifikat i zapise, za čije je dobivanje bilo dovoljno poslati zahtjeve "/attachments../vault.db", "/attachments../identity.pfx", "/attachments../logs/api.log ", itd. .P.
Metoda je također funkcionirala s Google HPC Toolkitom, koji je /static zahtjeve preusmjeravao u direktorij "../hpc-toolkit/community/front-end/website/static/". Kako bi dobio bazu podataka s privatnim ključem i vjerodajnicama, napadač bi mogao poslati zahtjeve “/static../.secret_key” i “/static../db.sqlite3”.
Izvor: opennet.ru