Nginx
Odmah dostupna postavka za procenu ranjivosti i penetraciono testiranje. Pokrenite potpuni pentest sa bilo kog mesta sa 20+ alata i funkcija koje idu od rekognicije do izveštavanja. Ne zamenjujemo pentestere - razvijamo prilagođene alate, module za detekciju i eksploataciju kako bismo im vratili malo vremena da dublje istraže, otvore shell-ove i zabave se.
Missing root location
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 enkriptovane akreditive korišćene za HTTP osnovnu autentifikaciju.
Alias LFI Misconfiguration
U konfiguracionim datotekama Nginx-a, bliska inspekcija je neophodna za "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 sa serverovog fajl sistema 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:
Unsafe path restriction
Proverite sledeću stranicu da biste saznali kako da zaobiđete direktive kao što su:
Nepravilna upotreba varijabli / Deljenje HTTP zahteva
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 … }
- Ranjiv
location ~ /docs/([^/\s])? { … $1 … }
- Nije ranjiv (proverava razmake)
location ~ /docs/(.*)? { … $1 … }
- Nije ranjiv
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 kodhttps://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 kodhttp://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
Any variable
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 prikazane od strane korisnika. Međutim, smanjenje broja ranjivih instanci sugeriše da su napori za ispravku ovog problema bili donekle uspešni.
Čitanje sirovog odgovora backend-a
Nginx nudi funkciju putem 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 pruži prilagođeni odgovor za pozadinske odgovore sa status kodom većim 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 pozadinskih odgovora, uključujući tajna zaglavlja i poruke o grešci.
merge_slashes postavljeno na off
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 bezbednosni problemi.
Za više informacija pogledajte Danny Robinson i Rotem Bar.
Maclicious Response Headers
Kao što je prikazano u ovoj analizi, postoje određena zaglavlja koja, ako su prisutna u odgovoru sa web servera, menjaju 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. Dakle, imati Nginx konfiguraciju sa nečim poput root /
i odgovorom sa web servera sa X-Accel-Redirect: .env
će nagnati Nginx da pošalje sadržaj /.env
(Path Traversal).
Default Value in Map Directive
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 Ranljivost
DNS spoofing protiv Nginx-a je moguć 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
Direktive
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.
proxy_set_header Upgrade & Connection
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.
Pokušajte sami
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
Alati za statičku analizu
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.
Reference
Odmah dostupna postavka za procenu ranjivosti i penetraciono testiranje. Izvršite potpuni pentest sa bilo kog mesta sa 20+ alata i funkcija koje idu od rekona do izveštavanja. Ne zamenjujemo pentestere - razvijamo prilagođene alate, module za detekciju i eksploataciju kako bismo im vratili malo vremena da dublje istraže, otvore shell-ove i zabave se.
Last updated