Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00

Translator f0d3bc1562 Translated ['forensics/basic-forensic-methodology/partitions-file-system

2024-03-26 15:53:40 +00:00

10 KiB

Raw Blame History

Kuboresha Kichwa cha Kichwa

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

Njia nyingine za kusaidia HackTricks:

Ikiwa unataka kuona kampuni yako ikionekana kwenye HackTricks au kupakua HackTricks kwa PDF Angalia MIPANGO YA USAJILI!
Pata bidhaa rasmi za PEASS & HackTricks
Gundua Familia ya PEASS, mkusanyiko wetu wa NFTs ya kipekee
Jiunge na 💬 Kikundi cha Discord au kikundi cha telegram au tufuate kwenye Twitter 🐦 @carlospolopm.
Shiriki mbinu zako za kudukua kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.

Kikundi cha Usalama cha Kujitahidi

{% embed url="https://discord.gg/tryhardsecurity" %}

H2C Smuggling

HTTP2 Juu ya Nakala Wazi (H2C)

H2C, au http2 juu ya nakala wazi, inatofautiana na kawaida ya mawasiliano ya HTTP ya muda mfupi kwa kuboresha mawasiliano ya HTTP ya kawaida kuwa moja ya kudumu. Mawasiliano yaliyoboreshwa hutumia itifaki ya binary ya http2 kwa mawasiliano endelevu, tofauti na asili ya ombi moja la HTTP ya nakala wazi.

Makali ya tatizo la kudukua hutokea wakati wa matumizi ya proxy ya kurudisha. Kawaida, proxy ya kurudisha huprocess na kutuma maombi ya HTTP kwa seva ya nyuma, kurudisha jibu la seva ya nyuma baada ya hapo. Walakini, wakati kichwa cha Connection: Kuboresha kipo katika ombi la HTTP (mara nyingi huonekana na mawasiliano ya websocket), proxy ya kurudisha inahifadhi mawasiliano ya kudumu kati ya mteja na seva, kurahisisha kubadilishana kwa mara kwa mara inayohitajika na itifaki fulani. Kwa mawasiliano ya H2C, kufuata RFC kunahitaji uwepo wa vichwa vitatu maalum:

Upgrade: h2c
HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
Connection: Upgrade, HTTP2-Settings

Mkazo unatokea wakati, baada ya kuboresha uhusiano, reverse proxy inakoma kusimamia maombi binafsi, ikidhani kazi yake ya kuongoza imekamilika baada ya kuanzisha uhusiano. Kutumia H2C Smuggling inaruhusu kuzunguka sheria za reverse proxy zilizotumika wakati wa usindikaji wa maombi, kama vile kuongoza kulingana na njia, uthibitishaji, na usindikaji wa WAF, ikidhani uhusiano wa H2C unafanikiwa kuanzishwa.

Proksi Zenye Udhaifu

Mkazo unategemea jinsi proksi ya reverse inavyoshughulikia vichwa vya Upgrade na mara nyingine vichwa vya Connection. Proksi zifuatazo kwa asili huzisonga vichwa hivi wakati wa kupitisha proksi, hivyo kwa asili kuruhusu H2C smuggling:

HAProxy
Traefik
Nuster

Kinyume chake, huduma hizi kwa asili hazisongi vichwa vyote wakati wa kupitisha proksi. Hata hivyo, zinaweza kuwekwa kwa njia isiyokuwa salama, kuruhusu usongaji usio na kichujio wa vichwa vya Upgrade na Connection:

AWS ALB/CLB
NGINX
Apache
Squid
Varnish
Kong
Envoy
Apache Traffic Server

Kutumia

Ni muhimu kutambua kwamba si seva zote kwa asili zinasonga vichwa vinavyohitajika kwa kuboresha uhusiano wa H2C kwa njia inayofuata sheria. Kwa hivyo, seva kama AWS ALB/CLB, NGINX, na Apache Traffic Server, miongoni mwa nyingine, kwa asili zinazuia uhusiano wa H2C. Walakini, ni vyema kujaribu na toleo lisilofuata viwango la Connection: Upgrade, ambalo halijumuishi thamani ya HTTP2-Settings kutoka kwa kichwa cha Connection, kwani baadhi ya seva za nyuma hazizingatii viwango.

{% hint style="danger" %} Bila kujali njia maalum iliyoteuliwa katika URL ya proxy_pass (k.m., http://backend:9999/socket.io), uhusiano ulioanzishwa unakuwa kwa chaguo-msingi http://backend:9999. Hii inaruhusu mwingiliano na njia yoyote ndani ya hatima hiyo, ikitumia mbinu hii. Kwa hivyo, kutaja njia katika URL ya proxy_pass haizuili upatikanaji. {% endhint %}

Zana h2csmuggler na BishopFox na h2csmuggler na assetnote hufanikisha majaribio ya kuzunguka ulinzi uliowekwa na proksi kwa kuanzisha uhusiano wa H2C, hivyo kuruhusu upatikanaji wa rasilimali zilizolindwa na proksi.

Kwa habari zaidi kuhusu mkazo huu, hasa kuhusu NGINX, tazama rasilimali hii iliyodetauliwa.

Websocket Smuggling

Websocket smuggling, tofauti na kuanzisha handaki ya HTTP2 kwa hatima inayopatikana kupitia proksi, inaanzisha handaki la Websocket kuzunguka vizuizi vya proksi na kurahisisha mawasiliano moja kwa moja na hatima.

Skena 1

Katika skena hii, hatima inayotoa API ya Websocket ya umma pamoja na API ya REST ya ndani isiyopatikana inalengwa na mteja mhalifu anayetafuta upatikanaji wa API ya REST ya ndani. Shambulio linajitokeza katika hatua kadhaa:

Mteja anaanza kwa kutuma ombi la Kuboresha kwa proksi ya reverse na toleo sahihi la itifaki ya Sec-WebSocket-Version kwenye kichwa. Proksi, ikishindwa kuthibitisha kichwa cha Sec-WebSocket-Version, inaamini ombi la Kuboresha ni sahihi na kuliforward kwa hatima.
Hatima inajibu na nambari ya hali 426, ikionyesha toleo lisilo sahihi la itifaki katika kichwa cha Sec-WebSocket-Version. Proksi ya reverse, ikipuuza hali ya majibu ya hatima, inadhani kuwa tayari kwa mawasiliano ya Websocket na kusambaza majibu kwa mteja.
Kufuatia hivyo, proksi ya reverse inadanganywa kuamini kuwa uhusiano wa Websocket umewekwa kati ya mteja na hatima, wakati halisi, hatima ilikataa ombi la Kuboresha. Hata hivyo, proksi inaendelea kuweka wazi uhusiano wa TCP au TLS kati ya mteja na hatima, kuruhusu mteja upatikanaji usiozuiliwa wa API ya REST ya faragha kupitia uhusiano huu.

Proksi za reverse zilizoathiriwa ni pamoja na Varnish, ambayo ilikataa kushughulikia suala hilo, na proksi ya Envoy toleo 1.8.0 au la zamani, na toleo za baadaye zimebadilisha mbinu ya kuboresha. Proksi nyingine pia zinaweza kuwa na udhaifu.

Skena 2

Skena hii inahusisha hatima yenye API ya Websocket ya umma na API ya REST ya umma kwa ukaguzi wa afya, pamoja na API ya REST ya ndani isiyopatikana. Shambulio, lenye utata zaidi, linajumuisha hatua zifuatazo:

Mteja anatuma ombi la POST kuanzisha API ya ukaguzi wa afya, likijumuisha kichwa cha HTTP cha ziada Upgrade: websocket. NGINX, ikifanya kazi kama proksi ya reverse, inachukulia hili kama ombi la Kuboresha la kawaida kulingana tu na kichwa cha Upgrade, ikipuuza vipengele vingine vya ombi, na kuliforward kwa hatima.
Hatima inatekeleza API ya ukaguzi wa afya, ikifikia rasilimali ya nje inayodhibitiwa na mshambuliaji ambayo inarudisha jibu la HTTP lenye nambari ya hali 101. Jibu hili, mara tu linapopokelewa na hatima na kusambazwa kwa NGINX, linadanganya proksi kuamini kuwa uhusiano wa Websocket umewekwa kutokana na uthibitisho wake wa nambari ya hali pekee.

Onyo: Utata wa mbinu hii unaongezeka kwani inahitaji uwezo wa kuingiliana na hatima inayoweza kurudisha nambari ya hali 101.

Hatimaye, NGINX inadanganywa kuamini kuwa uhusiano wa Websocket upo kati ya mteja na hatima. Kwa hakika, uhusiano kama huo haupo; API ya REST ya ukaguzi wa afya ilikuwa lengo. Walakini, proksi ya reverse inaendelea kuweka uhusiano wazi, kuruhusu mteja kupata API ya REST ya faragha kupitia huo.

Proksi nyingi za reverse ziko katika hatari katika skena hii, lakini kutumia inategemea uwepo wa udhaifu wa SSRF wa nje, kawaida ukitazamwa kama suala la kiwango cha chini.

Maabara

Angalia maabara ili kujaribu skena zote mbili kwenye https://github.com/0ang3el/websocket-smuggle.git

Marejeo

Kikundi cha Usalama cha Try Hard