<summary><strong>Lernen Sie AWS-Hacking von Null auf Held mit</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merch**](https://peass.creator-spring.com)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) Github-Repositories senden.
H2C oder **http2 über Klartext** weicht von der Norm transienter HTTP-Verbindungen ab, indem es eine Standard-HTTP-Verbindung auf eine persistente Verbindung **aufrüstet**. Diese aufgerüstete Verbindung verwendet das http2-Binärprotokoll für die fortlaufende Kommunikation, im Gegensatz zur einmaligen Anfrage von Klartext-HTTP.
Der Kern des Schmuggelproblems entsteht durch die Verwendung eines **Reverse-Proxys**. Normalerweise verarbeitet der Reverse-Proxy HTTP-Anfragen und leitet sie an das Backend weiter, um anschließend die Antwort des Backends zurückzugeben. Wenn jedoch der `Connection: Upgrade`-Header in einer HTTP-Anfrage vorhanden ist (üblicherweise bei WebSocket-Verbindungen), **pflegt der Reverse-Proxy eine persistente Verbindung** zwischen Client und Server, um den kontinuierlichen Austausch zu ermöglichen, der von bestimmten Protokollen benötigt wird. Für H2C-Verbindungen erfordert die Einhaltung des RFC das Vorhandensein von drei spezifischen Headern:
Die Schwachstelle tritt auf, wenn der Reverse-Proxy nach einem Verbindungsupgrade aufhört, einzelne Anfragen zu verwalten und davon ausgeht, dass seine Routing-Aufgabe nach der Verbindungseinrichtung abgeschlossen ist. Die Ausnutzung von H2C Smuggling ermöglicht die Umgehung von Reverse-Proxy-Regeln, die während der Anfrageverarbeitung angewendet werden, wie z. B. routing basierend auf Pfaden, Authentifizierung und WAF-Verarbeitung, vorausgesetzt, dass eine H2C-Verbindung erfolgreich hergestellt wurde.
Die Schwachstelle hängt von der Behandlung der `Upgrade`- und manchmal `Connection`-Header durch den Reverse-Proxy ab. Die folgenden Proxies leiten diese Header während des Proxy-Passes inhärent weiter, was H2C Smuggling inhärent ermöglicht:
Im Gegensatz dazu leiten diese Dienste die beiden Header während des Proxy-Passes nicht inhärent weiter. Sie können jedoch unsicher konfiguriert sein und das ungefilterte Weiterleiten von `Upgrade`- und `Connection`-Headern ermöglichen:
Es ist wichtig zu beachten, dass nicht alle Server die für ein konformes H2C-Verbindungsupgrade erforderlichen Header inhärent weiterleiten. Daher blockieren Server wie AWS ALB/CLB, NGINX und Apache Traffic Server natürlicherweise H2C-Verbindungen. Es ist dennoch sinnvoll, es 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.
Unabhängig vom spezifischen **Pfad**, der in der `proxy_pass`-URL festgelegt ist (z. B. `http://backend:9999/socket.io`), wird die hergestellte Verbindung standardmäßig auf `http://backend:9999` zurückgesetzt. Dies ermöglicht die Interaktion mit jedem Pfad innerhalb dieses internen Endpunkts unter Verwendung dieser Technik. Folglich beschränkt die Angabe eines Pfads in der `proxy_pass`-URL nicht den Zugriff.
Die Tools [**h2csmuggler von BishopFox**](https://github.com/BishopFox/h2csmuggler) und [**h2csmuggler von assetnote**](https://github.com/assetnote/h2csmuggler) erleichtern Versuche, **von Proxys auferlegte Schutzmaßnahmen zu umgehen**, indem eine H2C-Verbindung hergestellt wird, wodurch der Zugriff auf Ressourcen ermöglicht wird, die durch den Proxy geschützt sind.
Für weitere Informationen zu dieser Schwachstelle, insbesondere zu NGINX, siehe [**diese ausführliche Ressource**](../network-services-pentesting/pentesting-web/nginx.md#proxy\_set\_header-upgrade-and-connection).
Websocket Smuggling richtet im Gegensatz zur Erstellung eines HTTP2-Tunnels zu einem über einen Proxy erreichbaren Endpunkt einen Websocket-Tunnel ein, um potenzielle Proxy-Einschränkungen zu umgehen und die direkte Kommunikation mit dem Endpunkt zu erleichtern.
In diesem Szenario zielt ein bösartiger Client auf einen Backend ab, der eine öffentliche WebSocket-API neben einer nicht zugänglichen internen REST-API anbietet. Der Angriff erfolgt 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, hält die Upgrade-Anfrage für gültig und leitet sie an das Backend weiter.
2. Das Backend antwortet mit dem Statuscode `426`, der die falsche Protokollversion im `Sec-WebSocket-Version`-Header angibt. Der Reverse-Proxy, der die Antwort des Backends übersieht, geht davon aus, dass die WebSocket-Kommunikation bereit ist, 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 Client und Backend hergestellt wurde, während das Backend die Upgrade-Anfrage abgelehnt hat. Trotzdem unterhält der Proxy eine offene TCP- oder TLS-Verbindung zwischen Client und Backend, was dem Client uneingeschränkten Zugriff auf die private REST-API über diese Verbindung ermöglicht.
Betroffene Reverse-Proxys sind Varnish, der sich weigerte, das Problem anzugehen, und der Envoy-Proxy in der Version 1.8.0 oder älter, wobei spätere Versionen den Upgrade-Mechanismus geändert haben. Andere Proxys können ebenfalls anfällig sein.
Dieses Szenario betrifft ein Backend mit einer öffentlichen WebSocket-API und einer öffentlichen REST-API für die Gesundheitsprüfung sowie einer nicht zugänglichen internen REST-API. Der komplexere Angriff umfasst die folgenden Schritte:
1. Der Client sendet eine POST-Anfrage, um die Health-Check-API auszulösen, und fügt einen zusätzlichen HTTP-Header `Upgrade: websocket` hinzu. NGINX, der als Reverse-Proxy fungiert, interpretiert dies als Standard-Upgrade-Anfrage basierend ausschließlich auf dem `Upgrade`-Header, ohne die anderen Aspekte der Anfrage zu berücksichtigen, und leitet sie an das Backend weiter.
2. Das Backend führt die Health-Check-API aus und greift auf eine vom Angreifer kontrollierte externe Ressource zu, die 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, da er nur den Statuscode validiert, und lässt ihn glauben, dass eine WebSocket-Verbindung aufgebaut wurde.
> **Warnung:** Die Komplexität dieser Technik steigt, da sie die Fähigkeit erfordert, mit einem Endpunkt zu interagieren, der einen Statuscode 101 zurückgeben kann.
Letztendlich wird NGINX getäuscht und glaubt, dass eine WebSocket-Verbindung zwischen Client und Backend besteht. In Wirklichkeit besteht keine solche Verbindung; die Health-Check-REST-API war das Ziel. Dennoch hält der Reverse-Proxy die Verbindung offen und ermöglicht es dem Client, über sie auf die private REST-API zuzugreifen.
Die meisten Reverse-Proxys sind anfällig für dieses Szenario, aber die Ausnutzung hängt von einer externen SSRF-Schwachstelle ab, die in der Regel als geringfügiges Problem angesehen wird.
Überprüfen Sie die Labs, um beide Szenarien unter [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git) zu testen.
<summary><strong>Erlernen Sie AWS-Hacking von Grund auf mit</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks im PDF-Format herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories einreichen.
