Sårbarhet i Nginx-konfigurationer med felaktiga alias-inställningar

Vissa servrar med nginx förblir sårbara för tekniken Nginx Alias Traversal, som presenterades på Blackhat-konferensen redan 2018, och som gör det möjligt att få åtkomst till filer och kataloger som ligger utanför den angivna rotkatalogen i 'alias'-direktivet. Problemet uppstår endast i konfigurationer där 'alias'-direktivet ligger inom en 'location'-block, och där parametern inte avslutas med tecknet '⁄', medan 'alias' avslutas med '⁄'.

Problemet ligger i att filer för block med 'alias'-direktivet levereras genom att den begärda sökvägen bifogas, efter att den matchats med mönstret i 'location'-direktivet och den angivna delen av sökvägen skärs bort. I det ovanstående exemplet med en sårbar konfiguration kan en angripare begära filen '⁄img..⁄test.txt' och denna begäran kommer att passa in under det angivna mönstret i location '⁄img', varefter den kvarstående svansen '..⁄test.txt' kommer att bifogas till sökvägen från 'alias'-direktivet '⁄var⁄images⁄', och slutligen kommer filen '⁄var⁄images⁄..⁄test.txt' att begäras. På så sätt kan angripare få åtkomst till alla filer i katalogen '⁄var', och inte bara filer i '⁄var⁄images⁄', till exempel för att ladda loggar från nginx kan en förfrågan som '⁄img..⁄log⁄nginx⁄access.log' skickas.

I konfigurationer där värdet för 'alias'-direktivet inte avslutas med tecknet '⁄' (till exempel 'alias ⁄var⁄images;'), kan angriparen inte navigera till föräldrakatalogen, men kan begära en annan katalog i ⁄var vars namn börjar med det angivna i konfigurationen. Till exempel kan en begäran om '⁄img.old⁄test.txt' ge åtkomst till katalogen 'var⁄images.old⁄test.txt'.

Analys av repositorier på GitHub har visat att de konfigurationsfel som leder till problemet fortfarande förekommer i verkliga projekt. Till exempel har problemet identifierats i backend-delen av lösenordshanteraren Bitwarden, vilket kan ha använts för att få åtkomst till alla filer i katalogen ⁄etc⁄bitwarden (begärningar om ⁄attachments lämnades ut från ⁄etc⁄bitwarden⁄attachments⁄), inklusive den lagrade databasen med lösenord 'vault.db', certifikatet och loggarna, vars åtkomst bara krävde att man skickade förfrågningar som '⁄attachments..⁄vault.db', '⁄attachments..⁄identity.pfx', '⁄attachments..⁄logs⁄api.log' osv.

Metoden fungerade också med Google HPC Toolkit, där förfrågningar /static omdirigerades till katalogen «.. /hpc-toolkit /community /front-end /website /static /». För att få en databas med hemlig nyckel och autentiseringsuppgifter kunde angriparen skicka förfrågningar «/static.. /.secret_key» och «/static.. /db.sqlite3».

Källa: opennet.ru