Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/network-services-pentesting/pentesting-web/nginx.md
Translator workflow 6c06826974 Translated to Serbian
2024-02-10 13:11:20 +00:00

16 KiB
Raw Blame History

Nginx

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

Trenutno dostupna postavka za procenu ranjivosti i testiranje penetracije. Pokrenite puni pentest sa bilo kog mesta sa preko 20 alata i funkcija koje idu od rekonstrukcije do izveštavanja. Ne zamenjujemo pentestere - razvijamo prilagođene alate, module za detekciju i eksploataciju kako bismo im vratili neko vreme da dublje kopaju, otvaraju ljuske i zabavljaju se.

{% embed url="https://pentest-tools.com/" %}

Nedostajuća korenska lokacija

Osnove konfigurisanja Nginx korenskog direktorijuma

Prilikom konfigurisanja Nginx servera, root direktiva igra ključnu ulogu definisanjem osnovnog direktorijuma iz kojeg se serviraju fajlovi. Razmotrite sledeći primer:

server {
root /etc/nginx;

location /hello.txt {
try_files $uri $uri/ =404;
proxy_pass http://127.0.0.1:8080/;
}
}

U ovoj konfiguraciji, /etc/nginx je određen kao koreni direktorijum. Ova postavka omogućava pristup fajlovima unutar određenog korenskog direktorijuma, kao što je /hello.txt. Međutim, važno je napomenuti da je definirana samo određena lokacija (/hello.txt). Nema konfiguracije za korenu lokaciju (location / {...}). Ova izostavljena konfiguracija znači da se direktiva korena primenjuje globalno, omogućavajući zahteve za korenskom putanjom / da pristupaju fajlovima u direktorijumu /etc/nginx.

Iz ove konfiguracije proizlazi kritično sigurnosno pitanje. Jednostavan GET zahtev, poput GET /nginx.conf, može otkriti osetljive informacije tako što će poslužiti Nginx konfiguracioni fajl koji se nalazi na lokaciji /etc/nginx/nginx.conf. Postavljanje korena na manje osetljiv direktorijum, poput /etc, može umanjiti ovaj rizik, ali i dalje može omogućiti neželjen pristup drugim kritičnim fajlovima, uključujući druge konfiguracione fajlove, pristupne logove, pa čak i šifrovane akreditive koji se koriste za HTTP osnovnu autentifikaciju.

Konfiguracija Alias LFI

U konfiguracionim fajlovima Nginx-a, potrebno je pažljivo pregledati "location" direktive. Ranjivost poznata kao Local File Inclusion (LFI) može se nenamerno uneti kroz konfiguraciju koja liči na sledeću:

location /imgs {
alias /path/images/;
}

Ova konfiguracija je podložna LFI napadima zbog toga što server tumači zahteve poput /imgs../flag.txt kao pokušaj pristupa datotekama van namenjenog direktorijuma, efektivno rezultirajući u /putanja/slike/../flag.txt. Ova slabost omogućava napadačima da povrate datoteke sa serverskog fajl sistema koje ne bi trebalo da budu dostupne preko veba.

Da bi se umanjila ova ranjivost, konfiguracija treba da bude prilagođena na sledeći način:

location /imgs/ {
alias /path/images/;
}

Više informacija: https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/

Accunetix testovi:

alias../ => HTTP status code 403
alias.../ => HTTP status code 404
alias../../ => HTTP status code 403
alias../../../../../../../../../../../ => HTTP status code 400
alias../ => HTTP status code 403

Nesigurno ograničenje putanje

Proverite sledeću stranicu da biste saznali kako zaobići direktive poput:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

{% content-ref url="../../pentesting-web/proxy-waf-protections-bypass.md" %} proxy-waf-protections-bypass.md {% endcontent-ref %}

Nebezbedna upotreba promenljive

Ranjivost u konfiguraciji Nginx-a je prikazana u sledećem primeru:

location / {
return 302 https://example.com$uri;
}

