# Upgrade Header Smuggling {% hint style="success" %} Learn & practice AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\ Learn & practice GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks * Check the [**subscription plans**](https://github.com/sponsors/carlospolop)! * **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** * **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
{% endhint %} ### H2C Smuggling #### HTTP2 Over Cleartext (H2C) H2C, of **http2 oor duidelike teks**, deviates from the norm of transient HTTP connections deur 'n standaard HTTP **verbinding na 'n volgehoue een** op te gradeer. Hierdie opgegradeerde verbinding gebruik die http2 binêre protokol vir voortdurende kommunikasie, in teenstelling met die enkele versoek-natuur van duidelike teks HTTP. Die kern van die smuggling probleem ontstaan met die gebruik van 'n **omgekeerde proxy**. Gewoonlik verwerk die omgekeerde proxy en stuur HTTP versoeke na die agterkant, en keer die agterkant se antwoord daarna terug. egter, wanneer die `Connection: Upgrade` kop in 'n HTTP versoek teenwoordig is (wat algemeen gesien word met websocket verbindings), hou die omgekeerde **proxy 'n volgehoue verbinding** tussen kliënt en bediener, wat die voortdurende uitruil wat deur sekere protokolle vereis word, fasiliteer. Vir H2C verbindings vereis nakoming van die RFC die teenwoordigheid van drie spesifieke koppe: ``` Upgrade: h2c HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA Connection: Upgrade, HTTP2-Settings ``` Die kwesbaarheid ontstaan wanneer, na 'n verbinding opgradeer, die omgekeerde proxy ophou om individuele versoeke te bestuur, en aanneem dat sy werk van routering voltooi is na die vestiging van die verbinding. Die benutting van H2C Smuggling maak dit moontlik om omgekeerde proxy reëls wat tydens versoekverwerking toegepas word, soos pad-gebaseerde routering, outentisering, en WAF-verwerking, te omseil, mits 'n H2C-verbinding suksesvol geïnisieer word. #### Kwesbare Proxies Die kwesbaarheid is afhanklik van die omgekeerde proxy se hantering van `Upgrade` en soms `Connection` headers. Die volgende proxies stuur hierdie headers inherent deur proxy-pass, wat H2C smuggling inherent moontlik maak: * HAProxy * Traefik * Nuster Aan die ander kant, hierdie dienste stuur nie inherent albei headers tydens proxy-pass nie. Hulle kan egter onveilig gekonfigureer word, wat ongefilterde forwarding van `Upgrade` en `Connection` headers toelaat: * AWS ALB/CLB * NGINX * Apache * Squid * Varnish * Kong * Envoy * Apache Traffic Server #### Benutting Dit is belangrik om op te let dat nie alle bedieners inherent die headers stuur wat benodig word vir 'n conforme H2C-verbinding opgradering nie. Soos sodanig, bedieners soos AWS ALB/CLB, NGINX, en Apache Traffic Server, onder andere, blokkeer natuurlik H2C-verbindinge. Nietemin, dit is die moeite werd om te toets met die nie-conforme `Connection: Upgrade` variasie, wat die `HTTP2-Settings` waarde uit die `Connection` header uitsluit, aangesien sommige agtergronde dalk nie aan die standaarde voldoen nie. {% hint style="danger" %} Ongeag die spesifieke **pad** wat in die `proxy_pass` URL aangedui word (bv. `http://backend:9999/socket.io`), val die gevestigde verbinding terug na `http://backend:9999`. Dit maak interaksie met enige pad binne daardie interne eindpunt moontlik, wat hierdie tegniek benut. Gevolglik beperk die spesifikasie van 'n pad in die `proxy_pass` URL nie toegang nie. {% endhint %} Die gereedskap [**h2csmuggler deur BishopFox**](https://github.com/BishopFox/h2csmuggler) en [**h2csmuggler deur assetnote**](https://github.com/assetnote/h2csmuggler) fasiliteer pogings om **proxy-opgelegde beskermings te omseil** deur 'n H2C-verbinding te vestig, wat toegang tot hulpbronne wat deur die proxy beskerm word, moontlik maak. Vir addisionele inligting oor hierdie kwesbaarheid, veral rakende NGINX, verwys na [**hierdie gedetailleerde hulpbron**](../network-services-pentesting/pentesting-web/nginx.md#proxy\_set\_header-upgrade-and-connection). ## Websocket Smuggling Websocket smuggling, anders as die skep van 'n HTTP2 tonnel na 'n eindpunt wat deur 'n proxy toeganklik is, vestig 'n Websocket tonnel om potensiële proxy-beperkings te omseil en direkte kommunikasie met die eindpunt te fasiliteer. ### Scenario 1 In hierdie scenario, 'n agtergrond wat 'n publieke WebSocket API bied saam met 'n ontoeganklike interne REST API, word geteiken deur 'n kwaadwillige kliënt wat toegang tot die interne REST API soek. Die aanval ontvou in verskeie stappe: 1. Die kliënt begin deur 'n Upgrade versoek na die omgekeerde proxy te stuur met 'n verkeerde `Sec-WebSocket-Version` protokolweergawe in die header. Die proxy, wat misluk om die `Sec-WebSocket-Version` header te valideer, glo die Upgrade versoek is geldig en stuur dit na die agtergrond. 2. Die agtergrond antwoord met 'n statuskode `426`, wat die verkeerde protokolweergawe in die `Sec-WebSocket-Version` header aandui. Die omgekeerde proxy, wat die agtergrond se antwoordstatus oor die hoof sien, neem aan dat dit gereed is vir WebSocket kommunikasie en stuur die antwoord na die kliënt. 3. Gevolglik word die omgekeerde proxy mislei om te glo dat 'n WebSocket verbinding tussen die kliënt en agtergrond gevestig is, terwyl die agtergrond in werklikheid die Upgrade versoek verwerp het. Ten spyte hiervan, hou die proxy 'n oop TCP of TLS verbinding tussen die kliënt en agtergrond, wat die kliënt onbeperkte toegang tot die private REST API deur hierdie verbinding toelaat. Geaffekteerde omgekeerde proxies sluit Varnish in, wat geweier het om die probleem aan te spreek, en Envoy proxy weergawe 1.8.0 of ouer, met latere weergawes wat die opgradering meganisme verander het. Ander proxies kan ook kwesbaar wees. ![https://github.com/0ang3el/websocket-smuggle/raw/master/img/2-4.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/2-4.png) ### Scenario 2 Hierdie scenario behels 'n agtergrond met beide 'n publieke WebSocket API en 'n publieke REST API vir gesondheidskontrole, saam met 'n ontoeganklike interne REST API. Die aanval, meer kompleks, behels die volgende stappe: 1. Die kliënt stuur 'n POST versoek om die gesondheidskontrole API te aktiveer, insluitend 'n addisionele HTTP header `Upgrade: websocket`. NGINX, wat as die omgekeerde proxy dien, interpreteer dit as 'n standaard Upgrade versoek gebaseer slegs op die `Upgrade` header, terwyl dit die ander aspekte van die versoek verwaarloos, en stuur dit na die agtergrond. 2. Die agtergrond voer die gesondheidskontrole API uit, wat kontak maak met 'n eksterne hulpbron wat deur die aanvaller beheer word wat 'n HTTP antwoord met statuskode `101` teruggee. Hierdie antwoord, sodra dit deur die agtergrond ontvang en na NGINX gestuur is, mislei die proxy om te dink dat 'n WebSocket verbinding gevestig is as gevolg van sy validasie van slegs die statuskode. ![https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png) > **Waarskuwing:** Hierdie tegniek se kompleksiteit neem toe aangesien dit die vermoë vereis om met 'n eindpunt te kommunikeer wat 'n statuskode 101 kan teruggee. Uiteindelik word NGINX mislei om te glo dat 'n WebSocket verbinding tussen die kliënt en die agtergrond bestaan. In werklikheid bestaan daar geen sodanige verbinding nie; die gesondheidskontrole REST API was die teiken. Nietemin, die omgekeerde proxy hou die verbinding oop, wat die kliënt in staat stel om toegang tot die private REST API deur dit te verkry. ![https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-5.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-5.png) Meeste omgekeerde proxies is kwesbaar vir hierdie scenario, maar benutting is afhanklik van die teenwoordigheid van 'n eksterne SSRF kwesbaarheid, wat tipies as 'n laag-severiteit probleem beskou word. #### Laboratoriums Kontroleer die laboratoriums om beide scenario's te toets in [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git) ### Verwysings * [https://blog.assetnote.io/2021/03/18/h2c-smuggling/](https://blog.assetnote.io/2021/03/18/h2c-smuggling/) * [https://bishopfox.com/blog/h2c-smuggling-request](https://bishopfox.com/blog/h2c-smuggling-request) * [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git) {% hint style="success" %} Leer & oefen AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\ Leer & oefen GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Ondersteun HackTricks * Kontroleer die [**subskripsie planne**](https://github.com/sponsors/carlospolop)! * **Sluit aan by die** 💬 [**Discord groep**](https://discord.gg/hRep4RUj7f) of die [**telegram groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** * **Deel hacking truuks deur PRs in te dien na die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
{% endhint %}