Nogle servere med Nginx forbliver sårbare over for Nginx Alias Traversal-teknikken, der blev præsenteret på Blackhat-konferencen i 2018, og som muliggør adgang til filer og mapper placeret uden for rodmappen angivet i "alias"-direktivet. Problemet opstår kun i konfigurationer med et "alias"-direktiv placeret inden for en "location"-blok, hvor параметret ikke slutter på et tegn "\/", mens "alias" slutter på "\/".
Kernen i problemet er, at filer for blokke med "alias"-direktivet leveres via vedhæftning af den anmodede sti, efter at den er matchet med masken fra "location"-direktivet og det angivne parti af stien er skåret bort. For det viste eksempel på den sårbare konfiguration kan en angriber anmode om filen "\/img..\/test.txt", og denne anmodning vil falde ind under den i "location"-masken angivne "\/img", hvorefter den tilbageværende slutning "..\/test.txt" vil blive vedhæftet stien fra "alias"-direktivet "\/var\/images\/" og i sidste ende vil filen "\/var\/images\/..\/test.txt" blive anmodet. Dermed kan angriberen få adgang til filer i "\/var"-mappen og ikke kun til filer i "\/var\/images\/", for eksempel kan anmodningen "\/img..\/log\/nginx\/access.log" bruges til at hente nginx-loggen.
I konfigurationer, hvor værdien af "alias"-direktivet ikke slutter med tegnet "\/" (for eksempel "alias \/var\/images;"), kan angriberen ikke navigere til forældre-mappen, men har mulighed for at anmode om en anden mappe i \/var, hvis navn starter med det, der er angivet i konfigurationen. For eksempel kan anmodningen "\/img.old\/test.txt" give adgang til mappen "var\/images.old\/test.txt".
Analyse af repositories på GitHub har vist, at fejlene i Nginx-konfigurationen, der fører til problemet, stadig forekommer i virkelige projekter. For eksempel blev problemet identificeret i serverdelen af password manageren Bitwarden og kunne bruges til at få adgang til alle filer i mappen \/etc\/bitwarden (anmodninger om \/attachments blev leveret fra \/etc\/bitwarden\/attachments\/), inklusive databasen "vault.db" med adgangskoder, certifikatet og loggene, som kunne hentes ved blot at sende anmodningerne "\/attachments..\/vault.db", "\/attachments..\/identity.pfx", "\/attachments..\/logs\/api.log" osv.
Metoden fungerede også med Google HPC Toolkit, hvor anmodningerne /static blev omdirigeret til kataloget "../hpc-toolkit/community/front-end/website/static/". For at få adgang til databasen med den private nøgle og legitimationsoplysningerne kunne angriberen sende anmodningerne " /static../.secret_key" og "/static../db.sqlite3".
Kilde: opennet.ru
