Nginx-konfigurationssårbarhed med forkerte aliasblokindstillinger

Nogle servere med nginx forbliver sårbare over for Nginx Alias ​​​​Traversal-teknikken, som blev foreslået på Blackhat-konferencen tilbage i 2018 og giver adgang til filer og mapper, der er placeret uden for rodmappen, der er angivet i "alias"-direktivet. Problemet opstår kun i konfigurationer med et "alias"-direktiv placeret inde i "location"-blokken, hvis parameter ikke ender med et "/"-tegn, mens "alias" slutter med "/".

Nginx-konfigurationssårbarhed med forkerte aliasblokindstillinger

Essensen af ​​problemet er, at filer til blokke med aliasdirektivet gives ved at vedhæfte den anmodede sti, efter at den er matchet med masken fra lokationsdirektivet og udskåret den del af stien, der er specificeret i denne maske. For eksemplet med en sårbar konfiguration vist ovenfor, kan en angriber anmode om filen "/img../test.txt", og denne anmodning vil matche masken angivet i lokationen "/img", hvorefter den resterende hale "../test.txt" vil blive knyttet til stien fra aliasdirektivet "/var/images/" og som et resultat filen "/var/request.images.txt". Således kan angribere få adgang til alle filer i "/var"-mappen, og ikke kun filer i "/var/images/", for eksempel for at downloade nginx-loggen, du kan sende anmodningen "/img../log/nginx/access.log".

I konfigurationer, hvor værdien af ​​aliasdirektivet ikke slutter med et "/"-tegn (for eksempel "alias /var/images;"), kan angriberen ikke skifte til det overordnede bibliotek, men kan anmode om en anden mappe i /var, hvis navn begynder med det, der er angivet i konfigurationen. For eksempel, ved at anmode om "/img.old/test.txt" kan du få adgang til mappen "var/images.old/test.txt".

En analyse af depoterne på GitHub viste, at fejl i nginx-konfigurationen, der fører til problemet, stadig findes i rigtige projekter. For eksempel blev tilstedeværelsen af ​​et problem opdaget i backend af Bitwarden password manager og kunne bruges til at få adgang til alle filer i /etc/bitwarden mappen (anmodninger om /attachments blev udstedt fra /etc/bitwarden/attachments/), inklusive databasen gemt der med adgangskoder "vault.db", et certifikat og logfiler, som det var nok til send./attachd.b.ident./ ity.pfx”, “/atta chments../logs/api.log” osv.

Nginx-konfigurationssårbarhed med forkerte aliasblokindstillinger
Nginx-konfigurationssårbarhed med forkerte aliasblokindstillinger

Metoden fungerede også med Google HPC Toolkit, hvor /static-anmodninger blev omdirigeret til mappen "../hpc-toolkit/community/front-end/website/static/". For at få en database med en privat nøgle og legitimationsoplysninger kan en angriber sende forespørgsler "/static../.secret_key" og "/static../db.sqlite3".

Nginx-konfigurationssårbarhed med forkerte aliasblokindstillinger


Kilde: opennet.ru

Tilføj en kommentar