mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-23 05:03:35 +00:00
132 lines
11 KiB
Markdown
132 lines
11 KiB
Markdown
# Upgrade Header Smuggling
|
|
|
|
<details>
|
|
|
|
<summary><strong>Erlernen Sie AWS-Hacking von Null auf Held mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
|
|
|
Andere Möglichkeiten, HackTricks zu unterstützen:
|
|
|
|
* 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)!
|
|
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merch**](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.
|
|
|
|
</details>
|
|
|
|
**Try Hard Security Group**
|
|
|
|
<figure><img src="/.gitbook/assets/telegram-cloud-document-1-5159108904864449420.jpg" alt=""><figcaption></figcaption></figure>
|
|
|
|
{% embed url="https://discord.gg/tryhardsecurity" %}
|
|
|
|
***
|
|
|
|
### H2C Smuggling <a href="#http2-over-cleartext-h2c" id="http2-over-cleartext-h2c"></a>
|
|
|
|
#### HTTP2 über Klartext (H2C) <a href="#http2-over-cleartext-h2c" id="http2-over-cleartext-h2c"></a>
|
|
|
|
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 <a href="#exploitation" id="exploitation"></a>
|
|
|
|
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 <a href="#exploitation" id="exploitation"></a>
|
|
|
|
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. Daher beschränkt die Angabe eines Pfads in der `proxy_pass`-URL nicht den Zugriff.
|
|
{% endhint %}
|
|
|
|
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).
|
|
|
|
## 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.
|
|
|
|
|
|
|
|
### 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.
|
|
|
|
|
|
|
|
> **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.
|
|
|
|
#### Labs
|
|
|
|
Ü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.
|
|
|
|
### Referenzen
|
|
|
|
* [https://blog.assetnote.io/2021/03/18/h2c-smuggling/](https://blog.assetnote.io/2021/03/18/h2c-smuggling/)
|
|
* [https://bishopfox.com/blog/h2c-smuggling-request](https://bishopfox.com/blog/h2c-smuggling-request)
|
|
* [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git)
|
|
|
|
|
|
**Try Hard Security Group**
|
|
|
|
<figure><img src="/.gitbook/assets/telegram-cloud-document-1-5159108904864449420.jpg" alt=""><figcaption></figcaption></figure>
|
|
|
|
{% embed url="https://discord.gg/tryhardsecurity" %}
|
|
|
|
<details>
|
|
|
|
<summary><strong>Erlernen Sie AWS-Hacking von Grund auf mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
|
|
|
Andere Möglichkeiten, HackTricks zu unterstützen:
|
|
|
|
* 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)
|
|
* 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 einreichen.
|
|
|
|
</details>
|