Nginx-konfigurasiekwesbaarheid met verkeerde aliasblokinstellings

Sommige bedieners met nginx bly kwesbaar vir die Nginx Alias ​​​​Traversal-tegniek, wat tydens die Blackhat-konferensie in 2018 voorgestel is en toegang verleen tot lêers en gidse wat buite die wortelgids gespesifiseer is in die "alias"-riglyne. Die probleem verskyn slegs in konfigurasies met 'n "alias"-instruksie wat binne die "location"-blok geplaas is, waarvan die parameter nie eindig met 'n "/"-karakter nie, terwyl "alias" eindig met "/".

Nginx-konfigurasiekwesbaarheid met verkeerde aliasblokinstellings

Die kern van die probleem is dat lêers vir blokke met die alias-aanwysing gegee word deur die aangevraagde pad aan te heg, nadat dit met die masker van die ligging-aanwysing gepas is en die deel van die pad wat in hierdie masker gespesifiseer is, uitgesny word. Vir die voorbeeld van 'n kwesbare konfigurasie wat hierbo gewys word, kan 'n aanvaller die lêer "/img../test.txt" aanvra en hierdie versoek sal ooreenstem met die masker gespesifiseer in ligging "/img", waarna die oorblywende stert "../ test.txt" sal aan die pad van die alias-direktief "/var/images/" geheg word en gevolglik sal die lêer "/var/images/../test.txt" aangevra word. So, aanvallers kan toegang verkry tot enige lêers in die "/var" gids, en nie net lêers in "/var/images/", byvoorbeeld, om die nginx log af te laai, kan jy die versoek stuur "/img../log/ nginx/ access.log".

In konfigurasies waarin die waarde van die alias-instruksie nie met 'n "/"-karakter eindig nie (byvoorbeeld, "alias /var/images;"), kan die aanvaller nie na die ouergids verander nie, maar kan 'n ander gids in /var versoek. wie se naam begin met gespesifiseer in die konfigurasie. Byvoorbeeld, deur "/img.old/test.txt" te versoek, kan jy toegang tot die gids "var/images.old/test.txt" kry.

'n Ontleding van die bewaarplekke op GitHub het getoon dat foute in die nginx-konfigurasie wat tot die probleem lei, steeds in werklike projekte gevind word. Die teenwoordigheid van 'n probleem is byvoorbeeld in die agterkant van die Bitwarden-wagwoordbestuurder geïdentifiseer en kan gebruik word om toegang te verkry tot alle lêers in die /etc/bitwarden-gids (versoeke vir /aanhangsels is uitgereik vanaf /etc/bitwarden/attachments/), insluitend die databasis wat daar gestoor is met wagwoorde "vault. db", sertifikaat en logs, waarvoor dit genoeg was om versoeke "/attachments../vault.db", "/attachments../identity.pfx", "/attachments" te stuur ../logs/api.log", ens. .P.

Nginx-konfigurasiekwesbaarheid met verkeerde aliasblokinstellings
Nginx-konfigurasiekwesbaarheid met verkeerde aliasblokinstellings

Die metode het ook gewerk met die Google HPC Toolkit, waar /static-versoeke na die "../hpc-toolkit/community/front-end/website/static/"-gids herlei is. Om 'n databasis met 'n private sleutel en geloofsbriewe te verkry, kan 'n aanvaller navrae "/static../.secret_key" en "/static../db.sqlite3" stuur.

Nginx-konfigurasiekwesbaarheid met verkeerde aliasblokinstellings


Bron: opennet.ru

Voeg 'n opmerking