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
- Angalia mpango wa usajili!
- Jiunge na 💬 kikundi cha Discord au kikundi cha telegram au tufuatilie kwenye Twitter 🐦 @hacktricks_live.
- Shiriki mbinu za udukuzi kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.
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:
- 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 chaSec-WebSocket-Version
, inadhani ombi la Upgrade ni halali na linaelekeza kwa backend. - Backend inajibu kwa msimbo wa hali
426
, ikionyesha toleo la protokali isiyo sahihi katika kichwa chaSec-WebSocket-Version
. Reverse proxy, ikipuuza hali ya majibu ya backend, inadhani iko tayari kwa mawasiliano ya WebSocket na inapeleka majibu kwa mteja. - 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.
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:
- 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 chaUpgrade
, ikipuuza vipengele vingine vya ombi, na linaelekeza kwa backend. - 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.
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.
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
- 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)
Support HackTricks
- Angalia mpango wa usajili!
- Jiunge na 💬 kikundi cha Discord au kikundi cha telegram au tufuatilie kwenye Twitter 🐦 @hacktricks_live.
- Shiriki mbinu za udukuzi kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.