Kwetsbaarheid van Nginx-configuraties met onjuiste aliasblokinstellingen.

Sommige servers met nginx blijven kwetsbaar voor de techniek Nginx Alias Traversal, die op de Blackhat-conferentie in 2018 werd gepresenteerd en toegang biedt tot bestanden en mappen die buiten de rootdirectory liggen die is ingesteld in de ‘alias’-directive. Het probleem komt alleen voor in configuraties waarbij de ‘alias’-directive binnen een ‘location’-blok is geplaatst en de parameter niet eindigt op het teken ‘/’, terwijl ‘alias’ eindigt op ‘/’.

De kern van het probleem is dat bestanden voor blokken met de alias-directive worden geleverd via het toevoegen van het opgevraagde pad, na het vergelijken met het masker van de ‘location’-directive en het knippen van het gedeelte van het pad dat in dit masker is gedefinieerd. Voor het hierboven getoonde voorbeeld van een kwetsbare configuratie kan een aanvaller het bestand ‘/img../test.txt’ opvragen en dit verzoek valt onder het opgegeven masker van ‘location’ ‘/img’, waarna het resterende gedeelte ‘../test.txt’ zal worden toegevoegd aan het pad van de alias-directive ‘/var/images/’, en uiteindelijk wordt het bestand ‘/var/images/../test.txt’ opgevraagd. Zo kan een aanvaller toegang krijgen tot elk bestand in de ‘/var’-directory, niet alleen tot de bestanden in ‘/var/images/’, bijvoorbeeld om de nginx-logboek te downloaden kan het verzoek ‘/img../log/nginx/access.log’ worden verzonden.

In configuraties waarin de waarde van de alias-directive niet eindigt op het teken ‘/’ (bijvoorbeeld ‘alias /var/images;’), kan de aanvaller niet naar de bovenliggende directory gaan, maar heeft wel de mogelijkheid om een andere directory in ‘/var’ op te vragen, waarvan de naam begint met hetgeen in de configuratie is opgegeven. Bijvoorbeeld, door ‘/img.old/test.txt’ op te vragen, kan toegang worden verkregen tot de directory ‘var/images.old/test.txt’.

Analyse van repositories op GitHub heeft aangetoond dat de fouten in de nginx-configuratie die leiden tot dit probleem nog steeds voorkomen in echte projecten. Bijvoorbeeld, het probleem werd ontdekt in de serverzijde van de wachtwoordmanager Bitwarden en kon worden gebruikt om toegang te krijgen tot alle bestanden in de directory ‘/etc/bitwarden’ (verzoeken naar ‘/attachments’ werden geleverd vanuit ‘/etc/bitwarden/attachments/’), inclusief de daar opgeslagen database met wachtwoorden ‘vault.db’, certificaten en logboeken, waarvoor eenvoudigweg het verzenden van verzoeken ‘/attachments../vault.db’, ‘/attachments../identity.pfx’, ‘/attachments../logs/api.log’ enzovoort voldoende was.

De methode werkte ook met de Google HPC Toolkit, waarin verzoeken naar ‘/static’ werden omgeleid naar de directory ‘../hpc-toolkit/community/front-end/website/static/’. Voor toegang tot de database met de geheime sleutel en inloggegevens kon een aanvaller verzoeken sturen naar ‘/static../.secret_key’ en ‘/static../db.sqlite3’.

Bron: opennet.ru