Nginx AliasTraversal är fortfarande ett kritiskt problem för många projekt
Nyligen bröt nyheten ut det vissa nginx-servrar är fortfarande sårbara för Tekniken "Nginx AliasTraversal», som föreslogs vid Blackhat-konferensen 2018 och ger åtkomst till filer och kataloger som finns utanför rotkatalogen som anges i aliasdirektivet.
Kärnan i problemet är det filer för block med aliasdirektivet tillhandahålls genom att bifoga den begärda sökvägen, efter att ha matchat den med masken för platsdirektivet och skär av den del av sökvägen som anges i denna mask.
Problemet dyker upp endast i konfigurationer med ett "alias"-direktiv, som i Nginx-konfigurationen finns det ett direktiv som heter 'plats' som kan beskriva hur åtkomst till en viss URL ska hanteras, och används ofta för att tilldela URL:er till filer på servern.
I mönstret som använder den här platsen i kombination med aliaset är det avgörande när de två villkoren "sätt inte ett snedstreck i slutet av webbadressen som anges av platsen" och "lägg ett snedstreck i slutet av den angivna sökvägen" av alias' är uppfyllda. alias ' är uppfyllda. Sårbarhet sägs förekomma.
På BlackHat 2018-konferensen presenterade Orange Tsai sin forskning om att bryta URL-tolkar. Bland andra imponerande fynd demonstrerade han en teknik som upptäcktes i en HCTF CTF-utmaning 2016, skapad av @iaklis.
För att tekniken ska vara tillämplig måste följande villkor vara uppfyllda:
Platsdirektivet får inte ha ett snedstreck i sin väg;
Ett aliasdirektiv måste finnas i platssammanhanget och måste sluta med ett snedstreck.
För exemplet med en sårbar konfiguration som visas ovan kan en angripare begära filen "/img../test.txt" och denna begäran kommer att matcha masken som anges på platsen "/img", varefter kön De återstående ". ./test.txt" kommer att läggas till aliasdirektivets sökväg "/var/images/" och som ett resultat kommer filen "/var/images/../test.txt" att begäras.
Således kan angripare komma åt vilken fil som helst i "/var"-katalogen, inte bara filer i "/var/images/", till exempel för att ladda ner nginx-loggen kan du skicka begäran "/img ../log/nginx /access.log”.
En analys från arkiv på GitHub visade att felen i nginx-konfigurationen som leder till problemet fortfarande finns i verkliga projekt.
Till exempel hittades ett problem i Bitwarden lösenordshanterarens backend och kunde användas för att komma åt alla filer i /etc/bitwarden-katalogen (förfrågningar om /attachments utfärdades från /etc/bitwarden/attachments/), inklusive databasen som lagrats där med lösenord "vault.db", certifikat och loggar, för vilka det räckte att skicka förfrågningar "vault.db", "identity.pfx", "api.log", etc.
Det nämns det svårighetsgraden av denna sårbarhet kan variera avsevärt beroende på projektet, från en försumbar påverkan till en kritisk. Omfattningen av dess påverkan bestäms i första hand av om den exponerade katalogen innehåller känsliga uppgifter som kan underlätta ytterligare attacker eller leda till att privat information avslöjas.
Som en utgångspunkt i vårt sökande efter denna sårbarhet valde vi att utforska de populära GitHub-arkiven som visade det här problemet. Att identifiera denna specifika sårbarhet i miljöer med tillgång till källkoden blir betydligt mer genomförbart, främst på grund av två huvudfaktorer:
Detektion – Genom att använda enkla kodanalysverktyg, som sökningar i reguljära uttryck, kan vi effektivt identifiera potentiellt sårbara Nginx-konfigurationsfiler inom dessa projekt.
Exploatering: Genom att känna till den exakta målkatalogen som har tilldelats ett alias kan vi skapa en lokal instans, undersöka de aliasade katalogerna med hjälp av ett lokalt skal och avgöra vilka filer som kan nås genom sårbarheten.
Det är värt att nämna att metoden även fungerade med Google HPC Toolkit, där förfrågningar omdirigerades till katalogen av intresse för att få en databas med en privat nyckel och referenser, en angripare kunde skicka "secret_key" och "db.sqlite3" frågor.
Slutligen, om du är intresserad av att veta mer om det, kan du konsultera detaljerna I följande länk.