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 lokacija

Prilikom konfiguracije Nginx servera, root directive igra ključnu ulogu tako što definiše osnovni direktorijum iz kojeg se poslužuju fajlovi. Razmotrite primer ispod:

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 / {...}). Ovaj previd znači da root direktiva važi globalno, omogućavajući zahtevima na root putanju / pristup fajlovima pod /etc/nginx.

Zbog ove konfiguracije javlja se kritično sigurnosno pitanje. Jednostavan GET zahtev, kao GET /nginx.conf, može otkriti osetljive informacije tako što će poslužiti 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 omogućiti nenamerni pristup drugim kritičnim fajlovima, uključujući druge konfiguracione fajlove, access logove i čak šifrovane kredencijale koji se koriste za HTTP basic authentication.

Alias LFI - pogrešna konfiguracija

U konfiguracionim fajlovima Nginx-a treba pažljivo proveriti “location” direktive. Ranljivost poznata kao Local File Inclusion (LFI) može se nenamerno uvesti kroz konfiguraciju koja podseća 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 fajlovima izvan predviđenog direktorijuma, efektivno rešavajući ih kao /path/images/../flag.txt. Ova greška omogućava napadačima da pribave fajlove iz fajl-sistema servera koji ne bi trebalo da budu dostupni putem weba.

Da bi se ublažila ova ranjivost, konfiguracija bi trebalo da se prilagodi da:

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čavanje putanje

Pogledajte sledeću stranicu da naučite kako zaobići direktive poput:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

Proxy / WAF Protections Bypass

Nesigurna upotreba promenljivih / HTTP Request Splitting

Caution

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

A regex može takođe biti ranjiv, na primer:

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

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

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

Ranljivost u Nginx konfiguraciji ilustrovana je primerom ispod:

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

Karakteri \r (Carriage Return) i \n (Line Feed) označavaju karakterе 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) prema nepravilno konfigurisаном serveru rezultira time da server izda novi header nazvan Detectify. To se dešava zato što promenljiva $uri dekodira URL-enkodirane karaktere novog reda, što dovodi do neočekivanog headera 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/.

Also this technique is explained in this talk with some vulnerable examples and dectection mechanisms. Na primer, da biste otkrili ovu pogrešnu konfiguraciju iz blackbox perspektive možete koristiti sledeće zahteve:

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

Ako je ranjiv, prvi će se vratiti (jer je “X” bilo koja HTTP metoda), a drugi će vratiti grešku jer “H” nije validna metoda. Server će dakle primiti nešto poput: GET / H HTTP/1.1 i to će pokrenuti grešku.

Još primerа 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 otkrivene ranjive konfiguracije prikazane u tom predavanju bile su:

  • Note how $uri is set as is in the final URL
location ^~ /lite/api/ {
proxy_pass http://lite-backend$uri$is_args$args;
}
  • Obratite pažnju 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 promenljiva

Otkriveno je da user-supplied data može biti tretirano kao Nginx variable u određenim okolnostima. Uzrok ovog ponašanja ostaje donekle nejasan, ali nije redak niti jednostavan za potvrditi. Ova anomalija je istaknuta u izveštaju o bezbednosti na HackerOne, koji se može pogledati here. Dalja istraga poruke o grešci dovela je do identifikacije njenog pojavljivanja u SSI filter module of Nginx’s codebase, ukazujući na Server Side Includes (SSI) kao osnovni uzrok.

Da biste otkriti ovu pogrešnu konfiguraciju, može se izvršiti sledeća komanda, koja podrazumeva postavljanje Referer zaglavlja da bi se testiralo ispisivanje promenljivih:

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

Skeniranja ove miskonfiguracije na više sistema otkrila su više instanci u kojima su Nginx variables mogli biti ispisani od strane korisnika. Međutim, smanjenje broja ranjivih instanci sugeriše da su napori da se ovaj problem ispravi donekle uspešni.

Korišćenje try_files sa $URI$ARGS variables

Sledeća Nginx miskonfiguracija 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 koji pronađe. Osnovna sintaksa direktive try_files je sledeća:

try_files file1 file2 ... fileN fallback;

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

Međutim, kada u ovoj direktivi koristite promenljive $uri$args, Nginx će pokušati da pronađe datoteku koja odgovara request URI kombinovanom sa bilo kojim query string argumentima. 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 payload-om:

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

