German - Ht
HackTricks Training Twitter Linkedin Sponsor

Upgrade Header Smuggling

Erlernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Try Hard Security Group

LogoJoin the Try Hard Security Discord Server!Discord

H2C Smuggling

HTTP2 über Klartext (H2C)

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:

Upgrade: h2c
HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
Connection: Upgrade, HTTP2-Settings

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.

Anfällige Proxies

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:

  • HAProxy

  • Traefik

  • Nuster

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:

  • 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 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 und h2csmuggler von assetnote 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.

Websocket Smuggling

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.

Szenario 1

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.

https://github.com/0ang3el/websocket-smuggle/raw/master/img/2-4.png

Szenario 2

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.

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 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.

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 einer externen SSRF-Schwachstelle ab, die in der Regel als geringfügiges Problem angesehen wird.

Labs

Überprüfen Sie die Labs, um beide Szenarien unter https://github.com/0ang3el/websocket-smuggle.git zu testen.

Referenzen

Try Hard Security Group

LogoJoin the Try Hard Security Discord Server!Discord
Erlernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

PreviousHTTP Response Smuggling / DesyncNexthop-by-hop headers

Last updated