<summary><strong>Jifunze udukuzi wa AWS kutoka sifuri hadi shujaa na</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Mtaalam wa Timu Nyekundu ya AWS ya HackTricks)</strong></a><strong>!</strong></summary>
* Ikiwa unataka kuona **kampuni yako ikitangazwa kwenye HackTricks** au **kupakua HackTricks kwa PDF** Angalia [**MIPANGO YA USAJILI**](https://github.com/sponsors/carlospolop)!
* Gundua [**Familia ya PEASS**](https://opensea.io/collection/the-peass-family), mkusanyiko wetu wa [**NFTs**](https://opensea.io/collection/the-peass-family) za kipekee
* **Jiunge na** 💬 [**Kikundi cha Discord**](https://discord.gg/hRep4RUj7f) au kikundi cha [**telegram**](https://t.me/peass) au **tufuate** kwenye **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Shiriki mbinu zako za udukuzi kwa kuwasilisha PRs kwa** [**HackTricks**](https://github.com/carlospolop/hacktricks) na [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos za github.
H2C, au **http2 kupitia nakala wazi**, inatofautiana na kawaida ya mawasiliano ya HTTP ya muda mfupi kwa kuboresha **mawasiliano ya HTTP ya kawaida kuwa ya kudumu**. Mawasiliano yaliyoboreshwa hutumia itifaki ya binary ya http2 kwa mawasiliano endelevu, tofauti na asili ya ombi moja la HTTP ya maandishi ya kawaida.
Muhimu wa suala la udukuzi linatokea 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: Upgrade` kipo katika ombi la HTTP (mara nyingi huonekana na mawasiliano ya websocket), **proxy ya kurudisha inaendeleza 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:
Mkazo unatokea wakati, baada ya kuboresha uhusiano, reverse proxy inakoma kusimamia maombi binafsi, ikidhani kazi yake ya kuongoza imekamilika baada ya kuanzisha uhusiano. Kuchexploit H2C Smuggling kuruhusu 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.
Mkazo unategemea jinsi reverse proxy inavyoshughulikia vichwa vya `Upgrade` na mara nyingine `Connection`. Proxies zifuatazo kwa asili hufikisha vichwa hivi wakati wa kuendesha proxy-pass, hivyo kwa asili kuwezesha H2C smuggling:
Kinyume chake, huduma hizi kwa asili hazifanyi mbele vichwa vyote wakati wa kuendesha proxy-pass. Hata hivyo, zinaweza kuwekwa kwa njia isiyokuwa salama, kuruhusu mbele bila kufanyiwa uchujaji wa vichwa vya `Upgrade` na `Connection`:
Ni muhimu kutambua kwamba si seva zote kwa asili zinafikisha vichwa vinavyohitajika kwa ajili ya kuboresha uhusiano wa H2C kwa njia inayofuata sheria. Kwa hivyo, seva kama vile AWS ALB/CLB, NGINX, na Apache Traffic Server, miongoni mwa nyingine, kwa asili zinazuia uhusiano wa H2C. Hata hivyo, ni vyema kujaribu na toleo lisilofuata viwango vya `Connection: Upgrade`, ambavyo havijumuishi thamani ya `HTTP2-Settings` kutoka kwa kichwa cha `Connection`, kwani baadhi ya seva za nyuma hazizingatii viwango.
Bila kujali **njia** maalum iliyoteuliwa katika URL ya `proxy_pass` (k.m., `http://backend:9999/socket.io`), uhusiano ulioanzishwa unarudi kwa chaguo la msingi la `http://backend:9999`. Hii inaruhusu mwingiliano na njia yoyote ndani ya hatima hiyo, ikitumia mbinu hii. Hivyo, kutaja njia katika URL ya `proxy_pass` haizuili upatikanaji.
Zana [**h2csmuggler na BishopFox**](https://github.com/BishopFox/h2csmuggler) na [**h2csmuggler na assetnote**](https://github.com/assetnote/h2csmuggler) huwezesha majaribio ya **kuzunguka ulinzi uliowekwa na proxy** kwa kuanzisha uhusiano wa H2C, hivyo kuruhusu upatikanaji wa rasilimali zilizolindwa na proxy.
Kwa habari zaidi kuhusu mkazo huu, hasa kuhusu NGINX, tazama [**rasilimali hii iliyodetauliwa**](../network-services-pentesting/pentesting-web/nginx.md#proxy\_set\_header-upgrade-and-connection).
Websocket smuggling, tofauti na kuanzisha handaki ya HTTP2 kwa hatima inayopatikana kupitia proxy, inaanzisha handaki ya Websocket kuzunguka vizuizi vya proxy na kurahisisha mawasiliano moja kwa moja na hatima.
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:
1. Mteja anaanza kwa kutuma ombi la Kuboresha kwa reverse proxy na toleo sahihi la itifaki ya `Sec-WebSocket-Version` kwenye kichwa. Proxy, ikishindwa kuthibitisha kichwa cha `Sec-WebSocket-Version`, inaamini ombi la Kuboresha ni sahihi na kuliforward kwa hatima.
2. Hatima inajibu na nambari ya hali `426`, ikionyesha toleo lisilo sahihi la itifaki katika kichwa cha `Sec-WebSocket-Version`. Reverse proxy, ikipuuza hali ya jibu la hatima, inadhani kuwa tayari kwa mawasiliano ya WebSocket na kusambaza jibu kwa mteja.
3. Kufuatia hivyo, reverse proxy inadanganywa kuamini kuwa uhusiano wa WebSocket umewekwa kati ya mteja na hatima, wakati halisi, hatima ilikataa ombi la Kuboresha. Hata hivyo, proxy inadumisha uhusiano wa TCP au TLS wazi kati ya mteja na hatima, kuruhusu mteja upatikanaji usiozuiliwa wa API ya REST ya faragha kupitia uhusiano huu.
Proxies zenyeathiriwa ni pamoja na Varnish, ambayo ilikataa kushughulikia suala hilo, na proxy ya Envoy toleo 1.8.0 au la zamani, na toleo za baadaye zimebadilisha mbinu ya kuboresha. Proxies nyingine pia zinaweza kuwa hatarini.
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:
1. Mteja anatuma ombi la POST kuanzisha API ya ukaguzi wa afya, likijumuisha kichwa cha HTTP cha ziada `Upgrade: websocket`. NGINX, ikifanya kazi kama reverse proxy, inachukulia hili kama ombi la kawaida la Kuboresha kulingana tu na kichwa cha `Upgrade`, ikipuuza vipengele vingine vya ombi, na kuliforward kwa hatima.
2. 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, baada ya kupokelewa na hatima na kusambazwa kwa NGINX, linadanganya proxy kuamini kuwa uhusiano wa WebSocket umewekwa kutokana na uthibitisho wake wa nambari ya hali pekee.
Hatimaye, NGINX inadanganywa kuamini kuwa uhusiano wa WebSocket upo kati ya mteja na hatima. Halisi, uhusiano kama huo haupo; API ya REST ya ukaguzi wa afya ilikuwa lengo. Hata hivyo, reverse proxy inadumisha uhusiano wazi, kuruhusu mteja kupata API ya REST ya faragha kupitia huo.
Proxies nyingi za reverse ziko hatarini kwa skena hii, lakini kuchexploit kunategemea uwepo wa udhaifu wa SSRF wa nje, kawaida ukitazamwa kama suala la kiwango cha chini.
Angalia maabara ili kujaribu skena zote mbili kwenye [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git)