Karakteri \r (Carriage Return) i \n (Line Feed) označavaju nove linije u HTTP zahtevima, a njihove URL-kodirane forme se predstavljaju kao %0d%0a. Uključivanje ovih karaktera u zahtev (npr. http://localhost/%0d%0aDetectify:%20clrf) ka serveru sa lošom konfiguracijom rezultuje izdavanjem novog zaglavlja sa nazivom Detectify. Ovo se dešava jer promenljiva $uri dekodira URL-kodirane nove linije, što dovodi do neočekivanog zaglavlja u odgovoru:

HTTP/1.1 302 Moved Temporarily
Server: nginx/1.19.3
Content-Type: text/html
Content-Length: 145
Connection: keep-alive
Location: https://example.com/
Detectify: clrf

Saznajte više o rizicima CRLF ubacivanja i razdvajanja odgovora na https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.

Bilo koja promenljiva

Otkriveno je da se podaci koje korisnik dostavlja mogu tretirati kao Nginx promenljiva u određenim okolnostima. Uzrok ovog ponašanja ostaje delimično nejasan, ali nije retko niti jednostavno proveriti. Ova anomalija je istaknuta u izveštaju o bezbednosti na HackerOne, koji možete pogledati ovde. Dalje istraživanje greške je dovelo do identifikacije njenog pojavljivanja unutar SSI filter modula Nginx-ovog koda, pri čemu su Server Side Includes (SSI) identifikovani kao osnovni uzrok.

Da biste otkrili ovu lošu konfiguraciju, možete izvršiti sledeću komandu, koja uključuje postavljanje referer zaglavlja kako biste testirali ispis promenljive:

$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’

Skeniranja za ovu konfiguraciju na sistemima otkrila su višestruke instance gde korisnik može da prikaže Nginx promenljive. Međutim, smanjenje broja ranjivih instanci ukazuje da su napori za popravku ovog problema donekle uspešni.

Čitanje sirove odgovora sa servera

Nginx nudi mogućnost korišćenja proxy_pass funkcije koja omogućava presretanje grešaka i HTTP zaglavlja koja generiše server, sa ciljem sakrivanja internih poruka o greškama i zaglavlja. Ovo se postiže tako što Nginx servira prilagođene stranice sa greškama kao odgovor na greške servera. Međutim, javljaju se izazovi kada Nginx naiđe na nevažeći HTTP zahtev. Takav zahtev se prosleđuje serveru onakav kakav je primljen, a sirovi odgovor servera se direktno šalje klijentu bez intervencije Nginxa.

Razmotrimo primer scenarija koji uključuje uWSGI aplikaciju:

def application(environ, start_response):
start_response('500 Error', [('Content-Type', 'text/html'), ('Secret-Header', 'secret-info')])
return [b"Secret info, should not be visible!"]

Da biste to upravljali, koriste se specifične direktive u Nginx konfiguraciji:

http {
error_page 500 /html/error.html;
proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}
  • proxy_intercept_errors: Ova direktiva omogućava Nginx-u da posluži prilagođeni odgovor za odgovore sa statusnim kodom većim od 300. Ona osigurava da, za naš primer aplikacije uWSGI, odgovor 500 Error bude presretnut i obrađen od strane Nginx-a.
  • proxy_hide_header: Kao što naziv sugeriše, ova direktiva sakriva određene HTTP zaglavlja od klijenta, poboljšavajući privatnost i bezbednost.

Kada se napravi validan GET zahtev, Nginx ga normalno obrađuje, 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 otkrivanjem sirovih odgovora sa servera, uključujući tajna zaglavlja i poruke o greškama.

merge_slashes postavljen na off

Podrazumevano, Nginx-ova direktiva merge_slashes je postavljena na on, što komprimuje višestruke kosine u URL-u u jednu kosu. Ova funkcionalnost, iako olakšava obradu URL-ova, može nenamerno sakriti ranjivosti u aplikacijama iza Nginx-a, posebno one podložne napadima lokalnog uključivanja fajlova (LFI). Bezbednosni stručnjaci Danny Robinson i Rotem Bar su istakli potencijalne rizike povezane sa ovim podrazumevanim ponašanjem, posebno kada Nginx deluje kao reverzni proxy.

Da bi se umanjili takvi rizici, preporučuje se isključivanje direktive merge_slashes za aplikacije koje su podložne ovim ranjivostima. Ovo osigurava da Nginx prosleđuje zahteve aplikaciji bez izmena strukture URL-a, čime se ne prikrivaju eventualni bezbednosni problemi.

Za više informacija pogledajte Danny Robinson i Rotem Bar.

Podrazumevana vrednost u Map direktivi

U Nginx konfiguraciji, direktiva map često ima ulogu u kontroli autorizacije. Čest propust je nedostatak navođenja podrazumevane vrednosti, što može dovesti do neovlašćenog pristupa. Na primer:

http {
map $uri $mappocallow {
/map-poc/private 0;
/map-poc/secret 0;
/map-poc/public 1;
}
}

server {
location /map-poc {
if ($mappocallow = 0) {return 403;}
return 200 "Hello. It is private area: $mappocallow";
}
}

Bez default, zlonamerni korisnik može zaobići sigurnost pristupanjem nedefinisanom URI-ju unutar /map-poc. Nginx priručnik savetuje postavljanje podrazumevane vrednosti kako bi se izbegli takvi problemi.

Ranjivost DNS prevara

DNS prevara protiv Nginx-a je izvodljiva u određenim uslovima. Ako napadač zna DNS server koji koristi Nginx i može presresti njegove DNS upite, može falsifikovati DNS zapise. Međutim, ova metoda nije efikasna ako je Nginx konfigurisan da koristi localhost (127.0.0.1) za DNS razrešavanje. Nginx omogućava specificiranje DNS servera na sledeći način:

resolver 8.8.8.8;

proxy_pass и internal Директиве

Директива proxy_pass се користи за преусмеравање захтева на друге сервере, било интерно или екстерно. Директива internal осигурава да се одређени локације могу приступити само унутар Nginx-а. Иако ове директиве саме по себи нису угрозе, њихова конфигурација захтева пажљив преглед да би се спречили безбедносни пропусти.

proxy_set_header Upgrade & Connection

Ако је nginx сервер конфигурисан да прослеђује заглавља Upgrade и Connection, може се извршити h2c Smuggling attack да би се приступило заштићеним/интерним ендпоинтима.

{% hint style="danger" %} Ова угроза би омогућила нападачу да установи директну везу са proxy_pass ендпоинтом (http://backend:9999 у овом случају) чији садржај неће бити проверен од стране nginx-а. {% endhint %}

Пример угрожене конфигурације за крађу /flag са овде:

server {
listen       443 ssl;
server_name  localhost;

ssl_certificate       /usr/local/nginx/conf/cert.pem;
ssl_certificate_key   /usr/local/nginx/conf/privkey.pem;

location / {
proxy_pass http://backend:9999;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
}

location /flag {
deny all;
}

{% hint style="warning" %} Imajte na umu da čak i ako je proxy_pass upućivao na određenu putanju kao što je http://backend:9999/socket.io, veza će biti uspostavljena sa http://backend:9999, tako da možete kontaktirati bilo koju drugu putanju unutar tog internog odredišta. Dakle, nije važno da li je putanja navedena u URL-u proxy_pass. {% endhint %}

Isprobajte sami

Detectify je kreirao GitHub repozitorijum gde možete koristiti Docker da biste postavili svoj vlastiti ranjivi Nginx test server sa nekim od konfiguracija koje su opisane u ovom članku i pokušati da ih pronađete sami!

https://github.com/detectify/vulnerable-nginx

Alati za statičku analizu

GIXY

Gixy je alat za analizu Nginx konfiguracije. Glavni cilj Gixy-ja je sprečavanje neispravne konfiguracije bezbednosti i automatizacija otkrivanja slabosti.

Nginxpwner

Nginxpwner je jednostavan alat za pronalaženje uobičajenih Nginx konfiguracija i ranjivosti.

Reference

Trenutno dostupna postavka za procenu ranjivosti i testiranje penetracije. Pokrenite potpuni pentest sa bilo kog mesta sa više od 20 alata i funkcija koje idu od prikupljanja informacija do izveštavanja. Mi ne zamenjujemo pentestere - mi razvijamo prilagođene alate, module za otkrivanje i eksploataciju kako bismo im vratili neko vreme da dublje kopaju, otvaraju ljuske i zabavljaju se.

{% embed url="https://pentest-tools.com/" %}

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u: