Nginx

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Sehemu ya root iliyokosekana

Unapousanidi server ya Nginx, root directive ina jukumu muhimu kwa kufafanua saraka ya msingi ambapo faili zinahudumiwa. Angalia mfano hapa chini:

server {
root /etc/nginx;

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

Katika usanidi huu, /etc/nginx imewekwa kama saraka ya mzizi. Mpangilio huu unaruhusu kufikia faili ndani ya saraka ya mzizi iliyobainishwa, kama /hello.txt. Hata hivyo, ni muhimu kutambua kwamba eneo maalum tu (/hello.txt) limeainishwa. Hakuna usanidi kwa eneo la mzizi (location / {...}). Ukosefu huu unasababisha directive ya root kutumika kwa ujumla, ikiruhusu maombi kwa njia ya mzizi / kufikia faili chini ya /etc/nginx.

Kitu muhimu cha usalama kinatokana na usanidi huu. Ombi rahisi la GET, kama GET /nginx.conf, linaweza kufichua taarifa nyeti kwa kuwasilisha faili ya usanidi ya Nginx iliyoko /etc/nginx/nginx.conf. Kuweka root kwa saraka isiyo na hatari kubwa, kama /etc, kunaweza kupunguza hatari hii, lakini bado kunaweza kuruhusu ufikivu usiokusudiwa kwa faili zingine muhimu, ikiwemo faili nyingine za usanidi, access logs, na hata nywila zilizofichwa (encrypted credentials) zinazotumika kwa HTTP basic authentication.

Alias LFI Misconfiguration

Katika faili za usanidi za Nginx, inatakiwa kufanya ukaguzi wa karibu wa maelekezo ya “location”. Udhaifu unaojulikana kama Local File Inclusion (LFI) unaweza kuletwa bila kukusudiwa kupitia usanidi unaofanana na ufuatao:

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

Configuration hii iko nyeti kwa LFI attacks kwa sababu server inatafsiri requests kama /imgs../flag.txt kama jaribio la kufikia files nje ya directory iliyokusudiwa, kwa hivyo ikitatua kuwa /path/images/../flag.txt. Hitilafu hii inaruhusu attackers kupata files kutoka kwenye server filesystem ambazo hazipaswi kupatikana kupitia web.

Ili kupunguza vulnerability hii, configuration inapaswa kubadilishwa kama ifuatavyo:

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

Taarifa zaidi: https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/

Majaribio ya Accunetix:

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

Kizuizi kisicho salama cha njia

Angalia ukurasa ufuatao ili ujifunze jinsi ya kupitisha maelekezo kama:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

Proxy / WAF Protections Bypass

Matumizi yasiyo salama ya vigezo / HTTP Request Splitting

Caution

Vigezo hatarishi $uri na $document_uri; hili linaweza kurekebishwa kwa kuzibadilisha kwa $request_uri.

Regex pia inaweza kuwa hatarishi kama:

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

location ~ /docs/([^/\s])? { … $1 … } - Not vulnerable (checking spaces)

location ~ /docs/(.*)? { … $1 … } - Not vulnerable

Udhaifu katika usanidi wa Nginx unaonyeshwa na mfano hapa chini:

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

Herufi za udhibiti \r (Carriage Return) na \n (Line Feed) zinaashiria alama za mstari mpya katika HTTP requests, na toleo lao lililowekwa kwa URL (URL-encoded) linaonyeshwa kama %0d%0a. Kuingiza alama hizi katika request (mfano: http://localhost/%0d%0aDetectify:%20clrf) kwa server iliyopangwa vibaya husababisha server kutoa header mpya iitwayo Detectify. Hii inatokea kwa sababu $uri variable ina-decoding alama za mstari mpya zilizo URL-encoded, na kusababisha header isiyotegemewa katika response:

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

Jifunze zaidi kuhusu hatari za CRLF injection and response splitting kwenye https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.

Pia mbinu hii imeexplained in this talk na inatoa baadhi ya mifano yenye udhaifu na mekanisimu za utambuzi. Kwa mfano, ili kugundua misconfiguration hii kutoka kwa blackbox perspective unaweza kutuma maombi yafuatayo:

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

Ikiwa kuna udhaifu, ya kwanza itarudisha kwa sababu “X” ni any HTTP method na ya pili itarudisha kosa kwa sababu H si method halali. Hivyo server itapokea kitu kama: GET / H HTTP/1.1 na hii itasababisha kosa.

Mifano mingine ya kutambua yangekuwa:

  • http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x - Any HTTP code
  • http://company.tld/%20HTTP/1.1%0D%0AHost:%20x - 400 Bad Request

Baadhi ya mipangilio iliyogundulika kuwa dhaifu iliyotangazwa katika hotuba hiyo ni:

  • Angalia jinsi $uri imewekwa kama ilivyo katika URL ya mwisho
location ^~ /lite/api/ {
proxy_pass http://lite-backend$uri$is_args$args;
}
  • Angalia jinsi tena $uri iko kwenye URL (wakati huu ndani ya parameter)
location ~ ^/dna/payment {
rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break;
proxy_pass http://$back;
  • Sasa katika AWS S3
location /s3/ {
proxy_pass https://company-bucket.s3.amazonaws.com$uri;
}

Kigezo chochote

Iligundulika kwamba data iliyotolewa na mtumiaji inaweza kutendewa kama variable ya Nginx katika hali fulani. Chanzo cha tabia hii bado kinaonekana kuwa kigumu kueleweka, lakini si nadra wala si rahisi kuthibitisha. Anomalia hii ilibainishwa katika ripoti ya usalama kwenye HackerOne, ambayo inaweza kuangaliwa hapa. Uchunguzi zaidi wa ujumbe wa kosa ulipelekea kubainika kwake ndani ya SSI filter module of Nginx’s codebase, ukiashiria Server Side Includes (SSI) kama chanzo cha msingi.

Ili kugundua upangaji mbaya huu, amri ifuatayo inaweza kutumika, ambayo inajumuisha kuweka header ya referer ili kujaribu uchapaji wa variable:

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

Upimaji wa usanidi mbaya huu katika mifumo mbalimbali uligundua matukio kadhaa ambapo vigezo vya Nginx vilikuwa vinaweza kuchapishwa na mtumiaji. Hata hivyo, kupungua kwa idadi ya matukio hatarishi kunapendekeza kwamba juhudi za kurekebisha tatizo hili zimefanikiwa kwa kiasi.

Kutumia try_files na vigezo $URI$ARGS

Usanidi mbaya wa Nginx ufuatao unaweza kusababisha utovu wa LFI:

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

Katika usanidi wetu tuna directive try_files ambayo hutumika kuangalia uwepo wa faili kwa mpangilio uliowekwa. Nginx itahudumia ile ya kwanza itakayopatikana. Sintaksia ya msingi ya directive try_files ni kama ifuatavyo:

try_files file1 file2 ... fileN fallback;

Nginx itakagua uwepo wa kila faili kwa mpangilio uliobainishwa. Ikiwa faili ipo, itatolewa mara moja. Ikiwa hakuna kati ya faili zilizotajwa zinazopatikana, ombi litaelekezwa kwa chaguo la ziada, ambalo linaweza kuwa URI nyingine au ukurasa maalum wa kosa.

Hata hivyo, wakati wa kutumia vigezo $uri$args kwenye agizo hili, Nginx itajaribu kutafuta faili inayolingana na URI ya ombi iliyochanganywa na vigezo za query string. Kwa hivyo tunaweza exploit usanidi huu:

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

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

Kwa payload ifuatayo:

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

Kwa kutumia payload yetu tutaondoka kwenye root directory (iliyobainishwa katika configuration ya Nginx) na kupakia faili ya /etc/passwd. Katika debug logs tunaweza kuona jinsi Nginx inavyojaribu mafaili:

...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 dhidi ya Nginx ikitumia mipangilio iliyotajwa hapo juu: Example burp request

Kusoma majibu ghafi ya backend

Nginx ina kipengele kupitia proxy_pass kinachoruhusu kukamata makosa na HTTP headers zinazotokana na backend, kwa lengo la kuficha ujumbe wa ndani wa makosa na headers. Hili linafikiwa kwa Nginx kutumika kurasa za makosa maalum kama majibu kwa makosa ya backend. Hata hivyo, changamoto zinaibuka wakati Nginx inakutana na HTTP request isiyo halali. Request kama hiyo inapelekwa kwa backend kama ilivyopokelewa, na majibu ghafi ya backend hutumwa moja kwa moja kwa client bila uingiliaji wa Nginx.

Fikiria mfano wa tukio unaohusisha programu ya uWSGI:

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

Ili kudhibiti hili, maelekezo maalum katika usanidi wa Nginx zinatumika:

http {
error_page 500 /html/error.html;
proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}
  • proxy_intercept_errors: Dirisha hili linawezesha Nginx kutoa jibu maalum kwa majibu ya backend yenye msimbo wa hali zaidi ya 300. Hii inahakikisha kwamba, kwa mfano wetu wa application ya uWSGI, jibu la 500 Error linakamatwa na kushughulikiwa na Nginx.
  • proxy_hide_header: Kama jina linavyopendekeza, dirisha hili linaficha vichwa maalum vya HTTP kutoka kwa mteja, likiboresha faragha na usalama.

Unapoomba GET halali, Nginx huichakata kawaida, ikirejesha jibu la makosa la kawaida bila kufichua vichwa vyovyote vilivyo siri. Walakini, ombi la HTTP lisilo halali linavuja mfumo huu, na kusababisha kufichuka kwa majibu ghafi ya backend, ikiwa ni pamoja na vichwa vilivyo siri na ujumbe wa makosa.

merge_slashes imewekwa kuwa off

Kwa chaguo-msingi, dirisha la merge_slashes la Nginx limewekwa kuwa on, ambalo linabana vitambulisho vingi vya forward slashes katika URL kuwa slash moja. Kipengele hiki, ingawa kinaboreshawazi usindikaji wa URL, kinaweza bila kukusudia kuficha udhaifu katika applications zilizo nyuma ya Nginx, hasa zile zilizo hatarini kwa mashambulizi ya local file inclusion (LFI). Wataalamu wa usalama Danny Robinson na Rotem Bar wametaja hatari zinazoweza kutokea zinazoambatana na tabia hii ya chaguo-msingi, hasa wakati Nginx inafanya kazi kama reverse-proxy.

Ili kupunguza hatari hizi, inapendekezwa kuzimisha dirisha la merge_slashes kwa applications zilizo hatarini kwa udhaifu huu. Hii inahakikisha kuwa Nginx inapeleka requests kwa application bila kubadilisha muundo wa URL, hivyo kutozaa kuficha matatizo ya usalama yaliyopo msingi.

Kwa habari zaidi angalia Danny Robinson and Rotem Bar.

Vichwa vya Jibu vya Maclicious

Kama ilivyoonyeshwa katika this writeup, kuna vichwa fulani ambavyo ikiwa vipo katika jibu kutoka kwa web server vitabadilisha tabia ya proxy ya Nginx. Unaweza kuviangalia in the docs:

  • X-Accel-Redirect: Inaelekeza Nginx kufanya redirect ya ndani ya ombi hadi eneo lililotajwa.
  • X-Accel-Buffering: Inadhibiti kama Nginx inapaswa ku-buffer jibu au la.
  • X-Accel-Charset: Inaweka character set kwa jibu wakati wa kutumia X-Accel-Redirect.
  • X-Accel-Expires: Inaweka wakati wa kumalizika kwa jibu wakati wa kutumia X-Accel-Redirect.
  • X-Accel-Limit-Rate: Inazuia kiwango cha uhamishaji kwa majibu wakati wa kutumia X-Accel-Redirect.

Kwa mfano, header X-Accel-Redirect itasababisha redirect ya ndani katika nginx. Kwa hivyo, kuwa na configuration ya nginx yenye kitu kama root / na jibu kutoka kwa web server lenye X-Accel-Redirect: .env kutafanya nginx itume yaliyomo ya /.env (Path Traversal).

Default Value in Map Directive

Katika Nginx configuration, dirisha la map mara nyingi lina jukumu katika authorization control. Makosa ya kawaida ni kutosema thamani ya default, ambayo inaweza kusababisha kupata ufikiaji usiothibitishwa. Kwa mfano:

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

Bila default, malicious user anaweza kupitisha usalama kwa kufikia undefined URI ndani ya /map-poc. The Nginx manual inapendekeza kuweka default value ili kuepuka matatizo kama hayo.

DNS Spoofing Vulnerability

DNS spoofing dhidi ya Nginx inawezekana chini ya masharti fulani. Ikiwa attacker anajua DNS server inayotumika na Nginx na anaweza intercept DNS queries zake, anaweza spoof DNS records. Hata hivyo, njia hii haifanyi kazi ikiwa Nginx imewekwa kutumia localhost (127.0.0.1) kwa DNS resolution. Nginx inaruhusu kubainisha DNS server kama ifuatavyo:

resolver 8.8.8.8;

proxy_pass and internal Maelekezo

Maelekezo ya proxy_pass hutumika kupelekaza maombi kwa servers nyingine, ama ndani au nje. Maelekezo ya internal yanahakikisha kwamba maeneo fulani yanapatikana tu ndani ya Nginx. Ingawa maelekezo haya si vulnerabilities wenyewe, usanidi wake unahitaji ukaguzi makini ili kuzuia mapungufu ya usalama.

proxy_set_header Upgrade & Connection

Ikiwa server ya nginx imewekwa kupitisha vichwa vya Upgrade na Connection, h2c Smuggling attack inaweza kutekelezwa ili kufikia protected/internal endpoints.

Caution

This vulnerability itaruhusu attacker kuanzisha muunganano wa moja kwa moja na stablish a direct connection with the proxy_pass endpoint (http://backend:9999 katika kesi hii) ambayo yaliyomo hayataangaliwa na nginx.

Mfano wa usanidi hatari ili kuiba /flag kutoka 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

Kumbuka kwamba hata kama proxy_pass ilikuwa ikielekeza kwa path maalum kama http://backend:9999/socket.io muunganisho utaanzishwa na http://backend:9999 kwa hivyo unaweza kuwasiliana na any other path ndani ya endpoint ya ndani hiyo. Kwa hivyo haijalishi kama path imeainishwa katika URL ya proxy_pass.

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

Mnamo 2024 Nginx ilitangaza CVE-2024-31079, CVE-2024-32760, CVE-2024-34161 na CVE-2024-35200 zikionyesha kwamba single hostile QUIC session inaweza kusababisha worker processes kuanguka au leak memory wakati module ya majaribio ngx_http_v3_module imejengwa na socket ya listen ... quic imefunuliwa. Ma-build zilizoathirika ni 1.25.0–1.25.5 na 1.26.0, wakati 1.27.0/1.26.1 zinaleta fixes; memory disclosure (CVE-2024-34161) pia inahitaji MTUs kubwa zaidi ya 4096 bytes ili kuonyesha data nyeti (maelezo katika advisory ya nginx ya 2024 iliyotajwa hapa chini).

Recon & exploitation hints

  • HTTP/3 ni opt-in, kwa hivyo scan kwa Alt-Svc: h3=":443" responses au brute-force UDP/443 QUIC handshakes; mara tu ithibitishwe, fuzz the handshake na STREAM frames kwa custom quiche-client/nghttp3 payloads ili kusababisha worker crashes na kulazimisha log leakage.
  • Quickly fingerprint target support with:
nginx -V 2>&1 | grep -i http_v3
rg -n "listen .*quic" /etc/nginx/

TLS session resumption bypass of client cert auth (CVE-2025-23419)

Ushauri wa Februari 2025 ulifichua kwamba nginx 1.11.4–1.27.3 iliyojengwa na OpenSSL inaruhusu reusing a TLS 1.3 session kutoka name-based virtual host moja ndani ya nyingine, kwa hivyo client iliyokubaliana na host isiyo na cheti inaweza replay ticket/PSK ili kuingia kwenye vhost iliyo protected na ssl_verify_client on; na kupuuza mTLS kabisa. Hitilafu hii hujitokeza kila wakati virtual hosts nyingi zinaposhiriki TLS 1.3 session cache na tickets (angalia nginx advisory ya 2025 iliyotajwa hapa chini).

Attacker playbook

# 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

Ikiwa lengo lina udhaifu, handshake ya pili inakamilika bila kuwasilisha cheti cha mteja, ikifunua maeneo yaliyolindwa.

Kile cha kukagua

  • Bloki mchanganyiko za server_name zinazo shiriki ssl_session_cache shared:SSL pamoja na ssl_session_tickets on;.
  • Bloki za Admin/API zinazotarajia mTLS lakini zinarithi shared session cache/ticket settings kutoka kwa mwenyeji wa umma.
  • Automation inayowezesha TLS 1.3 session resumption kwa kiwango chote (kwa mfano, Ansible roles) bila kuzingatia vhost isolation.

HTTP/2 Rapid Reset resilience (tabia ya CVE-2023-44487)

Shambulio la HTTP/2 Rapid Reset (CVE-2023-44487) bado linaathiri nginx wakati waendeshaji wanapoinua keepalive_requests au http2_max_concurrent_streams zaidi ya mipangilio ya default: mshambuliaji hufungua muunganisho mmoja wa HTTP/2, kuumwaga kwa maelfu ya streams, kisha mara moja hutoa frames za RST_STREAM ili kizingiti cha concurrency kisifikike wakati CPU inaendelea kutumia rasilimali kwenye mantiki ya kufunga. Mipangilio ya default ya nginx (128 concurrent streams, 1000 keepalive requests) huweka mzunguko wa uharibifu mdogo; kuinua vigezo hivyo “kwa kiasi kikubwa” hufanya iwe rahisi kuzimia workers hata kutoka kwa mteja mmoja (tazama maelezo ya F5 yanayotajwa hapa chini).

Detection tips

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

Hosts ambazo zinaonyesha thamani isiyo ya kawaida kwa directives hizo ni malengo muhimu: mteja mmoja wa HTTP/2 anaweza kurudia kuunda stream na kutuma fremu za ghafla za RST_STREAM ili kuweka CPU ikitumia rasilimali bila kuzima concurrency cap.

Jaribu wewe mwenyewe

Detectify imeunda repository ya GitHub ambapo unaweza kutumia Docker kuanzisha server yako ya mtihani ya Nginx iliyo na udhaifu na baadhi ya mipangilio isiyo sahihi zilizojadiliwa katika makala hii na kujaribu kuzitafuta mwenyewe!

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

Zana za Static Analyzer

GIXY

Gixy ni chombo cha kuchambua usanidi wa Nginx. Lengo kuu la Gixy ni kuzuia mipangilio ya usalama isiyo sahihi na kuendesha ugundaji wa dosari kwa njia ya otomatiki.

Nginxpwner

Nginxpwner ni chombo rahisi kutafuta misconfigurations ya kawaida ya Nginx na vulnerabilities.

Marejeo

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks