# 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 %} **Try Hard Security Group**
{% embed url="https://discord.gg/tryhardsecurity" %} *** ### H2C Smuggling #### HTTP2 Über Klartext (H2C) H2C, oder **http2 über Klartext**, weicht von der Norm transienter HTTP-Verbindungen ab, indem es eine standardmäßige HTTP-**Verbindung in eine persistente umwandelt**. Diese aktualisierte Verbindung nutzt das http2-Binärprotokoll für die fortlaufende Kommunikation, im Gegensatz zur Einzelanfrage-Natur von Klartext-HTTP. Der Kern des Smuggling-Problems ergibt sich aus der Verwendung eines **Reverse Proxys**. In der Regel verarbeitet der Reverse Proxy HTTP-Anfragen und leitet sie an das Backend weiter, wobei er die Antwort des Backends danach zurückgibt. Wenn jedoch der `Connection: Upgrade`-Header in einer HTTP-Anfrage vorhanden ist (häufig bei Websocket-Verbindungen zu sehen), hält der Reverse **Proxy eine persistente Verbindung** zwischen Client und Server aufrecht, was den kontinuierlichen Austausch ermöglicht, der von bestimmten Protokollen erforderlich ist. Für H2C-Verbindungen erfordert die Einhaltung des RFC das Vorhandensein von drei spezifischen Headern: ``` Upgrade: h2c HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA Connection: Upgrade, HTTP2-Settings ``` Die Schwachstelle entsteht, wenn der Reverse-Proxy nach dem Upgrade einer Verbindung aufhört, einzelne Anfragen zu verwalten, und davon ausgeht, dass seine Aufgabe des Routings nach der Herstellung der Verbindung abgeschlossen ist. Die Ausnutzung von H2C Smuggling ermöglicht es, die vom Reverse-Proxy während der Anfrageverarbeitung angewendeten Regeln zu umgehen, wie z.B. pfadbasierte Weiterleitung, Authentifizierung und WAF-Verarbeitung, vorausgesetzt, eine H2C-Verbindung wird erfolgreich initiiert. #### Verwundbare Proxys Die Schwachstelle hängt von der Handhabung der `Upgrade`- und manchmal `Connection`-Header durch den Reverse-Proxy ab. Die folgenden Proxys leiten diese Header während des Proxy-Pass inherently weiter und ermöglichen somit H2C Smuggling: * HAProxy * Traefik * Nuster Im Gegensatz dazu leiten diese Dienste nicht inherent beide Header während des Proxy-Pass weiter. Sie können jedoch unsicher konfiguriert werden, was eine ungefilterte Weiterleitung der `Upgrade`- und `Connection`-Header ermöglicht: * AWS ALB/CLB * NGINX * Apache * Squid * Varnish * Kong * Envoy * Apache Traffic Server #### Ausnutzung Es ist wichtig zu beachten, dass nicht alle Server die für ein konformes H2C-Verbindungsupgrade erforderlichen Header inherent weiterleiten. Daher blockieren Server wie AWS ALB/CLB, NGINX und Apache Traffic Server unter anderem natürlich H2C-Verbindungen. Dennoch ist es sinnvoll, mit der nicht konformen `Connection: Upgrade`-Variante zu testen, die den `HTTP2-Settings`-Wert aus dem `Connection`-Header ausschließt, da einige Backends möglicherweise nicht den Standards entsprechen. {% hint style="danger" %} Unabhängig von dem spezifischen **Pfad**, der in der `proxy_pass`-URL angegeben ist (z.B. `http://backend:9999/socket.io`), wird die hergestellte Verbindung standardmäßig auf `http://backend:9999` gesetzt. Dies ermöglicht die Interaktion mit jedem Pfad innerhalb dieses internen Endpunkts, indem diese Technik genutzt wird. Folglich schränkt die Angabe eines Pfades in der `proxy_pass`-URL den Zugriff nicht ein. {% endhint %} Die Tools [**h2csmuggler von BishopFox**](https://github.com/BishopFox/h2csmuggler) und [**h2csmuggler von assetnote**](https://github.com/assetnote/h2csmuggler) erleichtern Versuche, **Proxy-geschützte Ressourcen zu umgehen**, indem sie eine H2C-Verbindung herstellen und so den Zugriff auf durch den Proxy geschützte Ressourcen ermöglichen. Für weitere Informationen zu dieser Schwachstelle, insbesondere in Bezug auf NGINX, siehe [**diese detaillierte Ressource**](../network-services-pentesting/pentesting-web/nginx.md#proxy\_set\_header-upgrade-and-connection). ## Websocket Smuggling Websocket Smuggling, im Gegensatz zur Erstellung eines HTTP2-Tunnels zu einem über einen Proxy zugänglichen Endpunkt, etabliert einen Websocket-Tunnel, um potenzielle Proxy-Beschränkungen zu umgehen und die direkte Kommunikation mit dem Endpunkt zu ermöglichen. ### Szenario 1 In diesem Szenario wird ein Backend, das eine öffentliche WebSocket-API neben einer nicht zugänglichen internen REST-API anbietet, von einem böswilligen Client angegriffen, der Zugriff auf die interne REST-API sucht. Der Angriff entfaltet sich in mehreren Schritten: 1. Der Client initiiert, indem er eine Upgrade-Anfrage an den Reverse-Proxy mit einer falschen `Sec-WebSocket-Version`-Protokollversion im Header sendet. Der Proxy, der den `Sec-WebSocket-Version`-Header nicht validiert, glaubt, dass die Upgrade-Anfrage gültig ist, und leitet sie an das Backend weiter. 2. Das Backend antwortet mit einem Statuscode `426`, der die falsche Protokollversion im `Sec-WebSocket-Version`-Header anzeigt. Der Reverse-Proxy, der den Status der Backend-Antwort übersieht, geht von der Bereitschaft zur WebSocket-Kommunikation aus und leitet die Antwort an den Client weiter. 3. Folglich wird der Reverse-Proxy in die Irre geführt und glaubt, dass eine WebSocket-Verbindung zwischen dem Client und dem Backend hergestellt wurde, während das Backend die Upgrade-Anfrage tatsächlich abgelehnt hat. Dennoch hält der Proxy eine offene TCP- oder TLS-Verbindung zwischen dem Client und dem Backend aufrecht, was dem Client ungehinderten Zugriff auf die private REST-API über diese Verbindung ermöglicht. Betroffene Reverse-Proxys sind Varnish, das sich weigerte, das Problem zu beheben, und Envoy-Proxy-Version 1.8.0 oder älter, wobei spätere Versionen den Upgrade-Mechanismus geändert haben. Auch andere Proxys können anfällig sein. ![https://github.com/0ang3el/websocket-smuggle/raw/master/img/2-4.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/2-4.png) ### Szenario 2 Dieses Szenario umfasst ein Backend mit sowohl einer öffentlichen WebSocket-API als auch einer öffentlichen REST-API zur Gesundheitsüberprüfung, zusammen mit einer nicht zugänglichen internen REST-API. Der Angriff, der komplexer ist, umfasst die folgenden Schritte: 1. Der Client sendet eine POST-Anfrage, um die Gesundheitsüberprüfungs-API auszulösen, einschließlich eines zusätzlichen HTTP-Headers `Upgrade: websocket`. NGINX, das als Reverse-Proxy fungiert, interpretiert dies als eine Standard-Upgrade-Anfrage, die ausschließlich auf dem `Upgrade`-Header basiert, und übersieht die anderen Aspekte der Anfrage und leitet sie an das Backend weiter. 2. Das Backend führt die Gesundheitsüberprüfungs-API aus und kontaktiert eine externe Ressource, die vom Angreifer kontrolliert wird und eine HTTP-Antwort mit dem Statuscode `101` zurückgibt. Diese Antwort, sobald sie vom Backend empfangen und an NGINX weitergeleitet wird, täuscht den Proxy darüber hinweg, dass eine WebSocket-Verbindung hergestellt wurde, da er nur den Statuscode validiert. ![https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png) > **Warnung:** Die Komplexität dieser Technik steigt, da sie die Fähigkeit erfordert, mit einem Endpunkt zu interagieren, der in der Lage ist, einen Statuscode 101 zurückzugeben. Letztendlich wird NGINX in die Irre geführt und glaubt, dass eine WebSocket-Verbindung zwischen dem Client und dem Backend besteht. In Wirklichkeit existiert keine solche Verbindung; die Gesundheitsüberprüfungs-REST-API war das Ziel. Dennoch hält der Reverse-Proxy die Verbindung offen, was dem Client den Zugriff auf die private REST-API über ihn ermöglicht. ![https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-5.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-5.png) Die meisten Reverse-Proxys sind anfällig für dieses Szenario, aber die Ausnutzung hängt von der Existenz einer externen SSRF-Schwachstelle ab, die typischerweise als geringfügiges Problem angesehen wird. #### Labs Überprüfen Sie die Labs, um beide Szenarien zu testen unter [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git) ### Referenzen * [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) **Try Hard Security Group**
{% embed url="https://discord.gg/tryhardsecurity" %} {% hint style="success" %} Lernen & üben Sie AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\ Lernen & üben Sie GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Unterstützen Sie HackTricks * Überprüfen Sie die [**Abonnementpläne**](https://github.com/sponsors/carlospolop)! * **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** * **Teilen Sie Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repos senden.
{% endhint %}