Upgrade Header Smuggling

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Try Hard Security Group

Join the Try Hard Security Discord Server!Discord

H2C Smuggling

HTTP2 Over Cleartext (H2C)

H2C, au http2 juu ya maandiko wazi, inatofautiana na kawaida ya muunganisho wa HTTP wa muda mfupi kwa kuboresha muunganisho wa HTTP wa kawaida 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 wazi.

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

The vulnerability arises when, after upgrading a connection, the reverse proxy ceases to manage individual requests, assuming its job of routing is complete post-connection establishment. Exploiting H2C Smuggling allows for circumvention of reverse proxy rules applied during request processing, such as path-based routing, authentication, and WAF processing, assuming an H2C connection is successfully initiated.

Vulnerable Proxies

Uthibitisho wa udhaifu unategemea jinsi reverse proxy inavyoshughulikia vichwa vya Upgrade na wakati mwingine Connection. Proxies zifuatazo kwa asili hupeleka vichwa hivi wakati wa proxy-pass, hivyo basi kuweza kuwezesha 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

Exploitation

Ni muhimu kutambua kwamba si seva zote kwa asili hupeleka vichwa vinavyohitajika kwa ajili ya kuboresha muunganisho wa H2C. Hivyo basi, seva kama AWS ALB/CLB, NGINX, na Apache Traffic Server, miongoni mwa zingine, kwa kawaida huzuia 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 kutokufuata viwango.

Irrespective of the specific path designated in the proxy_pass URL (e.g., http://backend:9999/socket.io), the established connection defaults to http://backend:9999. This allows for interaction with any path within that internal endpoint, leveraging this technique. Consequently, the specification of a path in the proxy_pass URL does not restrict access.

The tools h2csmuggler by BishopFox and h2csmuggler by assetnote facilitate attempts to circumvent proxy-imposed protections by establishing an H2C connection, thereby enabling access to resources shielded by the proxy.

For additional information on this vulnerability, particularly concerning NGINX, refer to this detailed resource.

Websocket Smuggling

Websocket smuggling, tofauti na kuunda tunnel ya HTTP2 kwa endpoint inayopatikana kupitia proxy, inaweka tunnel ya Websocket ili kupita mipaka ya proxy na kuwezesha mawasiliano ya moja kwa moja na endpoint.

Scenario 1

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

Mteja anaanza kwa kutuma ombi la Upgrade kwa reverse proxy na toleo sahihi la Sec-WebSocket-Version katika kichwa. Proxy, ikishindwa kuthibitisha kichwa cha Sec-WebSocket-Version, inadhani ombi la Upgrade ni halali na linaelekeza kwa backend.
Backend inajibu kwa msimbo wa hali 426, ikionyesha toleo lisilo sahihi la protokali 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.
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 binafsi ya REST kupitia muunganisho huu.

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

Scenario 2

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

Mteja anatumia ombi la POST kuanzisha API ya ukaguzi wa 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 kupeleka kwa backend.
Backend inatekeleza API ya ukaguzi wa 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: This technique's complexity increases as it requires the ability to interact with an endpoint capable of returning a status code 101.

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

Proxies nyingi za reverse zina hatari katika hali hii, lakini matumizi yake yanategemea uwepo wa udhaifu wa SSRF wa nje, ambao kwa kawaida unachukuliwa kama tatizo la chini.