Nginx-configuratiekwetsbaarheid met onjuiste aliasblokinstellingen

Sommige servers met nginx blijven kwetsbaar voor de Nginx Alias ​​​​Traversal-techniek, die werd voorgesteld op de Blackhat-conferentie in 2018 en die toegang geeft tot bestanden en mappen die zich buiten de hoofdmap bevinden die is gespecificeerd in de "alias" -richtlijn. Het probleem doet zich alleen voor in configuraties met een "alias"-richtlijn geplaatst in het "location"-blok, waarvan de parameter niet eindigt met een "/"-teken, terwijl "alias" eindigt met "/".

Nginx-configuratiekwetsbaarheid met onjuiste aliasblokinstellingen

De essentie van het probleem is dat bestanden voor blokken met de aliasrichtlijn worden gegeven door het gevraagde pad toe te voegen, nadat het is vergeleken met het masker van de locatierichtlijn en het deel van het pad dat in dit masker is gespecificeerd, is weggelaten. Voor het hierboven getoonde voorbeeld van een kwetsbare configuratie kan een aanvaller het bestand "/img../test.txt" opvragen en dit verzoek komt overeen met het masker dat is opgegeven in locatie "/img", waarna de resterende staart "../ test.txt" wordt toegevoegd aan het pad van de aliasrichtlijn "/var/images/" en als resultaat wordt het bestand "/var/images/../test.txt" opgevraagd. Zo hebben aanvallers toegang tot alle bestanden in de map "/var", en niet alleen bestanden in "/var/images/". Om bijvoorbeeld het nginx-logboek te downloaden, kunt u het verzoek "/img../log/ nginx/access.log".

In configuraties waarin de waarde van de aliasopdracht niet eindigt met een "/"-teken (bijvoorbeeld "alias /var/images;"), kan de aanvaller niet naar de bovenliggende map gaan, maar kan hij een andere map aanvragen in /var waarvan de naam begint met gespecificeerd in de configuratie. Door bijvoorbeeld "/img.old/test.txt" op te vragen, krijgt u toegang tot de map "var/images.old/test.txt".

Een analyse van de repositories op GitHub toonde aan dat fouten in de nginx-configuratie die tot het probleem hebben geleid, nog steeds worden gevonden in echte projecten. Er werd bijvoorbeeld de aanwezigheid van een probleem gedetecteerd in de backend van de Bitwarden-wachtwoordbeheerder en dit kon worden gebruikt om toegang te krijgen tot alle bestanden in de map /etc/bitwarden (aanvragen voor /attachments werden gedaan vanuit /etc/bitwarden/attachments/), inclusief de database die daar is opgeslagen met wachtwoorden "vault. db", certificaat en logs, waarvoor het voldoende was om verzoeken te verzenden "/attachments../vault.db", "/attachments../identity.pfx", "/attachments ../logs/api.log", enz. .P.

Nginx-configuratiekwetsbaarheid met onjuiste aliasblokinstellingen
Nginx-configuratiekwetsbaarheid met onjuiste aliasblokinstellingen

De methode werkte ook met de Google HPC Toolkit, waar /static verzoeken werden omgeleid naar de "../hpc-toolkit/community/front-end/website/static/" directory. Om een ​​database met een persoonlijke sleutel en inloggegevens te verkrijgen, kan een aanvaller query's "/static../.secret_key" en "/static../db.sqlite3" verzenden.

Nginx-configuratiekwetsbaarheid met onjuiste aliasblokinstellingen


Bron: opennet.ru

Voeg een reactie