<summary><strong>Lernen 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 bewerben 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-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 senden.
Finden Sie die wichtigsten Sicherheitslücken, damit Sie sie schneller beheben können. Intruder verfolgt Ihre Angriffsfläche, führt proaktive Bedrohungsscans durch und findet Probleme in Ihrer gesamten Technologie-Stack, von APIs über Webanwendungen bis hin zu Cloud-Systemen. [**Probieren Sie es noch heute kostenlos aus**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks).
H2C oder **http2 über Klartext** weicht von der Norm transienter HTTP-Verbindungen ab, indem es eine Standard-HTTP-**Verbindung zu einer dauerhaften Verbindung** aufrüstet. Diese aufgerüstete Verbindung verwendet das http2-Binärprotokoll für die fortlaufende Kommunikation, im Gegensatz zur einmaligen Anfrage-Natur von Klartext-HTTP.
Das Kernproblem des Schmuggels entsteht durch die Verwendung eines **Reverse-Proxys**. Normalerweise verarbeitet der Reverse-Proxy HTTP-Anfragen und leitet sie an das Backend weiter, wobei er die Antwort des Backends zurückgibt. Wenn jedoch der Header `Connection: Upgrade` in einer HTTP-Anfrage vorhanden ist (was häufig bei WebSocket-Verbindungen der Fall ist), behält der Reverse-Proxy eine dauerhafte Verbindung zwischen Client und Server bei, 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 dem Upgrade einer Verbindung aufhört, einzelne Anfragen zu verwalten und davon ausgeht, dass seine Aufgabe der Routing nach der Verbindungsherstellung abgeschlossen ist. Durch die Ausnutzung von H2C Smuggling kann die Umgehung von Reverse Proxy-Regeln während der Anfrageverarbeitung ermöglicht werden, wie z.B. Routing basierend auf dem Pfad, Authentifizierung und WAF-Verarbeitung, vorausgesetzt, dass eine H2C-Verbindung erfolgreich hergestellt 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 inhärent während des Proxy-Passes weiter und ermöglichen somit H2C Smuggling:
Diese Dienste leiten beide Header nicht inhärent während des Proxy-Passes weiter. Sie können jedoch unsicher konfiguriert sein und eine ungefilterte Weiterleitung 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 jedoch sinnvoll, es mit der nicht konformen Variante `Connection: Upgrade` zu testen, bei der der Wert `HTTP2-Settings` aus dem `Connection`-Header ausgeschlossen ist, da einige Backends möglicherweise nicht den Standards entsprechen.
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` festgelegt. Dadurch ist eine Interaktion mit jedem Pfad innerhalb dieses internen Endpunkts möglich, indem diese Technik genutzt wird. Die Angabe eines Pfads in der `proxy_pass`-URL beschränkt somit nicht den Zugriff.
Die Tools [**h2csmuggler von BishopFox**](https://github.com/BishopFox/h2csmuggler) und [**h2csmuggler von assetnote**](https://github.com/assetnote/h2csmuggler) erleichtern den Versuch, durch Herstellung einer H2C-Verbindung Proxy-bedingte Schutzmaßnahmen zu umgehen und somit auf Ressourcen zuzugreifen, 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).
Im Gegensatz zur Erstellung eines HTTP2-Tunnels zu einem über einen Proxy erreichbaren Endpunkt wird beim Websocket Smuggling ein Websocket-Tunnel hergestellt, um potenzielle Proxy-Beschränkungen zu umgehen und eine direkte Kommunikation mit dem Endpunkt zu ermöglichen.
In diesem Szenario wird ein Backend, das eine öffentliche WebSocket-API neben einer nicht zugänglichen internen REST-API anbietet, von einem bösartigen Client angegriffen, der Zugriff auf die interne REST-API erhalten möchte. Der Angriff erfolgt in mehreren Schritten:
1. Der Client initiiert den Vorgang, indem er eine Upgrade-Anfrage an den Reverse Proxy sendet und eine falsche `Sec-WebSocket-Version`-Protokollversion im Header angibt. 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 auf die falsche Protokollversion im `Sec-WebSocket-Version`-Header hinweist. Der Reverse Proxy, der den Antwortstatus des Backends übersieht, geht davon aus, dass eine WebSocket-Kommunikation möglich ist, und leitet die Antwort an den Client weiter.
3. Der Reverse Proxy wird irrtümlicherweise dazu verleitet, zu glauben, dass eine WebSocket-Verbindung zwischen dem Client und dem Backend hergestellt wurde, obwohl das Backend die Upgrade-Anfrage abgelehnt hat. Trotzdem unterhält der Proxy eine offene TCP- oder TLS-Verbindung zwischen dem Client und dem Backend, die es dem Client ermöglicht, über diese Verbindung uneingeschränkten Zugriff auf die private REST-API zu erhalten.
Betroffene Reverse Proxies sind Varnish, die sich weigerten, das Problem anzugehen, und Envoy Proxy Version 1.8.0 oder älter, wobei spätere Versionen den Upgrade-Mechanismus geändert haben. Andere Proxies können ebenfalls anfällig sein.
Dieses Szenario betrifft ein Backend mit einer öffentlichen WebSocket-API und einer öffentlichen REST-API zur Überprüfung der Gesundheit 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 standardmäßige Upgrade-Anfrage, basierend ausschließlich auf dem `Upgrade`-Header, und vernachlässigt die anderen Aspekte der Anfrage, 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 täuscht den Proxy, nachdem sie vom Backend empfangen und an NGINX weitergeleitet wurde, dazu, dass eine WebSocket-Verbindung aufgrund der Validierung nur des Statuscodes hergestellt 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 dazu gebracht, zu glauben, dass eine WebSocket-Verbindung zwischen dem Client und dem Backend besteht. In Wirklichkeit besteht keine solche Verbindung; die Ziel war die Health Check REST-API. 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 Proxies 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.
