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
- Angalia mpango wa usajili!
- Jiunge na 💬 kikundi cha Discord au kikundi cha telegram au tufuatilie kwenye Twitter 🐦 @hacktricks_live.
- Shiriki mbinu za hacking kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.
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:
- 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 chaSec-WebSocket-Version
, inadhani ombi la Upgrade ni sahihi na linaelekeza kwa nyuma. - Nyuma inajibu kwa msimbo wa hali
426
, ikionyesha toleo la protokali isiyo sahihi katika kichwa chaSec-WebSocket-Version
. Proxy ya nyuma, ikipuuza hali ya jibu la nyuma, inadhani iko tayari kwa mawasiliano ya WebSocket na inapeleka jibu kwa mteja. - 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.
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:
- 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 chaUpgrade
, ikipuuza vipengele vingine vya ombi, na linaelekeza kwa nyuma. - 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.
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.
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
- https://blog.assetnote.io/2021/03/18/h2c-smuggling/
- https://bishopfox.com/blog/h2c-smuggling-request
- https://github.com/0ang3el/websocket-smuggle.git
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
- Angalia mpango wa usajili!
- Jiunge na 💬 kikundi cha Discord au kikundi cha telegram au tufuatilie kwenye Twitter 🐦 @hacktricks_live.
- Shiriki mbinu za hacking kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.