Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2025-02-18 15:08:29 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/network-services-pentesting/pentesting-web/nginx.md
Translator workflow 54a7bb5de7 Translated to Swahili
2024-02-11 02:13:58 +00:00

15 KiB
Raw Blame History

Nginx

Jifunze kuhusu kudukua AWS kutoka sifuri hadi shujaa na htARTE (Mtaalam wa Timu Nyekundu ya AWS ya HackTricks)!

Njia nyingine za kusaidia HackTricks:

Usanidi uliopo mara moja kwa tathmini ya udhaifu na upenyezaji wa mtihani. Fanya pentest kamili kutoka mahali popote na zana na huduma 20+ ambazo zinaanza kutoka kwa uchunguzi hadi ripoti. Hatuchukui nafasi ya wapenyezaji - tunatengeneza zana za desturi, moduli za ugunduzi na uvamizi ili kuwapa muda wa kuchimba kwa kina, kuvunja kabati, na kufurahi.

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

Kukosekana kwa eneo la mizizi

Muhimu wa Kuweka Mwongozo wa Mizizi ya Nginx

Wakati wa kusanidi seva ya Nginx, mwongozo wa mizizi unacheza jukumu muhimu kwa kufafanua saraka ya msingi ambayo faili zinasambazwa kutoka. Fikiria 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 imepewa jukumu la kuwa saraka kuu. Usanidi huu huruhusu ufikiaji wa faili ndani ya saraka kuu iliyoainishwa, kama vile /hello.txt. Hata hivyo, ni muhimu kuelewa kwamba eneo maalum (/hello.txt) limefafanuliwa tu. Hakuna usanidi kwa eneo kuu (location / {...}). Kutokuwepo kwa usanidi huu kunamaanisha kuwa maelekezo ya msingi yanatumika kwa jumla, kuruhusu maombi kwenye njia ya msingi / kupata faili chini ya /etc/nginx.

Kuna shida muhimu ya usalama inayotokana na usanidi huu. Ombi rahisi la GET, kama vile GET /nginx.conf, linaweza kufichua habari nyeti kwa kutoa faili ya usanidi ya Nginx iliyoko katika /etc/nginx/nginx.conf. Kuweka saraka kuu katika saraka isiyo nyeti, kama vile /etc, kunaweza kupunguza hatari hii, lakini bado inaweza kuruhusu ufikiaji usiokusudiwa kwa faili muhimu zingine, ikiwa ni pamoja na faili za usanidi zingine, kumbukumbu za ufikiaji, na hata vitambulisho vilivyofichwa vinavyotumiwa kwa uwakilishi wa msingi wa HTTP.

Kosa la Usanidi wa Alias LFI

Katika faili za usanidi za Nginx, inahitajika uchunguzi wa karibu kwa maelekezo ya "location". Hitilafu inayojulikana kama Local File Inclusion (LFI) inaweza kuingizwa kwa bahati mbaya kupitia usanidi unaofanana na ufuatao:

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

Mazingira haya yanaweza kuwa rahisi kushambuliwa na mashambulizi ya LFI kutokana na seva kuelewa maombi kama vile /imgs../flag.txt kama jaribio la kufikia faili nje ya saraka inayokusudiwa, kimsingi ikielekeza kwa /path/images/../flag.txt. Kasoro hii inaruhusu wadukuzi kuchukua faili kutoka kwenye mfumo wa faili wa seva ambazo hazipaswi kupatikana kupitia wavuti.

Ili kupunguza hatari ya udhaifu huu, mazingira yanapaswa kurekebishwa kama ifuatavyo:

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

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

Vipimo vya 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 Hatarishi la Njia

Angalia ukurasa ufuatao ili kujifunza jinsi ya kuepuka maagizo kama vile:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

Matumizi Hatari ya Kigezo

Hitilafu katika usanidi wa Nginx inaonyeshwa na mfano ufuatao:

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

