Nginxi konfiguratsioonide haavatavus vale alias-bloki seadistamisega

Mõned nginx-serverid jäävad haavatavaks Nginx Alias Traversal tehnika suhtes, mis pakuti välja Blackhati konverentsil juba 2018. aastal ja võimaldab ligipääsu failidele ja kataloogidele, mis asuvad väljaspool juurkatalooge, mis on määratud alias direktiivis. Probleem ilmneb ainult konfigureerimistes, kus alias direktiiv asub location plokis, mille parameeter ei lõppe sümboliga " / ", samas kui alias lõppeb " / " .

Probleemi olemus seisneb selles, et alias direktiiviga plokkide failid antakse edasi, kui ühendatakse nõutud tee, pärast selle sobitamist location direktiivi malli ja eemaldades selle malli määratud tee osa. Ülaltoodud haavatava konfigureerimise näite puhul võib ründaja paluda faili " /img.. /test.txt " ja see päring langeb location malli " /img ", pärast mida jääb alles jõud " .. /test.txt " , mis kinnitatakse alias direktiivist " /var /images / " ja lõpuks kutsub üles faili " /var /images /.. /test.txt ". Seega võib ründaja saada ligipääsu mistahes failidele kataloogis " /var ", mitte ainult failidele " /var /images /", näiteks nginx logi allalaadimiseks võib saata päringu " /img.. /log /nginx /access.log ".

Konfigureerimistes, kus alias direktiivi väärtus ei lõppe sümboliga " / " (nt " alias /var /images; "), ei saa ründaja minna ülemisse katalooge, kuid tal on võimalus paluda teist katalooge, mille nimi algab konfigureeritud otsusega. Näiteks, paludes " /img.old /test.txt " , saab ligipääsu kataloogile " var /images.old /test.txt ".

GitHubis tehtud analüüs näitas, et probleemiga seotud vale konfiguratsioon nginxis esineb endiselt reaalselt toimivates projektides. Näiteks avastati probleem Bitwardeni paroolihalduri serveripoolel, mis oleks võinud võimaldada ligipääsu kõigile failidele kataloogis " /etc /bitwarden" (päringud " /attachments" anti edasi kataloogist " /etc /bitwarden /attachments / "), sealhulgas seal hoitavale paroolide andmebaasile " vault.db ", sertifikaadile ja logidele, mille saamiseks piisab päringute saatmisest " /attachments.. /vault.db ", " /attachments.. /identity.pfx ", " /attachments.. /logs /api.log " jne.

Meetod töötas samuti Google HPC Toolkiti puhul, kus päringud " /static " suunati katalooge " .. /hpc-toolkit /community /front-end /website /static / ". Salajase võtme ja autentimisteabe andmebaasi saamiseks võis ründaja saata päringud " /static.. / .secret_key " ja " /static.. /db.sqlite3 ".

Allikas: opennet.ru