Upgrade Header Smuggling

Reading time: 7 minutes

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

H2C Smuggling

HTTP2 Over Cleartext (H2C)

H2C, au http2 juu ya cleartext, inatofautiana na kawaida ya muunganisho wa HTTP wa muda mfupi kwa kuboresha muunganisho wa kawaida wa HTTP kuwa wa kudumu. Muunganisho huu ulioimarishwa unatumia itifaki ya http2 ya binary kwa mawasiliano ya kuendelea, tofauti na asili ya ombi moja ya HTTP ya plaintext.

Kiini cha tatizo la smuggling kinatokea na matumizi ya reverse proxy. Kawaida, reverse proxy inashughulikia na kupeleka maombi ya HTTP kwa backend, ikirejesha jibu la backend baada ya hapo. Hata hivyo, wakati kichwa cha Connection: Upgrade kinapokuwepo katika ombi la HTTP (ambalo mara nyingi huonekana na muunganisho wa websocket), proxy inashikilia muunganisho wa kudumu kati ya mteja na seva, ikirahisisha ubadilishanaji wa kuendelea unaohitajika na itifaki fulani. Kwa muunganisho wa H2C, kufuata RFC kunahitaji uwepo wa vichwa vitatu maalum:

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

Vulnerability inatokea wakati, baada ya kuboresha muunganisho, proxy ya nyuma inacha kusimamia maombi binafsi, ikidhani kazi yake ya kuelekeza imekamilika baada ya kuanzishwa kwa muunganisho. Kutumia H2C Smuggling kunaruhusu kupita sheria za proxy ya nyuma zinazotumika wakati wa usindikaji wa maombi, kama vile kuelekeza kwa msingi wa njia, uthibitishaji, na usindikaji wa WAF, ikidhani muunganisho wa H2C umeanzishwa kwa mafanikio.

Proxies Zenye Uthibitisho

Uthibitisho unategemea jinsi proxy ya nyuma inavyoshughulikia vichwa vya Upgrade na wakati mwingine Connection. Proxies zifuatazo kwa asili hupeleka vichwa hivi wakati wa proxy-pass, hivyo kwa asili zinawezesha H2C smuggling:

  • HAProxy
  • Traefik
  • Nuster

Kwa upande mwingine, huduma hizi hazipeleki vichwa vyote viwili kwa asili wakati wa proxy-pass. Hata hivyo, zinaweza kuwekwa kwa njia isiyo salama, kuruhusu upelelezi usio na filters wa vichwa vya Upgrade na Connection:

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

Utekelezaji

Ni muhimu kutambua kwamba si seva zote kwa asili hupeleka vichwa vinavyohitajika kwa kuboresha muunganisho wa H2C unaokubalika. Hivyo, seva kama AWS ALB/CLB, NGINX, na Apache Traffic Server, miongoni mwa zingine, kwa asili zinakataa muunganisho wa H2C. Hata hivyo, inafaa kujaribu na toleo lisilo la kawaida la Connection: Upgrade, ambalo linatenga thamani ya HTTP2-Settings kutoka kwa kichwa cha Connection, kwani baadhi ya nyuma zinaweza kutokubaliana na viwango.

caution

Bila kujali njia maalum iliyotolewa katika URL ya proxy_pass (mfano, http://backend:9999/socket.io), muunganisho ulioanzishwa unarudi kwa http://backend:9999. Hii inaruhusu mwingiliano na njia yoyote ndani ya mwisho huo wa ndani, ikitumia mbinu hii. Kwa hivyo, ufafanuzi wa njia katika URL ya proxy_pass hauzuia ufikiaji.

Zana h2csmuggler by BishopFox na h2csmuggler by assetnote zinasaidia juhudi za kupita ulinzi wa proxy kwa kuanzisha muunganisho wa H2C, hivyo kuruhusu ufikiaji wa rasilimali zilizofichwa na proxy.

Kwa maelezo zaidi kuhusu uthibitisho huu, hasa kuhusu NGINX, rejelea rasilimali hii ya kina.

Websocket Smuggling

Websocket smuggling, tofauti na kuunda tunnel ya HTTP2 kwa mwisho unaopatikana kupitia proxy, inaanzisha tunnel ya Websocket ili kupita mipaka ya proxy na kuwezesha mawasiliano ya moja kwa moja na mwisho.

Hali 1

Katika hali hii, nyuma inayotoa API ya WebSocket ya umma pamoja na API ya REST ya ndani isiyopatikana inashambuliwa na mteja mbaya anayejaribu kupata ufikiaji wa API ya REST ya ndani. Shambulio linafanyika kwa hatua kadhaa:

  1. Mteja anaanzisha kwa kutuma ombi la Upgrade kwa proxy ya nyuma na toleo la protokali isiyo sahihi ya Sec-WebSocket-Version katika kichwa. Proxy, ikishindwa kuthibitisha kichwa cha Sec-WebSocket-Version, inadhani ombi la Upgrade ni sahihi na linaelekeza kwa nyuma.
  2. Nyuma inajibu kwa msimbo wa hali 426, ikionyesha toleo la protokali isiyo sahihi katika kichwa cha Sec-WebSocket-Version. Proxy ya nyuma, ikipuuza hali ya jibu la nyuma, inadhani iko tayari kwa mawasiliano ya WebSocket na inapeleka jibu kwa mteja.
  3. Kwa hivyo, proxy ya nyuma inadanganywa kuamini kuwa muunganisho wa WebSocket umeanzishwa kati ya mteja na nyuma, wakati kwa kweli, nyuma ilikuwa imekataa ombi la Upgrade. Licha ya hili, proxy inashikilia muunganisho wa TCP au TLS wazi kati ya mteja na nyuma, ikiruhusu mteja kupata ufikiaji usio na vizuizi wa API ya REST ya kibinafsi kupitia muunganisho huu.

Proxies za nyuma zilizoathirika ni pamoja na Varnish, ambayo ilikataa kushughulikia tatizo, na toleo la proxy ya Envoy 1.8.0 au zamani, huku toleo za baadaye zikibadilisha mekanismu ya kuboresha. Proxies zingine pia zinaweza kuwa hatarini.

https://github.com/0ang3el/websocket-smuggle/raw/master/img/2-4.png

Hali 2

Hali hii inahusisha nyuma yenye API ya WebSocket ya umma na API ya REST ya umma kwa ajili ya kuangalia afya, pamoja na API ya REST ya ndani isiyopatikana. Shambulio, ambalo ni gumu zaidi, linajumuisha hatua zifuatazo:

  1. Mteja anatumia ombi la POST kuanzisha API ya kuangalia afya, akijumuisha kichwa cha ziada cha HTTP Upgrade: websocket. NGINX, ikihudumu kama proxy ya nyuma, inachukulia hii kama ombi la kawaida la Upgrade kulingana tu na kichwa cha Upgrade, ikipuuza vipengele vingine vya ombi, na linaelekeza kwa nyuma.
  2. Nyuma inatekeleza API ya kuangalia afya, ikifikia rasilimali ya nje inayodhibitiwa na mshambuliaji ambayo inarudisha jibu la HTTP lenye msimbo wa hali 101. Jibu hili, likipokelewa na nyuma na kupelekwa kwa NGINX, linadanganya proxy kuamini kuwa muunganisho wa WebSocket umeanzishwa kwa sababu ya kuthibitisha kwake tu msimbo wa hali.

https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png

Warning: Ugumu wa mbinu hii unakua kadri inavyohitaji uwezo wa kuingiliana na mwisho unaoweza kurudisha msimbo wa hali 101.

Hatimaye, NGINX inadanganywa kuamini kuwa muunganisho wa WebSocket upo kati ya mteja na nyuma. Kwa kweli, hakuna muunganisho kama huo; API ya kuangalia afya ilikuwa lengo. Hata hivyo, proxy ya nyuma inashikilia muunganisho wazi, ikiruhusu mteja kupata ufikiaji wa API ya REST ya kibinafsi kupitia hiyo.

https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-5.png

Proxies nyingi za nyuma zina hatari katika hali hii, lakini utekelezaji unategemea uwepo wa udhaifu wa SSRF wa nje, ambao kwa kawaida unachukuliwa kama tatizo la chini ya kiwango.

Maabara

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

Marejeleo

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks