Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 22:52:06 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/network-services-pentesting/pentesting-web/nginx.md

18 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 wa papo hapo wa upimaji wa udhaifu & kudukua. Tekeleza pentest kamili kutoka mahali popote na zana na vipengele zaidi ya 20 vinavyoanzia uchunguzi hadi ripoti. Hatuchukui nafasi ya wadukuzi - tuna

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 iliyotajwa, kama vile /hello.txt. Walakini, ni muhimu kuelewa kuwa eneo maalum (/hello.txt) limefafanuliwa tu. Hakuna usanidi kwa eneo la msingi (location / {...}). Kutokuwepo kwa hii kunamaanisha kuwa maelekezo ya msingi yanatumika kimataifa, kuruhusu maombi kwa njia ya msingi / kupata faili chini ya /etc/nginx.

Kuzingatiwa kwa usalama muhimu unatokea kutokana na usanidi huu. Ombi rahisi la GET, kama vile GET /nginx.conf, linaweza kufichua habari nyeti kwa kuhudumia faili ya usanidi wa Nginx iliyoko katika /etc/nginx/nginx.conf. Kuweka saraka kuu kuwa ni saraka isiyo na habari nyeti, kama vile /etc, kunaweza kupunguza hatari hii, hata hivyo bado inaweza kuruhusu ufikiaji usiokusudiwa kwa faili muhimu zingine, ikiwa ni pamoja na faili zingine za usanidi, magogo ya ufikiaji, na hata vibali vilivyofichwa vilivyotumika kwa uthibitishaji wa msingi wa HTTP.

Kosa la Mpangilio wa LFI kwa Kutumia Alias

Katika faili za usanidi za Nginx, uchunguzi wa karibu unahitajika kwa maelekezo ya "location". Udhaifu unaojulikana kama Ujumuishaji wa Faili za Kienyeji (LFI) unaweza kuingizwa kwa bahati mbaya kupitia usanidi unaofanana na ule ufuatao:

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

Hii mipangilio inaweza kushambuliwa na mashambulizi ya LFI kwa sababu ya seva kutafsiri maombi kama vile /imgs../flag.txt kama jaribio la kufikia faili nje ya saraka iliyokusudiwa, ikielekeza kwa /path/images/../flag.txt. Kasoro hii inaruhusu wachomaji kuchukua faili kutoka kwa mfumo wa seva ambazo hazipaswi kupatikana kupitia wavuti.

Ili kupunguza udhaifu huu, mipangilio inapaswa kurekebishwa kuwa:

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

Zaidi ya habari: 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 hatari la njia

Angalia ukurasa ufuatao kujifunza jinsi ya kudukua maagizo kama:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

Matumizi hatari ya kivinjari / Kugawanya Ombi la HTTP

{% hint style="danger" %} Vidokezo vinavyoweza kudhurika $uri na $document_uri na hili linaweza kurekebishwa kwa kuvibadilisha na $request_uri.

Regex inaweza pia kuwa hatarini kama:

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

location ~ /docs/([^/\s])? { … $1 … } - Si hatarini (kuangalia nafasi)

location ~ /docs/(.*)? { … $1 … } - Si hatarini {% endhint %}

Udhaifu katika usanidi wa Nginx unadhihirishwa na mfano hapa chini:

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 zilizo na URL-encoded hurejelezwa kama `%0d%0a`. Kujumuisha wahusika hawa katika ombi (k.m., `http://localhost/%0d%0aDetectify:%20clrf`) kwa seva iliyo na mipangilio mibovu husababisha seva kutoa kichwa kipya kilichoitwa `Detectify`. Hii hutokea kwa sababu ya kigezo $uri kudecode wahusika wa mstari walio na URL-encoded, ikisababisha kichwa cha kutarajia 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 katika https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.

Pia hii technique inaeleweka katika maongezi haya na mifano ya hatari na mbinu za kugundua. Kwa mfano, Ili kugundua hii hitilafu kutoka mtazamo wa blackbox unaweza kutumia maombi haya:

  • https://example.com/%20X - Kila nambari ya HTTP
  • https://example.com/%20H - 400 Ombi Batili

Endapo ina hitilafu, ya kwanza itarudi kama "X" ni njia yoyote ya HTTP na ya pili itarudi kosa kwani H si njia halali. Hivyo server itapokea kitu kama: GET / H HTTP/1.1 na hii itasababisha kosa.

Mifano mingine ya kugundua itakuwa:

  • http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x - Kila nambari ya HTTP
  • http://company.tld/%20HTTP/1.1%0D%0AHost:%20x - 400 Ombi Batili

