German - Ht
HackTricks Training Twitter Linkedin Sponsor

Upgrade Header Smuggling

Support HackTricks

H2C Smuggling

HTTP2 Über Klartext (H2C)

H2C, oder http2 über Klartext, weicht von der Norm der transienten HTTP-Verbindungen ab, indem es eine standardmäßige HTTP-Verbindung zu einer persistenten aufwertet. Diese aufgewertete 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. Gewöhnlich 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 gefordert wird. 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 wert, 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 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.

Die Tools h2csmuggler von BishopFox und h2csmuggler von assetnote 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.

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

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 aufgrund seiner Validierung nur des Statuscodes hergestellt wurde.

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

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 in https://github.com/0ang3el/websocket-smuggle.git

Referenzen

Unterstützen Sie HackTricks
PreviousHTTP Response Smuggling / DesyncNexthop-by-hop headers

Last updated