Unele servere cu nginx rămân vulnerabile la tehnica Nginx Alias Traversal, care a fost propusă la conferința Blackhat în 2018 și permite accesul la fișiere și directoare stocate în afara directorului rădăcină specificat în directiva «alias». Problema apare doar în configurațiile cu directiva «alias» plasată în interiorul blocului «location», al cărei parametru nu se încheie cu simbolul «/», în timp ce «alias» se încheie cu «/».
Sustenabilitatea problemei este că fișierele pentru blocurile cu directiva alias sunt livrate prin atașarea căii solicitate, după ce aceasta este corespunzătoare cu masca din directiva location și se elimină partea specificată în această mască. În exemplul de mai sus al configurației vulnerabile, un atacator poate solicita fișierul «/img.. /test.txt» și această solicitare va cădea sub masca specificată în location «/img», după care restul «.. /test.txt» va fi atașat la calea din directiva alias «/var /images/» și, în final, va fi solicitat fișierul «/var/images/.. /test.txt». Astfel, atacatorii pot accesa orice fișiere din directorul «/var», nu doar cele din «/var/images/», de exemplu, pentru a încărca logul nginx, se poate trimite o solicitare «/img.. /log/nginx/access.log».
În configurațiile în care valoarea directivei alias nu se încheie cu simbolul «/» (de exemplu, «alias /var/images;»), un atacator nu poate accesa directorul părinte, dar are posibilitatea de a solicita un alt director din /var, al cărui nume începe cu cel specificat în configurație. De exemplu, solicitând «/img.old/test.txt» se poate obține accesul la directorul «var/images.old/test.txt».
Analiza repositoariilor de pe GitHub a arătat că erorile de configurare care duc la această problemă sunt încă întâlnite în proiecte reale. De exemplu, problema a fost identificată în partea de server a managerului de parole Bitwarden și ar fi putut fi utilizată pentru a accesa toate fișierele din directorul /etc/bitwarden (solicitările /attachments erau livrate din /etc/bitwarden/attachments/), inclusiv baza de date stocată acolo «vault.db», certificatul și logurile, care puteau fi obținute prin trimiterea unor solicitări precum «/attachments.. /vault.db», «/attachments.. /identity.pfx», «/attachments.. /logs/api.log» etc.
Metoda a funcționat de asemenea cu Google HPC Toolkit, în care solicitările /static erau redirecționate în directorul «.. /hpc-toolkit/community/front-end/website/static/». Pentru a obține baza de date cu cheia privată și datele de autentificare, atacatorul putea trimite solicitările «/static.. /.secret_key» și «/static.. /db.sqlite3».
Sursa: opennet.ro