Koristeći naš payload, izaći ćemo iz root direktorijuma (definisanog u Nginx konfiguraciji) i učitati /etc/passwd. U debug logovima možemo videti 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 konfiguraciju navedenu gore: Primer Burp zahteva

Čitanje sirovog odgovora backenda

Nginx nudi opciju preko proxy_pass koja omogućava presretanje grešaka i HTTP zaglavlja koje generiše backend, sa ciljem da sakrije interne poruke o greškama i zaglavlja. To se postiže tako što Nginx serviira prilagođene error stranice kao odgovor na backend greške. Međutim, problem nastaje kada Nginx dobije nevažeći HTTP zahtev. Takav zahtev se prosleđuje backendu onakav kakav je primljen, a sirovi odgovor backenda 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đen odgovor za backend odgovore 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đene HTTP header-e od klijenta, povećavajući privatnost i bezbednost.

Kada se pošalje validan GET zahtev, Nginx ga obrađuje normalno i vraća standardan error odgovor bez otkrivanja bilo kojih tajnih header-a. Međutim, nevažeći HTTP zahtev zaobilazi ovaj mehanizam, što dovodi do izlaganja sirovih backend odgovora, uključujući tajne header-e i poruke o grešci.

merge_slashes podešeno na off

Po defaultu, Nginx-ova merge_slashes directive je postavljena na on, što sabija više uzastopnih kosih crta u URL-u u jednu. Ova funkcionalnost, iako pojednostavljuje obradu URL‑ova, može nenamerno sakriti ranjivosti u aplikacijama iza Nginx-a, posebno 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, naročito kada Nginx radi kao reverse-proxy.

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

For more information check Danny Robinson and Rotem Bar.

Maclicious Response Headers

Kao što je prikazano u this writeup, postoje određeni header-i koji, ako su prisutni u odgovoru web servera, menjaju ponašanje Nginx proxy-ja. Možete ih proveriti in the docs:

  • X-Accel-Redirect: Nalaže Nginx-u 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: Podešava karakter set za odgovor kada se koristi X-Accel-Redirect.
  • X-Accel-Expires: Podešava vreme isteka odgovora kada se koristi X-Accel-Redirect.
  • X-Accel-Limit-Rate: Ograničava brzinu prenosa odgovora kada se koristi X-Accel-Redirect.

Na primer, header X-Accel-Redirect će prouzrokovati internu redirect u nginx-u. Dakle, ako konfiguracija nginx-a sadrži nešto poput root / i odgovor web servera ima X-Accel-Redirect: .env, nginx će poslati sadržaj /.env (Path Traversal).

Podrazumevana vrednost u map direktivi

U Nginx configuration-u, map direktiva često igra ulogu u kontroli autorizacije. Uobičajena greška je neodređivanje podrazumevane vrednosti (default), š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";
}
}

Without a default, a zlonamerni korisnik može zaobići bezbednost pristupom nedefinisanom URI-ju unutar /map-poc. The Nginx manual advises setting a podrazumevana vrednost to avoid such issues.

DNS Spoofing Vulnerability

DNS spoofing protiv Nginx-a je moguć pod određenim uslovima. Ako napadač zna DNS server koji Nginx koristi i može presresti njegove DNS upite, može falsifikovati DNS zapise. Ova metoda, međutim, je neučinkovita ako je Nginx konfigurisan da za rezoluciju DNS-a koristi localhost (127.0.0.1). Nginx dozvoljava navođenje 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 na druge servere, bilo interno ili eksterno. Direktiva internal osigurava da su određene lokacije dostupne samo unutar Nginx-a. Iako same po sebi nisu ranjivosti, njihove konfiguracije zahtevaju 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/internal 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

Obratite pažnju da čak i ako proxy_pass pokazuje na određenu putanju poput http://backend:9999/socket.io konekcija će biti uspostavljena sa http://backend:9999, tako da možete kontaktirati bilo koju drugu putanju unutar tog internog endpoint‑a. Dakle, nije bitno ako je putanja navedena u URL‑u proxy_pass.

HTTP/3 QUIC module remote DoS & leak (2024)