Wahusika \r (Carriage Return) na \n (Line Feed) hufafanua wahusika mpya wa mstari katika maombi ya HTTP, na fomu zao zilizofanywa URL-encoded zinaonyeshwa kama %0d%0a. Kuingiza wahusika hawa katika ombi (kwa mfano, http://localhost/%0d%0aDetectify:%20clrf) kwa seva iliyo na usanidi mbaya husababisha seva kutolea kichwa kipya kinachoitwa Detectify. Hii hutokea kwa sababu kipengele cha $uri kinadecode wahusika wa URL-encoded mpya wa mstari, ikisababisha kichwa kisichotarajiwa katika jibu:

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 na response splitting kwenye https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.

Variable yoyote

Iligunduliwa kuwa data iliyotolewa na mtumiaji inaweza kutibiwa kama variable ya Nginx chini ya hali fulani. Chanzo cha tabia hii bado hakijulikani kabisa, lakini sio jambo nadra wala rahisi kuthibitisha. Anomali hii ilionyeshwa katika ripoti ya usalama kwenye HackerOne, ambayo inaweza kuonekana hapa. Uchunguzi zaidi wa ujumbe wa kosa ulisababisha kutambuliwa kwa uwepo wake ndani ya moduli ya SSI filter ya msingi wa kanuni ya Nginx, ikilenga Server Side Includes (SSI) kama chanzo cha msingi.

Kutambua hii hitilafu ya usanidi, amri ifuatayo inaweza kutekelezwa, ambayo inahusisha kuweka kichwa cha kurejelea ili kujaribu uchapishaji wa variable:

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

Uchunguzi wa kasoro hii kwenye mifumo umefunua visa kadhaa ambapo mchanganyiko wa Nginx unaweza kuchapishwa na mtumiaji. Walakini, kupungua kwa idadi ya visa hatarishi kunadokeza kuwa juhudi za kurekebisha shida hii zimefanikiwa kwa kiwango fulani.

Kusoma majibu ya nyuma ya seva

Nginx inatoa kipengele kupitia proxy_pass kinachoruhusu kukamata makosa na vichwa vya HTTP vilivyozalishwa na seva ya nyuma, lengo likiwa kuficha ujumbe wa makosa na vichwa vya ndani. Hii inafanikiwa kwa Nginx kutumikia kurasa za kosa za desturi kama jibu kwa makosa ya seva ya nyuma. Walakini, changamoto zinatokea wakati Nginx inakutana na ombi lisilo sahihi la HTTP. Ombi kama hilo linatumwa kwa seva ya nyuma kama ilivyopokelewa, na majibu ya nyuma ya seva yanatumwa moja kwa moja kwa mteja bila kuingilia kati kwa Nginx.

Fikiria mfano wa hali ambayo inahusisha 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!"]

Kuendesha hili, maelekezo maalum katika usanidi wa Nginx hutumiwa:

http {
error_page 500 /html/error.html;
proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}
  • proxy_intercept_errors: Kielekezi hiki kinawezesha Nginx kutumikia jibu la desturi kwa majibu ya seva ya nyuma yenye nambari ya hali kubwa kuliko 300. Inahakikisha kuwa, kwa mfano wetu wa programu ya uWSGI, jibu la 'Kosa la 500' linazuiliwa na kushughulikiwa na Nginx.
  • proxy_hide_header: Kama jina linavyopendekeza, kielekezi hiki kinajificha vichwa vya HTTP vilivyotajwa kutoka kwa mteja, kuboresha faragha na usalama.

Wakati ombi sahihi la GET linapofanywa, Nginx linalitumikia kawaida, likirudisha jibu la kawaida la kosa bila kufichua vichwa vya siri. Walakini, ombi lisilo sahihi la HTTP linapuuza utaratibu huu, ikisababisha kufichuliwa kwa majibu ya seva ya nyuma yasiyosindika, ikiwa ni pamoja na vichwa vya siri na ujumbe wa kosa.

merge_slashes iliyowekwa kuwa off

Kwa chaguo-msingi, kielekezi cha merge_slashes cha Nginx kimehakikishwa kuwa on, ambayo inasukuma mabano mengi ya mbele katika URL kuwa mabano mmoja. Kipengele hiki, wakati kinafanya mchakato wa URL kuwa rahisi, kinaweza kuficha kimakosa udhaifu katika programu zilizopo nyuma ya Nginx, haswa zile zinazoweza kuwa na mashambulizi ya kuingiza faili za ndani (LFI). Wataalam wa usalama Danny Robinson na Rotem Bar wamebainisha hatari zinazowezekana zinazohusiana na tabia hii ya chaguo-msingi, haswa wakati Nginx inafanya kazi kama seva ya wakala wa nyuma.

Ili kupunguza hatari kama hizo, inashauriwa kuzima kielekezi cha merge_slashes kwa programu zinazoweza kuwa na udhaifu huu. Hii inahakikisha kuwa Nginx inapeleka maombi kwa programu bila kubadilisha muundo wa URL, hivyo kutoficha masuala yoyote ya usalama yanayoweza kuwepo.

Kwa habari zaidi angalia Danny Robinson na Rotem Bar.

Thamani ya Chaguo-msingi katika Kielekezi cha Ramani

Katika usanidi wa Nginx, kielekezi cha map mara nyingi kinacheza jukumu katika udhibiti wa idhini. Kosa la kawaida ni kutotaja thamani ya chaguo-msingi, ambayo inaweza kusababisha ufikiaji usioruhusiwa. 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, mtumiaji mwenye nia mbaya anaweza kuepuka usalama kwa kufikia URI isiyofafanuliwa ndani ya /map-poc. Mwongozo wa Nginx unapendekeza kuweka thamani ya msingi ili kuepuka matatizo kama hayo.

Udhaifu wa DNS Spoofing

DNS spoofing dhidi ya Nginx inawezekana chini ya hali fulani. Ikiwa mshambuliaji anajua seva ya DNS inayotumiwa na Nginx na anaweza kuvuruga maswali yake ya DNS, wanaweza kudanganya rekodi za DNS. Hata hivyo, njia hii haifanyi kazi ikiwa Nginx imepangwa kutumia localhost (127.0.0.1) kwa ufafanuzi wa DNS. Nginx inaruhusu kuspecify seva ya DNS kama ifuatavyo:

resolver 8.8.8.8;

proxy_pass na Maagizo ya internal

Maagizo ya proxy_pass hutumiwa kuhamisha maombi kwa seva nyingine, ndani au nje ya mfumo. Maagizo ya internal yanahakikisha kuwa maeneo fulani yanapatikana tu ndani ya Nginx. Ingawa maagizo haya sio udhaifu wenyewe, usanidi wao unahitaji uchunguzi wa kina ili kuzuia upungufu wa usalama.

proxy_set_header Upgrade & Connection

Ikiwa seva ya nginx imepangwa kupitisha vichwa vya habari vya Upgrade na Connection, shambulio la h2c Smuggling linaweza kutekelezwa ili kupata ufikiaji wa sehemu zilizolindwa/ndani.

{% hint style="danger" %} Udhaifu huu ungekuruhusu mtu mshambuliaji kuweka uhusiano moja kwa moja na kielekezi cha proxy_pass (http://backend:9999 katika kesi hii) ambayo maudhui yake hayataangaliwa na nginx. {% endhint %}

Mfano wa usanidi unaoweza kudhurika ili kuiba /flag kutoka hapa:

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" %} Tafadhali kumbuka kwamba hata ikiwa proxy_pass inaelekeza kwenye njia maalum kama vile http://backend:9999/socket.io uhusiano utawekwa na http://backend:9999 hivyo unaweza kuwasiliana na njia nyingine yoyote ndani ya kielekezi hicho cha ndani. Kwa hivyo haifai ikiwa njia imeelezewa katika URL ya proxy_pass. {% endhint %}

Jaribu mwenyewe

Detectify imeunda hazina ya GitHub ambapo unaweza kutumia Docker kuweka seva yako ya majaribio ya Nginx yenye kasoro na baadhi ya misconfigurations iliyozungumziwa katika makala hii na kujaribu kuzipata mwenyewe!

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

Zana za Uchambuzi wa Statisa

GIXY

Gixy ni zana ya kuchambua usanidi wa Nginx. Lengo kuu la Gixy ni kuzuia kasoro za usanidi wa usalama na kugundua kasoro kiotomatiki.

Nginxpwner

Nginxpwner ni zana rahisi ya kutafuta kasoro za kawaida za usanidi na udhaifu wa Nginx.

Marejeo

Usanidi uliopo mara moja kwa ajili ya tathmini ya kasoro na upimaji wa uingiliaji. Tekeleza uchunguzi kamili kutoka mahali popote na zana na huduma 20+ ambazo zinaenda kutoka uchunguzi hadi ripoti. Hatuchukui nafasi ya wapenzi wa uingiliaji - tunatengeneza zana za desturi, moduli za ugunduzi na uingiliaji ili kuwapa muda wa kuchimba kwa kina, kuvunja kabati, na kufurahi.

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

Jifunze kuhusu kudukua AWS kutoka sifuri hadi shujaa na htARTE (HackTricks AWS Red Team Expert)!

Njia nyingine za kusaidia HackTricks: