Niektoré servery s nginx zostávajú zraniteľné voči technike Nginx Alias Traversal, ktorá bola navrhnutá na konferencii Blackhat v roku 2018 a umožňuje prístup k súborom a adresárom umiestneným mimo koreňového adresára špecifikovaného v smernici „alias“. Problém nastáva len v konfiguráciách s direktívou „alias“ umiestnenou vo vnútri bloku „location“, ktorej parameter nekončí znakom „/“, kým „alias“ končí „/“.
Podstata problému je v tom, že súbory pre bloky s aliasovou direktívou sú dané pripojením požadovanej cesty, po jej spárovaní s maskou z lokačnej direktívy a vyrezaní časti cesty uvedenej v tejto maske. V príklade zraniteľnej konfigurácie zobrazenej vyššie si útočník môže vyžiadať súbor „/img../test.txt“ a táto požiadavka bude zodpovedať maske špecifikovanej v umiestnení „/img“, po ktorej bude zostávajúci koniec „../ test.txt" bude pripojený k ceste z aliasovej direktívy "/var/images/" a v dôsledku toho sa bude vyžadovať súbor "/var/images/../test.txt". Útočníci tak môžu pristupovať k akýmkoľvek súborom v adresári „/var“, a nielen k súborom v „/var/images/“, napríklad na stiahnutie protokolu nginx môžete poslať požiadavku „/img../log/ nginx/ access.log“.
V konfiguráciách, v ktorých hodnota direktívy alias nekončí znakom "/" (napríklad "alias /var/images;"), sa útočník nemôže zmeniť na nadradený adresár, ale môže požiadať o iný adresár vo /var ktorého názov začína na špecifikované v konfigurácii. Napríklad vyžiadaním "/img.old/test.txt" získate prístup k adresáru "var/images.old/test.txt".
Analýza úložísk na GitHub ukázala, že chyby v konfigurácii nginx, ktoré vedú k problému, sa stále nachádzajú v skutočných projektoch. Napríklad prítomnosť problému bola identifikovaná v backende správcu hesiel Bitwarden a mohla byť použitá na prístup ku všetkým súborom v adresári /etc/bitwarden (žiadosti o /prílohy boli vydané z /etc/bitwarden/attachments/), vrátane tam uloženej databázy s heslami „vault. db“, certifikátom a protokolmi, na ktoré stačilo zaslať požiadavky „/attachments../vault.db“, „/attachments../identity.pfx“, „/attachments ../logs/api.log" atď. .P.
Metóda fungovala aj s Google HPC Toolkit, kde boli /statické požiadavky presmerované do adresára "../hpc-toolkit/community/front-end/website/static/". Na získanie databázy so súkromným kľúčom a povereniami by útočník mohol odoslať dopyty „/static../.secret_key“ a „/static../db.sqlite3“.
Zdroj: opennet.ru