Tokom 2024. Nginx je objavio CVE-2024-31079, CVE-2024-32760, CVE-2024-34161 i CVE-2024-35200, pokazujući da jedna zlonamerna QUIC sesija može srušiti worker procese ili leak memorije kad je eksperimentalni ngx_http_v3_module uključen i kada je izložen listen ... quic socket. Pogođeni buildovi su 1.25.0–1.25.5 i 1.26.0, dok 1.27.0/1.26.1 sadrže ispravke; otkrivanje memorije (CVE-2024-34161) dodatno zahteva MTU veće od 4096 bajtova da bi se osetljivi podaci pojavili (detalji u 2024 nginx advisory navedenom ispod).

Recon & exploitation hints

  • HTTP/3 je opt-in, pa skenirajte za odgovore Alt-Svc: h3=":443" ili brute-force UDP/443 QUIC handshakes; po potvrdi, fuzz‑ujte handshake i STREAM frejmove sa custom quiche-client/nghttp3 payload‑ovima kako biste izazvali padove workera i naterali leak logova.
  • Brzo fingerprintujte podršku mete pomoću:
nginx -V 2>&1 | grep -i http_v3
rg -n "listen .*quic" /etc/nginx/

Zaobilaženje obnove TLS sesije kod autentifikacije klijentskim sertifikatom (CVE-2025-23419)

U saopštenju iz februara 2025. otkriveno je da nginx 1.11.4–1.27.3 izgrađen sa OpenSSL omogućava ponovno korišćenje TLS 1.3 sesije sa jednog virtual hosta zasnovanog na imenu unutar drugog, tako da klijent koji je pregovarao host bez sertifikata može replay the ticket/PSK to jump into a vhost protected with ssl_verify_client on; i potpuno zaobići mTLS. Bug se aktivira kad god više virtualnih hostova deli isti TLS 1.3 session cache i tickets (pogledajte nginx saopštenje iz 2025. navedeno ispod).

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 target ranjiv, drugi handshake se završava bez prezentovanja client certificate, otkrivajući zaštićene lokacije.

Šta treba proveriti

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

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

The HTTP/2 Rapid Reset attack (CVE-2023-44487) i dalje pogađa nginx kada operatori povećaju keepalive_requests ili http2_max_concurrent_streams preko podrazumevanih vrednosti: napadač otvori jednu HTTP/2 konekciju, preplavi je sa hiljadama stream-ova, pa odmah pošalje RST_STREAM frejmove tako da plafon konkurentnosti nikada nije dostignut dok CPU troši resurse na logiku zatvaranja. Nginx defaults (128 concurrent streams, 1000 keepalive requests) drže blast radius malim; podizanje tih limita “substantially higher” olakšava izgladnjivanje workers čak i sa jednog klijenta (vidi F5 write-up referenciran ispod).

Saveti za detekciju

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

Hostovi koji otkrivaju neobično visoke vrednosti za te direktive su glavni ciljevi: jedan HTTP/2 klijent može u petlji kreirati streamove i slati instant RST_STREAM okvire da drži CPU opterećen bez aktiviranja ograničenja konkurentnosti.

Isprobajte sami

Detectify je napravio GitHub repozitorijum gde možete koristiti Docker da podignete sopstveni ranjivi Nginx test server sa nekim od pogrešnih konfiguracija obrađenih u ovom članku i pokušate da ih pronađete sami!

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

Alati za statičku analizu

gixy-ng & Gixy-Next & GIXY

  • Gixy-Next (ažurirani fork GIXY) je alat za analizu Nginx konfiguracija, sa ciljem pronalaženja ranjivosti, nesigurnih direktiva i rizičnih pogrešnih konfiguracija. Takođe nalazi konfiguracione greške koje utiču na performanse i otkriva propuštene prilike za hardening, omogućavajući automatizovano otkrivanje propusta.
  • gixy-ng (aktivno održavani fork GIXY) je alat za analizu Nginx konfiguracija, sa ciljem pronalaženja ranjivosti, nesigurnih direktiva i rizičnih pogrešnih konfiguracija. Takođe nalazi konfiguracione greške koje utiču na performanse i otkriva propuštene prilike za hardening, omogućavajući automatizovano otkrivanje propusta.

Nginxpwner

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

Reference

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