Baadhi ya mazingira yaliyopatikana kuwa na hitilafu yalipresentiwa katika maongezi hayo:

  • Tazama jinsi $uri inavyowekwa kama ilivyo kwenye URL ya mwisho
location ^~ /lite/api/ {
proxy_pass http://lite-backend$uri$is_args$args;
}
  • Tafadhali angalia jinsi $uri ilivyo 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;
}

Kila kivinjari

Iligundulika kwamba data iliyotolewa na mtumiaji inaweza kutibiwa kama kivinjari cha Nginx chini ya hali fulani. Chanzo cha tabia hii bado ni cha kufichika kidogo, lakini sio nadra wala rahisi kuthibitisha. Kosa hili lilisisitizwa katika ripoti ya usalama kwenye HackerOne, ambayo inaweza kuonekana hapa. Uchunguzi zaidi wa ujumbe wa kosa ulisababisha kutambuliwa kwa kutokea kwake ndani ya moduli ya kichujio cha SSI ya msimbo wa Nginx, ikilenga Seva Upande wa Pili (SSI) kama chanzo cha msingi.

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

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

Uchunguzi wa konfiga hii kwenye mifumo ulifunua visa vingi ambapo mchanganyiko wa Nginx ungeweza kuchapishwa na mtumiaji. Hata hivyo, kupungua kwa idadi ya visa vinavyoweza kudhuriwa kunadokeza kuwa juhudi za kusawazisha tatizo hili zimekuwa na mafanikio fulani.

Kusoma jibu la nyuma la seva

Nginx inatoa kipengele kupitia proxy_pass kinachoruhusu kuingilia kati makosa na vichwa vya HTTP vilivyozalishwa na nyuma, lengo likiwa kuficha ujumbe wa makosa na vichwa vya ndani. Hii inafanikishwa na Nginx kutumikia kurasa za makosa za desturi kujibu makosa ya nyuma. Hata hivyo, changamoto huibuka wakati Nginx inakutana na ombi lisilo sahihi la HTTP. Ombi kama hilo hupokelewa kwa nyuma kama lilivyopokelewa, na jibu la nyuma la nyuma linatumwa moja kwa moja kwa mteja bila kuingilia kati kwa Nginx.

Zingatia mfano wa tukio linalohusisha 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!"]

Kusimamia hili, maelekezo maalum katika usanidi wa Nginx hutumika:

http {
error_page 500 /html/error.html;
proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}
  • proxy_intercept_errors: Mwongozo huu unawezesha Nginx kutumikia jibu la desturi kwa majibu ya seva ya nyuma yenye nambari ya hali kubwa kuliko 300. Inahakikisha kwamba, kwa mfano wetu wa programu ya uWSGI, jibu la Hitilafu ya 500 linazuiliwa na kusindikwa na Nginx.
  • proxy_hide_header: Kama jina linavyopendekeza, mwongozo huu huficha vichwa vya HTTP vilivyotajwa kutoka kwa mteja, ikiboresha faragha na usalama.

Wakati ombi la GET halali linafanywa, Nginx hulisindika kawaida, likirudisha jibu la kosa la kawaida bila kufunua vichwa vya siri. Walakini, ombi lisilo sahihi la HTTP linapuuza mbinu hii, ikisababisha kufichuliwa kwa majibu ya seva ya nyuma moja kwa moja, ikiwa ni pamoja na vichwa vya siri na ujumbe wa hitilafu.

merge_slashes imewekwa kuwa off

Kwa chaguo-msingi, mwongozo wa merge_slashes wa Nginx umewekwa kuwa on, ambayo inapunguza mabano mengi ya mbele katika URL kuwa mabano moja. Kipengele hiki, wakati wa kusafisha usindikaji wa URL, inaweza kuficha kimakosa udhaifu katika programu zilizo nyuma ya Nginx, haswa zile zenye uwezekano wa mashambulizi ya kuingiza faili za ndani (LFI). Wataalamu wa usalama Danny Robinson na Rotem Bar wameonyesha hatari zinazowezekana zinazohusiana na tabia hii ya chaguo-msingi, haswa wakati Nginx inafanya kazi kama seva ya mbele.

Ili kupunguza hatari kama hizo, inapendekezwa kugeuza mwongozo wa merge_slashes kuwa off kwa programu zinazoweza kuathiriwa na udhaifu huu. Hii inahakikisha kwamba Nginx inapeleka maombi kwa programu bila kubadilisha muundo wa URL, hivyo kutoficha masuala yoyote ya usalama yanayoweza kuwepo.

Kwa maelezo zaidi angalia Danny Robinson na Rotem Bar.

