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

17 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 haraka wa upimaji wa hatari na kudukua. Tekeleza pentest kamili kutoka mahali popote na zana na vipengele zaidi ya 20 vinavyoanzia uchunguzi hadi ripoti. Hatuchukui nafasi ya wadukuzi - tunaendeleza zana za desturi, moduli za ugunduzi na uchomaji ili kuwapa muda wa kuchimba kwa kina, kufungua makompyuta, na kufurahi.

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

Mahali ya Mzizi Lililopotea

Muhimu wa Kuweka Mwongozo wa Mzizi wa Nginx

Wakati wa kuweka seva ya Nginx, mwelekeo wa mzizi unacheza jukumu muhimu kwa kufafanua saraka ya msingi ambayo faili hutumikia. Chukua 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 iliyotajwa, kama vile /hello.txt. Walakini, ni muhimu kuelewa kuwa eneo maalum (/hello.txt) limefafanuliwa tu. Hakuna usanidi wa 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.

Kuzingatia 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 saraka isiyo na habari nyeti, kama vile /etc, kunaweza kupunguza hatari hii, hata hivyo bado inaweza kuruhusu ufikiaji usiokusudiwa wa faili muhimu zaidi, ikiwa ni pamoja na faili nyingine za usanidi, kumbukumbu za ufikiaji, na hata vibali vilivyofichwa vilivyotumika kwa ajili ya 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 Kimaeneo (LFI) unaweza kuletwa kwa bahati mbaya kupitia usanidi unaofanana na ule ufuatao:

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

Konfigurasi hii inaweza kushambuliwa na mashambulizi ya LFI kwa sababu server inachukulia 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 kwenye mfumo wa seva ambazo haipaswi kupatikana kupitia wavuti.

Ili kupunguza udhaifu huu, konfigurasi inapaswa kurekebishwa kuwa:

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 cha njia isiyo salama

Angalia ukurasa ufuatao kujifunza jinsi ya kukiuka maagizo kama:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

{% content-ref url="../../pentesting-web/proxy-waf-protections-bypass.md" %} proxy-waf-protections-bypass.md {% endcontent-ref %}

Matumizi hatari ya variable / Kugawa Ombi la HTTP

{% hint style="danger" %} Variables zenye udhaifu $uri na $document_uri na hii inaweza kusuluhishwa kwa kuzibadilisha na $request_uri.

Regex pia inaweza kuwa na udhaifu kama:

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

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

location ~ /docs/(.*)? { … $1 … } - Sio zenye udhaifu {% 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 kutolea kichwa kipya kinachoitwa Detectify. Hii hutokea kwa sababu ya kigezo $uri kudecode wahusika wa mstari walio na URL-encoded, 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 katika https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.

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

  • https://example.com/%20X - Kificho cha HTTP chochote
  • https://example.com/%20H - 400 Ombi Batili

Ikiwa 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 ugunduzi itakuwa:

  • http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x - Kificho cha HTTP chochote
  • http://company.tld/%20HTTP/1.1%0D%0AHost:%20x - 400 Ombi Batili

Baadhi ya mazingira yaliyopatikana kuwa hatarishi yaliyowasilishwa katika maongezi hayo ni:

  • 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 tena $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 siri 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 kutambua kutokea kwake ndani ya moduli ya kichujio cha SSI ya msimbo wa Nginx, ikilenga Seva Upande wa Pili (SSI) kama chanzo cha msingi.

Kwa kugundua 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 hitilafu 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 na vichwa vya makosa ya 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 hujibiwa moja kwa moja kwa mteja bila kuingilia kati kwa Nginx.

Chukua 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 sahihi la GET linapofanywa, 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, ambao unapunguza 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 kuwa 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 habari zaidi angalia Danny Robinson na Rotem Bar.

Thamani ya Chaguo-msingi katika Mwongozo wa Ramani

Katika mipangilio ya 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 kuepuka 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 matakwa yake ya DNS, wanaweza kufanya udukuzi wa DNS. Hata hivyo, njia hii haifanyi kazi ikiwa Nginx imeboreshwa kutumia localhost (127.0.0.1) kwa ufumbuzi wa DNS. Nginx inaruhusu kufafanua 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 kwamba 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 hayatachunguzwa 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 inaelekeza 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 kielekezi hicho cha ndani. Kwa hivyo haifai ikiwa njia imebainishwa 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 zilizojadiliwa katika makala hii na kujaribu 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 na kasoro za kawaida za Nginx.

Marejeo

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

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

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

Njia nyingine za kusaidia HackTricks: