Learn & practice AWS Hacking:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
H2C, ou **http2 sur texte clair**, s'écarte de la norme des connexions HTTP transitoires en mettant à niveau une **connexion HTTP standard en une connexion persistante**. Cette connexion mise à niveau utilise le protocole binaire http2 pour une communication continue, contrairement à la nature de requête unique de l'HTTP en texte clair.
Le cœur du problème de contournement réside dans l'utilisation d'un **proxy inverse**. Ordinairement, le proxy inverse traite et transmet les requêtes HTTP vers le backend, retournant la réponse du backend après cela. Cependant, lorsque l'en-tête `Connection: Upgrade` est présent dans une requête HTTP (souvent observé avec les connexions websocket), le **proxy inverse maintient une connexion persistante** entre le client et le serveur, facilitant l'échange continu requis par certains protocoles. Pour les connexions H2C, le respect de la RFC nécessite la présence de trois en-têtes spécifiques :
La vulnérabilité survient lorsque, après la mise à niveau d'une connexion, le proxy inverse cesse de gérer les requêtes individuelles, supposant que son travail de routage est terminé après l'établissement de la connexion. L'exploitation de H2C Smuggling permet de contourner les règles de proxy inverse appliquées lors du traitement des requêtes, telles que le routage basé sur le chemin, l'authentification et le traitement WAF, à condition qu'une connexion H2C soit initiée avec succès.
La vulnérabilité dépend de la gestion par le proxy inverse des en-têtes `Upgrade` et parfois `Connection`. Les proxies suivants transmettent intrinsèquement ces en-têtes lors du proxy-pass, permettant ainsi intrinsèquement le H2C smuggling :
En revanche, ces services ne transmettent pas intrinsèquement les deux en-têtes lors du proxy-pass. Cependant, ils peuvent être configurés de manière non sécurisée, permettant le transfert non filtré des en-têtes `Upgrade` et `Connection` :
Il est crucial de noter que tous les serveurs ne transmettent pas intrinsèquement les en-têtes requis pour une mise à niveau de connexion H2C conforme. Ainsi, des serveurs comme AWS ALB/CLB, NGINX et Apache Traffic Server, entre autres, bloquent naturellement les connexions H2C. Néanmoins, il vaut la peine de tester avec la variante non conforme `Connection: Upgrade`, qui exclut la valeur `HTTP2-Settings` de l'en-tête `Connection`, car certains backends peuvent ne pas se conformer aux normes.
Indépendamment du **chemin** spécifique désigné dans l'URL `proxy_pass` (par exemple, `http://backend:9999/socket.io`), la connexion établie par défaut à `http://backend:9999`. Cela permet d'interagir avec n'importe quel chemin au sein de ce point de terminaison interne, en tirant parti de cette technique. Par conséquent, la spécification d'un chemin dans l'URL `proxy_pass` ne restreint pas l'accès.
Les outils [**h2csmuggler by BishopFox**](https://github.com/BishopFox/h2csmuggler) et [**h2csmuggler by assetnote**](https://github.com/assetnote/h2csmuggler) facilitent les tentatives de **contourner les protections imposées par le proxy** en établissant une connexion H2C, permettant ainsi l'accès à des ressources protégées par le proxy.
Pour plus d'informations sur cette vulnérabilité, en particulier concernant NGINX, consultez [**cette ressource détaillée**](../network-services-pentesting/pentesting-web/nginx.md#proxy\_set\_header-upgrade-and-connection).
Le websocket smuggling, contrairement à la création d'un tunnel HTTP2 vers un point de terminaison accessible via un proxy, établit un tunnel Websocket pour contourner les limitations potentielles du proxy et faciliter la communication directe avec le point de terminaison.
Dans ce scénario, un backend qui offre une API WebSocket publique aux côtés d'une API REST interne inaccessible est ciblé par un client malveillant cherchant à accéder à l'API REST interne. L'attaque se déroule en plusieurs étapes :
1. Le client commence par envoyer une requête Upgrade au proxy inverse avec une version de protocole `Sec-WebSocket-Version` incorrecte dans l'en-tête. Le proxy, ne validant pas l'en-tête `Sec-WebSocket-Version`, croit que la requête Upgrade est valide et la transmet au backend.
2. Le backend répond avec un code d'état `426`, indiquant la version de protocole incorrecte dans l'en-tête `Sec-WebSocket-Version`. Le proxy inverse, ignorant le statut de réponse du backend, suppose qu'il est prêt pour la communication WebSocket et relaye la réponse au client.
3. Par conséquent, le proxy inverse est induit en erreur en croyant qu'une connexion WebSocket a été établie entre le client et le backend, alors qu'en réalité, le backend avait rejeté la requête Upgrade. Malgré cela, le proxy maintient une connexion TCP ou TLS ouverte entre le client et le backend, permettant au client d'accéder sans restriction à l'API REST privée via cette connexion.
Les proxies inverses affectés incluent Varnish, qui a refusé de traiter le problème, et la version 1.8.0 ou antérieure du proxy Envoy, les versions ultérieures ayant modifié le mécanisme de mise à niveau. D'autres proxies peuvent également être susceptibles.
Ce scénario implique un backend avec à la fois une API WebSocket publique et une API REST publique pour le contrôle de la santé, ainsi qu'une API REST interne inaccessible. L'attaque, plus complexe, implique les étapes suivantes :
1. Le client envoie une requête POST pour déclencher l'API de contrôle de la santé, incluant un en-tête HTTP supplémentaire `Upgrade: websocket`. NGINX, servant de proxy inverse, interprète cela comme une requête de mise à niveau standard basée uniquement sur l'en-tête `Upgrade`, négligeant les autres aspects de la requête, et la transmet au backend.
2. Le backend exécute l'API de contrôle de la santé, contactant une ressource externe contrôlée par l'attaquant qui renvoie une réponse HTTP avec le code d'état `101`. Cette réponse, une fois reçue par le backend et transmise à NGINX, trompe le proxy en pensant qu'une connexion WebSocket a été établie en raison de sa validation uniquement du code d'état.
> **Avertissement :** La complexité de cette technique augmente car elle nécessite la capacité d'interagir avec un point de terminaison capable de renvoyer un code d'état 101.
En fin de compte, NGINX est trompé en croyant qu'une connexion WebSocket existe entre le client et le backend. En réalité, aucune connexion de ce type n'existe ; l'API REST de contrôle de la santé était la cible. Néanmoins, le proxy inverse maintient la connexion ouverte, permettant au client d'accéder à l'API REST privée à travers elle.
La plupart des proxies inverses sont vulnérables à ce scénario, mais l'exploitation dépend de la présence d'une vulnérabilité SSRF externe, généralement considérée comme un problème de faible gravité.
Vérifiez les laboratoires pour tester les deux scénarios à [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git)
Apprenez et pratiquez le hacking AWS :<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Apprenez et pratiquez le hacking GCP : <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Consultez les [**plans d'abonnement**](https://github.com/sponsors/carlospolop) !
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Partagez des astuces de hacking en soumettant des PR au** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts GitHub.
