<summary><strong>Erlernen 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)!
* **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 in eine persistente umwandelt. Diese aufgerüstete Verbindung verwendet das binäre http2-Protokoll 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 Header `Connection: Upgrade` 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, der von bestimmten Protokollen benötigt wird, zu ermöglichen. 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 Upgrade einer Verbindung aufhört, einzelne Anfragen zu verwalten und davon ausgeht, dass seine Routing-Aufgabe nach der Verbindungsherstellung 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 initiiert wird.
Die Schwachstelle hängt von der Behandlung der `Upgrade`- und manchmal der `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 nicht inhärent während des Proxy-Passes weiter. Sie können jedoch unsicher konfiguriert sein und das ungefilterte Weiterleiten der `Upgrade`- und `Connection`-Header 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. Daher 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 detaillierte Ressource**](../network-services-pentesting/pentesting-web/nginx.md#proxy\_set\_header-upgrade-and-connection).
Im Gegensatz zur Erstellung eines HTTP2-Tunnels zu einem über einen Proxy erreichbaren Endpunkt richtet Websocket Smuggling 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 den Antwortstatus 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, einschließlich eines zusätzlichen HTTP-Headers `Upgrade: websocket`. NGINX, der als Reverse-Proxy fungiert, interpretiert dies als eine Standard-Upgrade-Anfrage, basierend ausschließlich auf dem `Upgrade`-Header, 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, in den 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 in der Lage ist, einen Statuscode 101 zurückzugeben.
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)
* **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.
