Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 22:52:06 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/h2c-smuggling.md

11 KiB
Raw Blame History

Upgrade Header Smuggling

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

Andere Möglichkeiten, HackTricks zu unterstützen:

H2C-Schmuggel

HTTP2 über Klartext (H2C)

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:

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

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.

Anfällige Proxies

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:

  • HAProxy
  • Traefik
  • Nuster

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:

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

{% hint style="danger" %} 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. {% endhint %}

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 ausführliche Ressource.

Websocket Smuggling

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.

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

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

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

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

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

Andere Möglichkeiten, HackTricks zu unterstützen: