Kuboresha Kichwa cha Kuingiza

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 KUJIUNGA!
Pata bidhaa rasmi za PEASS & HackTricks
Gundua Familia ya PEASS, mkusanyiko wetu wa NFTs za 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.

Kuingiza H2C

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 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.

Makali ya tatizo la kuingiza 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: 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:

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. 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 umefanikiwa kuanzishwa.

Proxies Zenye Udhaifu

Mkazo unategemea jinsi reverse proxy inavyoshughulikia vichwa vya Upgrade na mara nyingine Connection. Proxies zifuatazo kwa asili huziendeleza vichwa hivi wakati wa kupeleka kwa proxy-pass, hivyo kwa asili kuruhusu H2C smuggling:

HAProxy
Traefik
Nuster

Kinyume chake, huduma hizi kwa asili hazipeleki vichwa vyote viwili wakati wa kupeleka kwa proxy-pass. Hata hivyo, zinaweza kuwekwa kwa njia isiyo salama, kuruhusu kupeleka bila kufuatiliwa kwa vichwa vya Upgrade na Connection:

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

Kuchexploit

Ni muhimu kutambua kwamba si seva zote kwa asili huzipeleka 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.

{% 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 la msingi http://backend:9999. Hii inaruhusu mwingiliano na njia yoyote ndani ya hatima hiyo, ikitumia mbinu hii. Hivyo, kutaja njia katika URL ya proxy_pass haitoi kizuizi cha ufikiaji. {% endhint %}

Zana h2csmuggler na BishopFox na h2csmuggler na assetnote huwezesha majaribio ya kuzunguka ulinzi uliowekwa na proxy kwa kuanzisha uhusiano wa H2C, hivyo kuruhusu ufikiaji wa rasilimali zilizolindwa na proxy.

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

Websocket Smuggling

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

Skenario 1

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

Mteja anaanza kwa kutuma ombi la Kuboresha kwa reverse proxy na toleo la itifaki la Sec-WebSocket-Version lisilo sahihi katika kichwa. Proxy, ikishindwa kuthibitisha kichwa cha Sec-WebSocket-Version, inaamini ombi la Kuboresha ni sahihi na kulipeleka kwa hatima.
Hatima inajibu na nambari ya hali 426, ikionyesha toleo lisilo sahihi la itifaki katika kichwa cha Sec-WebSocket-Version. Reverse proxy, ikipuuza hali ya majibu ya hatima, inadhani kuwa tayari kwa mawasiliano ya Websocket na inapeleka majibu kwa mteja.
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 ufikiaji usiozuiliwa wa API ya ndani ya REST 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 na udhaifu.

Skenario 2

Skenario hili linahusisha hatima yenye API ya Websocket ya umma na API ya REST ya afya kwa ukaguzi, pamoja na API ya ndani ya REST 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 reverse proxy, inachukulia hili kama ombi la Kuboresha la kawaida kulingana tu na kichwa cha Upgrade, ikipuuza vipengele vingine vya ombi, na kulipeleka 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 kusafirishwa kwa NGINX, linadanganya proxy kuamini kuwa uhusiano wa Websocket umewekwa kutokana na uthibitisho wake wa nambari ya hali pekee.

Onyo: Utata wa mbinu hii unazidi 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. Hata hivyo, reverse proxy inadumisha uhusiano wazi, kuruhusu mteja kupata API ya ndani ya REST kupitia huo.

Proxies nyingi za reverse ziko hatarini kwa skenario hili, lakini kuchexploit kunategemea uwepo wa udhaifu wa SSRF wa nje, kawaida ukitazamwa kama suala la kiwango cha chini.

Maabara

Angalia maabara ili kujaribu mizunguko yote miwili katika https://github.com/0ang3el/websocket-smuggle.git

8.7 KiB Raw Blame History