Vichwa vya Majibu Yenye Madhara

Kama inavyoonyeshwa katika hii andishi, kuna vichwa fulani ambavyo ikiwa vipo katika jibu kutoka kwa seva ya wavuti vitabadilisha tabia ya proksi ya Nginx. Unaweza kuvichunguza katika nyaraka:

  • X-Accel-Redirect: Inaonyesha Nginx kuelekeza kwa ndani ombi kwa eneo lililospecifika.
  • X-Accel-Buffering: Inadhibiti ikiwa Nginx inapaswa kubana jibu au la.
  • X-Accel-Charset: Inaweka seti ya herufi kwa jibu wakati wa kutumia X-Accel-Redirect.
  • X-Accel-Expires: Inaweka muda wa kumalizika kwa jibu wakati wa kutumia X-Accel-Redirect.
  • X-Accel-Limit-Rate: Inapunguza kasi ya uhamisho kwa majibu wakati wa kutumia X-Accel-Redirect.

Kwa mfano, kichwa cha X-Accel-Redirect kitasababisha uelekezaji wa ndani katika nginx. Kwa hivyo kuwa na usanidi wa nginx na kitu kama root / na jibu kutoka kwa seva ya wavuti na X-Accel-Redirect: .env kutafanya nginx itume maudhui ya /.env (Uvamizi wa Njia).

Thamani ya Chaguo-msingi katika Mwongozo wa Ramani

Katika usanidi wa Nginx, mwongozo wa map mara nyingi unacheza 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 kudukua usalama kwa kufikia URI isiyoelezwa ndani ya /map-poc. Mwongozo wa Nginx unapendekeza kuweka thamani ya default ili kuepuka matatizo kama hayo.

Ugumu wa Udukuzi wa DNS

Udukuzi wa DNS dhidi ya Nginx unawezekana chini ya hali fulani. Ikiwa mshambuliaji anajua seva ya DNS inayotumiwa na Nginx na anaweza kuvuruga maswali yake ya DNS, wanaweza kudukua rekodi za DNS. Hata hivyo, njia hii haifanyi kazi ikiwa Nginx imeboreshwa kutumia localhost (127.0.0.1) kwa ufumbuzi wa DNS. Nginx inaruhusu kutaja seva ya DNS kama ifuatavyo:

resolver 8.8.8.8;

proxy_pass na Maelekezo ya internal

Maelekezo ya proxy_pass hutumiwa kwa kuelekeza maombi kwa seva nyingine, ndani au nje. Maelekezo ya internal hufanya uhakika kuwa maeneo fulani yanapatikana tu ndani ya Nginx. Ingawa maelekezo haya si udhaifu wenyewe, usanidi wao unahitaji uchunguzi wa makini ili kuzuia upungufu wa usalama.

proxy_set_header Kuboresha & Uunganisho

Ikiwa seva ya nginx imeboreshwa kupitisha vichwa vya Kuboresha na Uunganisho, shambulio la h2c Smuggling linaweza kutekelezwa kufikia vituo vilivyolindwa/ndani.

{% hint style="danger" %} Udhaifu huu ungeiruhusu mshambuliaji kuanzisha uhusiano moja kwa moja na kituo cha proxy_pass (http://backend:9999 katika kesi hii) ambacho maudhui yake hayataangaliwa na nginx. {% endhint %}

Mfano wa usanidi unaoweza kudhuriwa 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 hata kama proxy_pass ilikuwa ikielekeza kwenye njia maalum kama vile http://backend:9999/socket.io uhusiano utaanzishwa na http://backend:9999 hivyo unaweza kuwasiliana na njia nyingine yoyote ndani ya kipande hicho cha mwisho. Kwa hivyo haifai ikiwa njia imetajwa kwenye URL ya proxy_pass. {% endhint %}

Jaribu mwenyewe

Detectify wameunda 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 jaribu kuzipata mwenyewe!

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

Zana za Uchambuzi wa Stetiki

GIXY

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

Nginxpwner

Nginxpwner ni zana rahisi ya kutafuta misconfigurations ya kawaida ya Nginx na mapungufu.

Marejeleo

Usanidi uliopo mara moja kwa tathmini ya kasoro & upimaji wa uingiliaji. Tekeleza pentest kamili kutoka popote na zana na vipengele zaidi ya 20 vinavyoanzia uchunguzi hadi ripoti. Hatuchukui nafasi ya pentesters - tunatengeneza zana za desturi, ugunduzi & moduli za uingiliaji ili kuwapa muda wa kuchimba kwa kina, kuvunja makompyuta, na kufurahi.

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

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

Njia nyingine za kusaidia HackTricks: