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)

Support HackTricks

H2C Smuggling

HTTP2 Over Cleartext (H2C)

H2C, au http2 over 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 maandiko.

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 kuwepo kwa vichwa vitatu maalum:

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

Vulnerability inatokea wakati, baada ya kuboresha muunganisho, reverse proxy inacha kusimamia maombi binafsi, ikidhani kazi yake ya kuelekeza imekamilika baada ya kuanzishwa kwa muunganisho. Kutumia H2C Smuggling kunaruhusu kupita sheria za reverse proxy 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 reverse proxy 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 backends zinaweza kutokubaliana na viwango.

caution

Bila kujali njia maalum iliyotolewa katika URL ya proxy_pass (kwa 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.

Vifaa h2csmuggler by BishopFox na h2csmuggler by assetnote vinasaidia 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, inaweka tunnel ya Websocket ili kupita mipaka ya proxy na kuwezesha mawasiliano ya moja kwa moja na mwisho.

Hali 1

Katika hali hii, backend 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 anaanza kwa kutuma ombi la Upgrade kwa reverse proxy 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 halali na linaelekeza kwa backend.
  2. Backend inajibu kwa msimbo wa hali 426, ikionyesha toleo la protokali isiyo sahihi katika kichwa cha Sec-WebSocket-Version. Reverse proxy, ikipuuza hali ya majibu ya backend, inadhani iko tayari kwa mawasiliano ya WebSocket na inapeleka majibu kwa mteja.
  3. Kwa hivyo, reverse proxy inadanganywa kuamini kuwa muunganisho wa WebSocket umeanzishwa kati ya mteja na backend, wakati kwa kweli, backend ilikuwa imekataa ombi la Upgrade. Licha ya hili, proxy inashikilia muunganisho wa TCP au TLS wazi kati ya mteja na backend, ikiruhusu mteja kupata ufikiaji usio na vizuizi wa API ya REST ya kibinafsi kupitia muunganisho huu.

Proxies za reverse zilizoathirika ni pamoja na Varnish, ambayo ilikataa kushughulikia tatizo, na toleo la proxy la Envoy 1.8.0 au la zamani, huku matoleo ya baadaye yakiwa yamebadilisha 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 backend 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, lililo ngumu 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 reverse proxy, inachukulia hii kama ombi la Upgrade la kawaida kulingana tu na kichwa cha Upgrade, ikipuuza vipengele vingine vya ombi, na linaelekeza kwa backend.
  2. Backend inatekeleza API ya kuangalia afya, ikifikia rasilimali ya nje inayodhibitiwa na mshambuliaji ambayo inarudisha majibu ya HTTP yenye msimbo wa hali 101. Majibu haya, yanapopokelewa na backend na kupelekwa kwa NGINX, yanadanganya proxy kuamini kuwa muunganisho wa WebSocket umeanzishwa kutokana na uthibitisho wake wa msimbo wa hali pekee.

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 backend. Kwa kweli, hakuna muunganisho kama huo; API ya kuangalia afya ilikuwa lengo. Hata hivyo, reverse proxy 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 reverse 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)

Support HackTricks