Nginx
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Dobijte perspektivu hakera o vašim veb aplikacijama, mreži i oblaku
Pronađite i prijavite kritične, iskoristive ranjivosti sa stvarnim poslovnim uticajem. Koristite naših 20+ prilagođenih alata za mapiranje napadačke površine, pronalaženje bezbednosnih problema koji vam omogućavaju da eskalirate privilegije, i koristite automatizovane eksploate za prikupljanje suštinskih dokaza, pretvarajući vaš trud u uverljive izveštaje.
Kada konfigurišete Nginx server, root direktiva igra ključnu ulogu definišući osnovni direktorijum iz kojeg se serviraju fajlovi. Razmotrite primer ispod:
U ovoj konfiguraciji, /etc/nginx je označen kao korenski direktorijum. Ova postavka omogućava pristup datotekama unutar specificiranog korenskog direktorijuma, kao što je /hello.txt. Međutim, važno je napomenuti da je definisana samo specifična lokacija (/hello.txt). Nema konfiguracije za korensku lokaciju (location / {...}). Ova propuštena konfiguracija znači da se korenska direktiva primenjuje globalno, omogućavajući zahteve za korenskim putem / da pristupe datotekama pod /etc/nginx.
Kritična bezbednosna razmatranja proizilaze iz ove konfiguracije. Jednostavan GET zahtev, poput GET /nginx.conf, mogao bi otkriti osetljive informacije tako što bi poslužio Nginx konfiguracionu datoteku smeštenu na /etc/nginx/nginx.conf. Postavljanje korena na manje osetljiv direktorijum, poput /etc, moglo bi smanjiti ovaj rizik, ali i dalje može omogućiti nepredviđeni pristup drugim kritičnim datotekama, uključujući druge konfiguracione datoteke, logove pristupa, pa čak i šifrovane akreditive korišćene za HTTP osnovnu autentifikaciju.
U konfiguracionim datotekama Nginx-a, neophodno je pažljivo pregledati "location" direktive. Ranljivost poznata kao Local File Inclusion (LFI) može biti nenamerno uvedena kroz konfiguraciju koja podseća na sledeću:
Ova konfiguracija je podložna LFI napadima zbog toga što server interpretira zahteve poput /imgs../flag.txt kao pokušaj pristupa datotekama van predviđene direktorijuma, što se efektivno rešava na /path/images/../flag.txt. Ova greška omogućava napadačima da preuzmu datoteke iz datotečnog sistema servera koje ne bi trebale biti dostupne putem veba.
Da bi se ublažila ova ranjivost, konfiguracija bi trebala biti prilagođena na:
Više informacija: https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/
Accunetix testovi:
Proverite sledeću stranicu da biste saznali kako da zaobiđete direktive kao što su:
Ranljive varijable $uri i $document_uri i ovo se može ispraviti zamenom sa $request_uri.
Regex može takođe biti ranjiv kao:
location ~ /docs/([^/])? { … $1 … } - Ranljivo
location ~ /docs/([^/\s])? { … $1 … } - Nije ranjivo (proverava razmake)
location ~ /docs/(.*)? { … $1 … } - Nije ranjivo
Ranjivost u Nginx konfiguraciji je prikazana u sledećem primeru:
Karakteri \r (Carriage Return) i \n (Line Feed) označavaju nove linije u HTTP zahtevima, a njihovi URL-enkodirani oblici predstavljeni su kao %0d%0a. Uključivanje ovih karaktera u zahtev (npr., http://localhost/%0d%0aDetectify:%20clrf) na pogrešno konfigurisanoj serveru rezultira time da server izdaje novi header pod nazivom Detectify. To se dešava zato što $uri varijabla dekodira URL-enkodirane nove linije, što dovodi do neočekivanog headera u odgovoru:
Saznajte više o rizicima CRLF injekcije i deljenja odgovora na https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.
Takođe, ova tehnika je objašnjena u ovom predavanju sa nekim ranjivim primerima i mehanizmima detekcije. Na primer, da biste otkrili ovu pogrešnu konfiguraciju iz perspektive crne kutije, mogli biste koristiti ove zahteve:
https://example.com/%20X - Bilo koji HTTP kod
https://example.com/%20H - 400 Bad Request
Ako je ranjiv, prvi će se vratiti kao "X" je bilo koja HTTP metoda, a drugi će vratiti grešku jer H nije važeća metoda. Tako će server primiti nešto poput: GET / H HTTP/1.1 i to će izazvati grešku.
Drugi primeri detekcije bi bili:
http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x - Bilo koji HTTP kod
http://company.tld/%20HTTP/1.1%0D%0AHost:%20x - 400 Bad Request
Neke pronađene ranjive konfiguracije predstavljene u tom predavanju su:
Obratite pažnju kako je $uri postavljen kao što jeste u konačnom URL-u.
Obratite pažnju kako je ponovo $uri u URL-u (ovog puta unutar parametra)
Sada u AWS S3
Otkriveno je da podaci koje unosi korisnik mogu biti tretirani kao Nginx varijabla pod određenim okolnostima. Uzrok ovog ponašanja ostaje donekle nejasan, ali nije retko niti jednostavno za verifikaciju. Ova anomalija je istaknuta u bezbednosnom izveštaju na HackerOne, koji se može pogledati ovde. Dalja istraga o poruci greške dovela je do identifikacije njenog pojavljivanja unutar SSI filter modula Nginx-ove kodne baze, ukazujući na Server Side Includes (SSI) kao osnovni uzrok.
Da bi se otkrila ova pogrešna konfiguracija, može se izvršiti sledeća komanda, koja uključuje postavljanje referer zaglavlja za testiranje štampanja varijable:
Skeneri za ovu pogrešnu konfiguraciju širom sistema otkrili su više instanci gde su Nginx varijable mogle biti štampane od strane korisnika. Međutim, smanjenje broja ranjivih instanci sugeriše da su napori za ispravku ovog problema bili donekle uspešni.
Nginx nudi funkciju kroz proxy_pass koja omogućava presretanje grešaka i HTTP zaglavlja koja proizvodi backend, sa ciljem da sakrije interne poruke o greškama i zaglavlja. To se postiže tako što Nginx služi prilagođene stranice grešaka kao odgovor na greške backend-a. Međutim, izazovi se javljaju kada Nginx naiđe na nevažeći HTTP zahtev. Takav zahtev se prosleđuje backend-u onako kako je primljen, a sirovi odgovor backend-a se zatim direktno šalje klijentu bez intervencije Nginx-a.
Razmotrite primer scenarija koji uključuje uWSGI aplikaciju:
Da bi se to upravljalo, koriste se specifične direktive u Nginx konfiguraciji:
proxy_intercept_errors: Ova direktiva omogućava Nginxu da poslužuje prilagođeni odgovor za odgovore sa pozadinskog sistema koji imaju status kod veći od 300. Osigurava da, za naš primer uWSGI aplikacije, 500 Error odgovor bude presretnut i obrađen od strane Nginxa.
proxy_hide_header: Kao što ime sugeriše, ova direktiva skriva određene HTTP zaglavlja od klijenta, poboljšavajući privatnost i sigurnost.
Kada se izvrši važeći GET zahtev, Nginx ga obrađuje normalno, vraćajući standardni odgovor o grešci bez otkrivanja bilo kakvih tajnih zaglavlja. Međutim, nevažeći HTTP zahtev zaobilazi ovaj mehanizam, što rezultira izlaganjem sirovih odgovora sa pozadinskog sistema, uključujući tajna zaglavlja i poruke o grešci.
Podrazumevano, Nginxova merge_slashes direktiva je postavljena na on, što kompresuje više uzastopnih kose crte u URL-u u jednu kosu crtu. Ova funkcija, iako pojednostavljuje obradu URL-a, može nenamerno prikriti ranjivosti u aplikacijama iza Nginxa, posebno onima koje su podložne napadima lokalnog uključivanja datoteka (LFI). Stručnjaci za bezbednost Danny Robinson i Rotem Bar su istakli potencijalne rizike povezane sa ovim podrazumevanjem, posebno kada Nginx deluje kao obrnuti proxy.
Da bi se umanjili takvi rizici, preporučuje se isključivanje merge_slashes direktive za aplikacije koje su podložne ovim ranjivostima. Ovo osigurava da Nginx prosledi zahteve aplikaciji bez izmene strukture URL-a, čime se ne prikrivaju nikakvi osnovni problemi sa bezbednošću.
Za više informacija pogledajte Danny Robinson i Rotem Bar.
Kao što je prikazano u ovom izveštaju, postoje određena zaglavlja koja, ako su prisutna u odgovoru sa web servera, mogu promeniti ponašanje Nginx proxy-a. Možete ih proveriti u dokumentaciji:
X-Accel-Redirect: Ukazuje Nginxu da interno preusmeri zahtev na određenu lokaciju.
X-Accel-Buffering: Kontroliše da li Nginx treba da kešira odgovor ili ne.
X-Accel-Charset: Postavlja karakter set za odgovor kada se koristi X-Accel-Redirect.
X-Accel-Expires: Postavlja vreme isteka za odgovor kada se koristi X-Accel-Redirect.
X-Accel-Limit-Rate: Ograničava brzinu prenosa za odgovore kada se koristi X-Accel-Redirect.
Na primer, zaglavlje X-Accel-Redirect će izazvati interno preusmeravanje u Nginxu. Tako da, ako imate Nginx konfiguraciju sa nečim poput root / i odgovorom sa web servera sa X-Accel-Redirect: .env, Nginx će poslati sadržaj /.env (Path Traversal).
U Nginx konfiguraciji, map direktiva često igra ulogu u kontroli autorizacije. Uobičajena greška je neodređivanje podrazumevane vrednosti, što može dovesti do neovlašćenog pristupa. Na primer:
Bez default, zlonameran korisnik može zaobići sigurnost pristupajući neodređenom URI unutar /map-poc. Nginx priručnik savetuje postavljanje podrazumevane vrednosti kako bi se izbegli takvi problemi.
DNS spoofing protiv Nginx-a je izvodljiv pod određenim uslovima. Ako napadač zna koji DNS server koristi Nginx i može presresti njegove DNS upite, može falsifikovati DNS zapise. Ova metoda, međutim, nije efikasna ako je Nginx konfigurisan da koristi localhost (127.0.0.1) za DNS rezoluciju. Nginx omogućava specificiranje DNS servera na sledeći način:
proxy_pass i internal DirektiveDirektiva proxy_pass se koristi za preusmeravanje zahteva na druge servere, bilo interno ili eksterno. Direktiva internal osigurava da su određene lokacije dostupne samo unutar Nginx-a. Iako ove direktive same po sebi nisu ranjivosti, njihova konfiguracija zahteva pažljivo ispitivanje kako bi se sprečili sigurnosni propusti.
Ako je nginx server konfigurisan da prosledi Upgrade i Connection zaglavlja, može se izvesti h2c Smuggling napad kako bi se pristupilo zaštićenim/internim krajnjim tačkama.
Ova ranjivost bi omogućila napadaču da uspostavi direktnu vezu sa proxy_pass krajnjom tačkom (http://backend:9999 u ovom slučaju) čiji sadržaj neće biti proveravan od strane nginx-a.
Primer ranjive konfiguracije za krađu /flag sa ovde:
Napomena da čak i ako je proxy_pass usmeren na određeni put kao što je http://backend:9999/socket.io, veza će biti uspostavljena sa http://backend:9999, tako da možete kontaktirati bilo koji drugi put unutar tog internog krajnjeg tačke. Tako da nije važno da li je put specificiran u URL-u proxy_pass.
Detectify je kreirao GitHub repozitorijum gde možete koristiti Docker da postavite svoj vlastiti ranjivi Nginx test server sa nekim od pogrešnih konfiguracija o kojima se govori u ovom članku i pokušate da ih pronađete sami!
https://github.com/detectify/vulnerable-nginx
Gixy je alat za analizu Nginx konfiguracije. Glavni cilj Gixy je sprečavanje sigurnosnih pogrešnih konfiguracija i automatizacija otkrivanja grešaka.
Nginxpwner je jednostavan alat za traženje uobičajenih Nginx pogrešnih konfiguracija i ranjivosti.
Dobijte perspektivu hakera o vašim web aplikacijama, mreži i cloudu
Pronađite i prijavite kritične, eksploatabilne ranjivosti sa stvarnim poslovnim uticajem. Koristite naših 20+ prilagođenih alata za mapiranje napada, pronalaženje sigurnosnih problema koji vam omogućavaju da eskalirate privilegije, i koristite automatizovane eksploate za prikupljanje suštinskih dokaza, pretvarajući vaš trud u uverljive izveštaje.
Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
