Jotkut Nginx-palvelimet ovat edelleen haavoittuvia Nginx Alias Traversal -tekniikalle, jota ehdotettiin Blackhat-konferenssissa vuonna 2018 ja joka mahdollistaa pääsyn tiedostoihin ja hakemistoihin, jotka sijaitsevat "alias" -direktiivissä määritellyn juurihakemiston ulkopuolella. Ongelma ilmenee vain kokoonpanoissa, joissa "alias"-käsky on sijoitettu "location"-lohkon sisään, jonka parametri ei pääty "/"-merkkiin, kun taas "alias" päättyy "/".
Ongelman ydin on, että alias-direktiivin sisältävien lohkojen tiedostot palvellaan liittämällä pyydetty polku sen jälkeen, kun sitä on verrattu sijaintidirektiivin maskiin ja leikattu pois tässä maskissa määritetty osa polusta. Yllä esitetyn haavoittuvan kokoonpanon esimerkissä hyökkääjä voi pyytää tiedostoa "/img../test.txt", ja tämä pyyntö kuuluu sijainnissa määritetyn "/img"-maskin alle, minkä jälkeen jäljelle jäävä häntä ".. /test.txt” liitetään aliasdirektiivin ”/var/images/” polkuun ja pyytää lopulta tiedostoa ”/var/images/../test.txt”. Siten hyökkääjät voivat käyttää kaikkia "/var"-hakemiston tiedostoja, eivät vain tiedostoja "/var/images/", esimerkiksi ladataksesi nginx-lokin, voit lähettää pyynnön "/img../log/ nginx/ access.log".
Kokoonpanoissa, joissa alias-direktiivin arvo ei pääty "/"-merkkiin (esimerkiksi "alias /var/images;"), hyökkääjä ei voi vaihtaa päähakemistoon, mutta voi pyytää toista hakemistoa /varissa jonka nimi alkaa samalla määrityksessä määritellyllä. Esimerkiksi pyytämällä "/img.old/test.txt" pääset hakemistoon "var/images.old/test.txt".
GitHubin tietovarastojen analyysi osoitti, että nginx-kokoonpanon virheitä, jotka johtavat ongelmaan, esiintyy edelleen todellisissa projekteissa. Esimerkiksi ongelma tunnistettiin Bitwardenin salasananhallinnan taustaohjelmassa, ja sitä voitiin käyttää kaikkien /etc/bitwarden-hakemiston tiedostojen käyttämiseen (/attachments-pyynnöt lähetettiin /etc/bitwarden/attachments/), mukaan lukien "holvi". . db", varmenne ja lokit, joiden saamiseksi riitti lähettää pyynnöt "/attachments../vault.db", "/attachments../identity.pfx", "/attachments../logs/api.log " jne. .P.
Menetelmä toimi myös Google HPC Toolkitin kanssa, joka ohjasi /staattiset pyynnöt hakemistoon "../hpc-toolkit/community/front-end/website/static/". Saadakseen tietokannan yksityisellä avaimella ja tunnistetiedoilla hyökkääjä voi lähettää pyynnöt "/static../.secret_key" ja "/static../db.sqlite3".
Lähde: opennet.ru