Nginx
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Pata mtazamo wa hacker kuhusu programu zako za wavuti, mtandao, na wingu
Pata na ripoti kuhusu udhaifu muhimu, unaoweza kutumiwa kwa faida halisi ya biashara. Tumia zana zetu zaidi ya 20 za kawaida kupanga uso wa shambulio, pata masuala ya usalama yanayokuruhusu kupandisha mamlaka, na tumia matumizi ya kiotomatiki kukusanya ushahidi muhimu, ukigeuza kazi yako ngumu kuwa ripoti za kushawishi.
Wakati wa kusanidi seva ya Nginx, mwelekeo wa root unachukua jukumu muhimu kwa kufafanua saraka ya msingi kutoka ambayo faili hutolewa. Fikiria mfano ulio hapa chini:
Katika usanidi huu, /etc/nginx imewekwa kama saraka ya mzizi. Mipangilio hii inaruhusu ufikiaji wa faili ndani ya saraka iliyoainishwa, kama vile /hello.txt. Hata hivyo, ni muhimu kutambua kwamba eneo maalum tu (/hello.txt) limeainishwa. Hakuna usanidi kwa eneo la mzizi (location / {...}). Kukosekana kwa hili kunamaanisha kwamba mwelekeo wa mzizi unatumika kwa ujumla, ukiruhusu maombi kwa njia ya mzizi / kufikia faili chini ya /etc/nginx.
Kipengele muhimu cha usalama kinatokea kutokana na usanidi huu. Ombi rahisi la GET, kama GET /nginx.conf, linaweza kufichua taarifa nyeti kwa kutoa faili la usanidi la Nginx lililopo kwenye /etc/nginx/nginx.conf. Kuweka mzizi kwenye saraka isiyo nyeti sana, kama /etc, kunaweza kupunguza hatari hii, lakini bado kuna uwezekano wa kuruhusu ufikiaji usio kusudiwa kwa faili nyingine muhimu, ikiwa ni pamoja na faili zingine za usanidi, kumbukumbu za ufikiaji, na hata akidi zilizofichwa zinazotumika kwa uthibitishaji wa msingi wa HTTP.
Katika faili za usanidi za Nginx, ukaguzi wa karibu unahitajika kwa mwelekeo wa "location". Uthibitisho wa udhaifu unaojulikana kama Local File Inclusion (LFI) unaweza kuanzishwa bila kukusudia kupitia usanidi unaofanana na yafuatayo:
Hii usanidi ina hatari ya mashambulizi ya LFI kutokana na seva kufasiri maombi kama /imgs../flag.txt kama jaribio la kufikia faili nje ya saraka iliyokusudiwa, ikitatua kwa ufanisi hadi /path/images/../flag.txt. Kasoro hii inaruhusu washambuliaji kupata faili kutoka kwa mfumo wa faili wa seva ambao haupaswi kupatikana kupitia wavuti.
Ili kupunguza udhaifu huu, usanidi unapaswa kubadilishwa ili:
Zaidi ya habari: https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/
Majaribio ya Accunetix:
Tazama ukurasa ufuatao kujifunza jinsi ya kupita maagizo kama:
Mabadiliko yenye hatari $uri na $document_uri na hii inaweza kurekebishwa kwa kuyabadilisha na $request_uri.
Regex inaweza pia kuwa na hatari kama:
location ~ /docs/([^/])? { … $1 … } - Ina hatari
location ~ /docs/([^/\s])? { … $1 … } - Haina hatari (ikikagua nafasi)
location ~ /docs/(.*)? { … $1 … } - Haina hatari
Uthibitisho wa udhaifu katika usanidi wa Nginx unadhihirishwa na mfano hapa chini:
Mara nyingi \r (Carriage Return) na \n (Line Feed) zinaashiria wahusika wapya katika maombi ya HTTP, na aina zao zilizowekwa URL zinawakilishwa kama %0d%0a. Kuongeza wahusika hawa katika ombi (kwa mfano, http://localhost/%0d%0aDetectify:%20clrf) kwa seva isiyo sahihi husababisha seva kutoa kichwa kipya kinachoitwa Detectify. Hii inatokea kwa sababu ya $uri variable inachambua wahusika wapya wa URL, na kusababisha kichwa kisichotarajiwa katika jibu:
Jifunze zaidi kuhusu hatari za CRLF injection na response splitting kwenye https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.
Pia, mbinu hii imeelezwa katika mazungumzo haya ikiwa na mifano yenye udhaifu na mitambo ya kugundua. Kwa mfano, ili kugundua usakinishaji huu usio sahihi kutoka kwa mtazamo wa blackbox unaweza kutumia maombi haya:
https://example.com/%20X - Kila nambari ya HTTP
https://example.com/%20H - 400 Bad Request
Ikiwa kuna udhaifu, ya kwanza itarudisha kama "X" ni mbinu yoyote ya HTTP na ya pili itarudisha kosa kwani H si mbinu halali. Hivyo, seva itapokea kitu kama: GET / H HTTP/1.1 na hii itasababisha kosa.
Mifano mingine ya kugundua ingekuwa:
http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x - Kila nambari ya HTTP
http://company.tld/%20HTTP/1.1%0D%0AHost:%20x - 400 Bad Request
Baadhi ya usanidi ulio na udhaifu ulioonekana katika mazungumzo hayo ulikuwa:
Kumbuka jinsi $uri ilivyowekwa kama ilivyo katika URL ya mwisho.
Kumbuka jinsi tena $uri iko kwenye URL (wakati huu ndani ya parameter)
Sasa katika AWS S3
Iligundulika kwamba data inayotolewa na mtumiaji inaweza kut treated kama Nginx variable chini ya hali fulani. Sababu ya tabia hii bado ni ngumu kidogo, lakini si nadra wala rahisi kuthibitisha. Anomali hii ilisisitizwa katika ripoti ya usalama kwenye HackerOne, ambayo inaweza kuonekana hapa. Uchunguzi zaidi wa ujumbe wa kosa ulisababisha kutambua kutokea kwake ndani ya moduli ya chujio ya SSI katika msimbo wa Nginx, ikitaja Server Side Includes (SSI) kama sababu kuu.
Ili kubaini hii misconfiguration, amri ifuatayo inaweza kutekelezwa, ambayo inahusisha kuweka kichwa cha referer ili kujaribu uchapishaji wa variable:
Scans for this misconfiguration across systems revealed multiple instances where Nginx variables could be printed by a user. However, a decrease in the number of vulnerable instances suggests that efforts to patch this issue have been somewhat successful.
Nginx inatoa kipengele kupitia proxy_pass ambacho kinaruhusu kukamatwa kwa makosa na vichwa vya HTTP vilivyotolewa na backend, kwa lengo la kuficha ujumbe wa makosa ya ndani na vichwa. Hii inafanywa na Nginx ikihudumia kurasa za makosa za kawaida kama majibu ya makosa ya backend. Hata hivyo, changamoto zinatokea wakati Nginx inakutana na ombi la HTTP lisilo sahihi. Ombi kama hilo linapelekwa kwa backend kama lilivyo, na jibu la moja kwa moja la backend kisha linatumwa moja kwa moja kwa mteja bila kuingilia kati kwa Nginx.
Consider an example scenario involving a uWSGI application:
Ili kusimamia hili, maagizo maalum katika usanidi wa Nginx yanatumika:
proxy_intercept_errors: Hii amri inaruhusu Nginx kutoa jibu maalum kwa majibu ya nyuma yenye msimbo wa hali zaidi ya 300. Inahakikisha kwamba, kwa mfano wetu wa programu ya uWSGI, jibu la 500 Error linakamatwa na kushughulikiwa na Nginx.
proxy_hide_header: Kama jina linavyopendekeza, hii amri inaficha vichwa vya HTTP vilivyotajwa kutoka kwa mteja, ikiongeza faragha na usalama.
Wakati ombi halali la GET linapotolewa, Nginx linafanya kazi yake kawaida, ikirudisha jibu la kawaida la kosa bila kufichua vichwa vya siri. Hata hivyo, ombi la HTTP lisilo halali linapita mfumo huu, na kusababisha kufichuliwa kwa majibu ya nyuma ya asili, ikiwa ni pamoja na vichwa vya siri na ujumbe wa makosa.
Kwa default, amri ya merge_slashes ya Nginx imewekwa kuwa on, ambayo inakusanya slashi nyingi za mbele katika URL kuwa slashi moja. Kipengele hiki, ingawa kinaboresha usindikaji wa URL, kinaweza kwa bahati mbaya kuficha udhaifu katika programu zilizo nyuma ya Nginx, hasa zile zinazoweza kukabiliwa na mashambulizi ya kuingiza faili za ndani (LFI). Wataalamu wa usalama Danny Robinson na Rotem Bar wameonyesha hatari zinazoweza kutokea zinazohusiana na tabia hii ya default, hasa wakati Nginx inafanya kazi kama reverse-proxy.
Ili kupunguza hatari kama hizo, inapendekezwa kugeuza amri ya merge_slashes kuwa off kwa programu zinazoweza kukabiliwa na udhaifu hizi. Hii inahakikisha kwamba Nginx inapeleka maombi kwa programu bila kubadilisha muundo wa URL, hivyo basi haitaweza kuficha matatizo yoyote ya usalama yaliyofichika.
Kwa maelezo zaidi angalia Danny Robinson na Rotem Bar.
Kama inavyoonyeshwa katika hii andiko, kuna vichwa fulani ambavyo ikiwa vipo katika jibu kutoka kwa seva ya wavuti vitabadilisha tabia ya proxy ya Nginx. Unaweza kuvikagua katika nyaraka:
X-Accel-Redirect: Inamuru Nginx kuhamasisha ombi kwa ndani kwa eneo lililotajwa.
X-Accel-Buffering: Inadhibiti ikiwa Nginx inapaswa kubofya jibu au la.
X-Accel-Charset: Inapanga seti ya wahusika kwa jibu wakati wa kutumia X-Accel-Redirect.
X-Accel-Expires: Inapanga muda wa kumalizika kwa jibu wakati wa kutumia X-Accel-Redirect.
X-Accel-Limit-Rate: Inapunguza kiwango cha uhamishaji kwa majibu wakati wa kutumia X-Accel-Redirect.
Kwa mfano, kichwa X-Accel-Redirect kitasababisha redirect ya ndani katika nginx. Hivyo kuwa na usanidi wa nginx na kitu kama root / na jibu kutoka kwa seva ya wavuti yenye X-Accel-Redirect: .env kutaifanya nginx kutuma maudhui ya /.env (Path Traversal).
Katika usanidi wa Nginx, amri ya map mara nyingi ina jukumu katika udhibiti wa idhini. Kosa la kawaida ni kutoshughulikia thamani ya default, ambayo inaweza kusababisha ufikiaji usioidhinishwa. Kwa mfano:
Bila default, mtumiaji mbaya anaweza kupita usalama kwa kufikia URI isiyofafanuliwa ndani ya /map-poc. Mwongozo wa Nginx unashauri kuweka thamani ya default ili kuepuka matatizo kama haya.
DNS spoofing dhidi ya Nginx inawezekana chini ya hali fulani. Ikiwa mshambuliaji anajua seva ya DNS inayotumika na Nginx na anaweza kukamata maswali yake ya DNS, wanaweza kudanganya rekodi za DNS. Hata hivyo, njia hii haiwezi kufanya kazi ikiwa Nginx imewekwa kutumia localhost (127.0.0.1) kwa ajili ya ufumbuzi wa DNS. Nginx inaruhusu kuweka seva ya DNS kama ifuatavyo:
proxy_pass na internal MiongozoMiongozo ya proxy_pass inatumika kwa ajili ya kuelekeza maombi kwa seva nyingine, ama ndani au nje. Miongozo ya internal inahakikisha kwamba maeneo fulani yanapatikana tu ndani ya Nginx. Ingawa miongozo hii si udhaifu kwa wenyewe, usanidi wao unahitaji uchunguzi wa makini ili kuzuia mapungufu ya usalama.
Ikiwa seva ya nginx imewekwa ili kupitisha vichwa vya Upgrade na Connection, shambulio la h2c Smuggling linaweza kufanywa ili kufikia mwisho uliohifadhiwa/wa ndani.
Udhaifu huu utamruhusu mshambuliaji kuanzisha muunganisho wa moja kwa moja na mwisho wa proxy_pass (http://backend:9999 katika kesi hii) ambao maudhui yake hayataangaliwa na nginx.
Mfano wa usanidi ulio dhaifu ili kuiba /flag kutoka hapa:
Kumbuka kwamba hata kama proxy_pass ilikuwa ikielekeza kwenye path maalum kama http://backend:9999/socket.io muunganisho utaanzishwa na http://backend:9999 hivyo unaweza kuwasiliana na path nyingine yoyote ndani ya mwisho huo wa ndani. Hivyo haijalishi kama path imeainishwa katika URL ya proxy_pass.
Detectify ameunda hazina ya GitHub ambapo unaweza kutumia Docker kuanzisha seva yako ya majaribio ya Nginx yenye udhaifu na baadhi ya mipangilio isiyo sahihi iliyozungumziwa katika makala hii na jaribu kuzipata mwenyewe!
https://github.com/detectify/vulnerable-nginx
Gixy ni zana ya kuchambua mipangilio ya Nginx. Lengo kuu la Gixy ni kuzuia mipangilio isiyo sahihi ya usalama na kuharakisha kugundua kasoro.
Nginxpwner ni zana rahisi ya kutafuta mipangilio isiyo sahihi ya kawaida ya Nginx na udhaifu.
Pata mtazamo wa hacker kuhusu programu zako za wavuti, mtandao, na wingu
Pata na ripoti udhaifu muhimu, unaoweza kutumiwa kwa faida halisi ya biashara. Tumia zana zetu 20+ za kawaida kuandaa uso wa shambulio, pata masuala ya usalama yanayokuruhusu kupandisha mamlaka, na tumia mashambulizi ya kiotomatiki kukusanya ushahidi muhimu, ukigeuza kazi yako ngumu kuwa ripoti za kushawishi.
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)
