<summary><strong>Jifunze kuhusu kudukua 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 inayotangazwa katika HackTricks** au **kupakua HackTricks kwa PDF** Angalia [**MPANGO WA KUJIUNGA**](https://github.com/sponsors/carlospolop)!
* Pata [**swag rasmi ya PEASS & HackTricks**](https://peass.creator-spring.com)
* Gundua [**Familia ya PEASS**](https://opensea.io/collection/the-peass-family), mkusanyiko wetu wa kipekee wa [**NFTs**](https://opensea.io/collection/the-peass-family)
* **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 kudukua kwa kuwasilisha PRs kwa** [**HackTricks**](https://github.com/carlospolop/hacktricks) na [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos za github.
Pata udhaifu unaowezekana zaidi ili uweze kuzirekebisha haraka. Intruder inafuatilia eneo lako la shambulio, inafanya uchunguzi wa vitisho wa kujitokeza, inapata masuala katika mfumo wako mzima wa teknolojia, kutoka kwa APIs hadi programu za wavuti na mifumo ya wingu. [**Jaribu bure**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks) leo.
H2C, au **http2 juu ya nakala wazi**, inatofautiana na kawaida ya uhusiano wa HTTP wa muda mfupi kwa kuboresha uhusiano wa HTTP wa kawaida kuwa wa kudumu. Uhusiano ulioboreshwa hutumia itifaki ya binary ya http2 kwa mawasiliano endelevu, tofauti na asili ya ombi moja la HTTP ya nakala wazi.
Shida ya kudukua inatokea wakati wa kutumia **proxy ya kurudisha**. Kawaida, proxy ya kurudisha huprocess na kupeleka maombi ya HTTP kwa seva ya nyuma, ikirudisha jibu la seva ya nyuma baada ya hapo. Walakini, wakati kichwa cha `Connection: Upgrade` kipo katika ombi la HTTP (mara nyingi huonekana na uhusiano wa websocket), proxy ya kurudisha **inadumisha uhusiano wa kudumu** kati ya mteja na seva, kurahisisha kubadilishana endelevu inayohitajika na itifaki fulani. Kwa uhusiano wa H2C, kufuata RFC kunahitaji uwepo wa vichwa vitatu maalum:
Mkazo unatokea wakati, baada ya kuboresha uhusiano, wakala wa nyuma unakoma kusimamia maombi ya kibinafsi, ukidhani kazi yake ya kuelekeza imekamilika baada ya kuanzisha uhusiano. Kufaidika na H2C Smuggling kunaruhusu kuzunguka sheria za wakala wa nyuma zinazotumiwa wakati wa usindikaji wa ombi, kama vile kuelekeza kulingana na njia, uthibitishaji, na usindikaji wa WAF, ukidhani kuwa uhusiano wa H2C umefanikiwa kuanzishwa.
Mkazo unategemea jinsi wakala wa nyuma unavyoshughulikia vichwa vya `Upgrade` na mara nyingine `Connection`. Wakala wa nyuma zifuatazo kwa asili hupeleka vichwa hivi wakati wa kupitisha wakala, hivyo kuwezesha H2C smuggling:
Kwa upande mwingine, huduma hizi kwa asili hazipeleki vichwa vyote wakati wa kupitisha wakala. Walakini, zinaweza kuwekwa kwa njia isiyofaa, kuruhusu kupeleka bila kuchuja vichwa vya `Upgrade` na `Connection`:
Ni muhimu kutambua kuwa seva zote hazipeleki vichwa vinavyohitajika kwa kuboresha uhusiano wa H2C kwa kufuata viwango. Kwa hivyo, seva kama AWS ALB/CLB, NGINX, na Apache Traffic Server, kati ya zingine, kwa asili zinazuia uhusiano wa H2C. Walakini, ni muhimu kujaribu na toleo lisilofuata viwango la `Connection: Upgrade`, ambalo halijumuishi thamani ya `HTTP2-Settings` kutoka kwa kichwa cha `Connection`, kwani baadhi ya nyuma zinaweza kutofuata viwango.
Bila kujali **njia** maalum iliyotengwa katika URL ya `proxy_pass` (kwa mfano, `http://backend:9999/socket.io`), uhusiano ulioanzishwa unatumia chaguo-msingi `http://backend:9999`. Hii inaruhusu mwingiliano na njia yoyote ndani ya kielelezo hicho cha ndani, kwa kutumia mbinu hii. Kwa hivyo, kutoweka kwa njia katika URL ya `proxy_pass` haizuizi upatikanaji.
Zana [**h2csmuggler na BishopFox**](https://github.com/BishopFox/h2csmuggler) na [**h2csmuggler na assetnote**](https://github.com/assetnote/h2csmuggler) hufanikisha jaribio la **kuzunguka ulinzi uliowekwa na wakala** kwa kuanzisha uhusiano wa H2C, hivyo kuruhusu upatikanaji wa rasilimali zilizolindwa na wakala.
Kwa habari zaidi kuhusu mkazo huu, haswa kuhusu NGINX, tazama [**rasilimali hii iliyodeta**](../network-services-pentesting/pentesting-web/nginx.md#proxy\_set\_header-upgrade-and-connection).
Websocket smuggling, tofauti na kujenga handaki ya HTTP2 kwa kielelezo kinachopatikana kupitia wakala, inaanzisha handaki ya Websocket ili kuzunguka vizuizi vya wakala na kurahisisha mawasiliano moja kwa moja na kielelezo.
Katika skenario hili, mteja mbaya anayetaka kupata upatikanaji wa API ya REST ya ndani isiyopatikana anashambulia kielelezo cha nyuma kinachotoa API ya Websocket ya umma pamoja na API ya REST ya ndani isiyopatikana. Shambulio linatokea hatua kadhaa:
1. Mteja anaanza kwa kutuma ombi la Kuboresha kwa wakala wa nyuma na toleo sahihi la itifaki ya `Sec-WebSocket-Version` katika kichwa. Wakala, kwa kutoshughulikia kichwa cha `Sec-WebSocket-Version`, anaamini ombi la Kuboresha ni sahihi na kulipeleka kwa kielelezo cha nyuma.
2. Kielelezo cha nyuma kinajibu na msimbo wa hali `426`, ukionyesha toleo lisilo sahihi la itifaki katika kichwa cha `Sec-WebSocket-Version`. Wakala wa nyuma, bila kuzingatia hali ya jibu la kielelezo cha nyuma, unaamini kuwa tayari kwa mawasiliano ya Websocket na kupeleka jibu kwa mteja.
3. Kwa hivyo, wakala wa nyuma unadanganywa kuamini kuwa kuna uhusiano wa Websocket ulioanzishwa kati ya mteja na kielelezo cha nyuma, wakati ukweli ni kwamba kielelezo cha nyuma kilikataa ombi la Kuboresha. Hata hivyo, wakala unadumisha uhusiano wa TCP au TLS wazi kati ya mteja na kielelezo cha nyuma, kuruhusu mteja kupata upatikanaji usiozuiliwa wa API ya REST ya faragha kupitia uhusiano huu.
Wakala wa nyuma walioathiriwa ni pamoja na Varnish, ambao hawakuchukua hatua kushughulikia suala hili, na wakala wa Envoy toleo 1.8.0 au chini, na toleo jipya limebadilisha mfumo wa kuboresha. Wakala wengine pia wanaweza kuwa hatarini.
Skenario hili linahusisha kielelezo cha nyuma chenye 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 ukaguzi wa afya API, likijumuisha kichwa cha HTTP cha ziada `Upgrade: websocket`. NGINX, ikifanya kazi kama wakala wa nyuma, inaona hii kama ombi la Kuboresha la kawaida kwa msingi wa kichwa cha `Upgrade` pekee, ikipuuza vipengele vingine vya ombi, na kulipeleka kwa kielelezo cha nyuma.
2. Kielelezo cha nyuma kinatekeleza ukaguzi wa afya API, kufikia rasilimali ya nje inayodhibitiwa na mshambuliaji ambayo inarudisha jibu la HTTP lenye msimbo wa hali `101`. Jibu hili, mara tu linapopokelewa na kielelezo cha nyuma na kupelekwa kwa NGINX, linadanganya wakala kuamini kuwa uhusiano wa Websocket umewekwa kutokana na uthibitisho wake wa msimbo wa hali pekee.
