- Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
- Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFT**](https://opensea.io/collection/the-peass-family)
- **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Partagez vos astuces de piratage en soumettant des PR au [repo hacktricks](https://github.com/carlospolop/hacktricks) et au [repo hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
Trouvez les vulnérabilités les plus importantes afin de pouvoir les corriger plus rapidement. Intruder suit votre surface d'attaque, effectue des analyses de menaces proactives, trouve des problèmes dans l'ensemble de votre pile technologique, des API aux applications web et aux systèmes cloud. [**Essayez-le gratuitement**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks) dès aujourd'hui.
Une connexion HTTP normale dure généralement seulement pendant la durée d'une seule requête. Cependant, H2C ou "**http2 sur texte clair**" est lorsque **une connexion HTTP transitoire normale est mise à niveau vers une connexion persistante qui utilise le protocole binaire http2** pour communiquer en continu au lieu d'une seule requête utilisant le protocole HTTP en texte clair.
La deuxième partie du smuggling se produit lorsqu'un **reverse proxy est utilisé**. Normalement, lorsque des requêtes HTTP sont faites à un reverse proxy, le proxy gère la requête, traite une série de règles de routage, puis transfère la requête vers l'arrière-plan et renvoie la réponse. Lorsqu'une requête HTTP inclut un en-tête `Connection: Upgrade`, comme pour une connexion websocket, le reverse **proxy maintiendra la connexion persistante** entre le client et le serveur, **permettant la communication continue nécessaire pour ces protocoles**. Pour une connexion H2C, le RFC exige que 3 en-têtes soient présents :
Alors, où est le bug? **Lors de la mise à niveau d'une connexion, le proxy inverse arrête souvent de gérer les requêtes individuelles**, en supposant que une fois la connexion établie, son travail de routage est terminé. En utilisant H2C Smuggling, nous pouvons contourner les règles qu'un proxy inverse utilise lors du traitement des requêtes, telles que le routage basé sur le chemin, l'authentification ou le traitement WAF, à condition que nous puissions établir une connexion H2C en premier.
Notez, à partir de l'explication de la vulnérabilité, que le serveur proxy doit **transmettre l'en-tête Upgrade**, et parfois l'en-tête **Connection** doit également être transmis avec succès.
Par défaut, les services suivants **transmettent** les en-têtes **Upgrade** et **Connection** lors de la transmission par proxy, ce qui permet la contrefaçon h2c dès le départ :
Par défaut, ces services ne transmettent pas les en-têtes Upgrade et Connection lors de la transmission par proxy, mais **peuvent être configurés de manière non sécurisée** (en passant des en-têtes Upgrade et Connection non filtrés) :
L'article de blog original souligne que tous les serveurs ne transmettront pas les en-têtes requis pour une mise à niveau de connexion H2C conforme. Cela signifie que les équilibreurs de charge tels que AWS ALB/CLB, NGINX et Apache Traffic Server, entre autres, **empêcheront une connexion H2C par défaut**. Cependant, à la fin de l'article de blog, il mentionne que "tous les backends n'étaient pas conformes, et nous pouvions **tester avec la variante non conforme `Connection: Upgrade`, où la valeur `HTTP2-Settings` est omise** de l'en-tête `Connection`".
Notez que même si l'URL `proxy_pass` (le point final vers lequel le proxy transmet la connexion) pointait vers un **chemin** spécifique tel que `http://backend:9999/socket.io`, la connexion sera établie avec `http://backend:9999`, vous pouvez donc **contacter tout autre chemin à l'intérieur de ce point final interne en abusant de cette technique. Il n'est donc pas important qu'un chemin soit spécifié dans l'URL de proxy\_pass.**
En utilisant les outils [**https://github.com/BishopFox/h2csmuggler**](https://github.com/BishopFox/h2csmuggler) **et** [**https://github.com/assetnote/h2csmuggler**](https://github.com/assetnote/h2csmuggler), vous pouvez essayer de **contourner les protections imposées** par le proxy en établissant une connexion H2C et accéder aux ressources protégées par le proxy.
Suivez ce lien pour [**plus d'informations sur cette vulnérabilité dans Nginx**](../network-services-pentesting/pentesting-web/nginx.md#proxy\_set\_header-upgrade-and-connection).
Similaire à la technique précédente, celle-ci **au lieu de créer un tunnel HTTP2** vers un point final accessible via un proxy, elle créera un **tunnel WebSocket** dans le même but, **contourner les limitations potentielles des proxies** et communiquer directement avec le point final :
Nous avons un backend qui expose une **API WebSocket publique** et dispose également d'une **API REST interne non accessible** depuis l'extérieur. Un client malveillant souhaite accéder à l'API REST interne.
À la **première** étape, le client envoie une **requête de mise à niveau** au proxy inverse, mais avec une **mauvaise version de protocole** dans l'en-tête `Sec-WebSocket-Version`. Le **proxy** ne valide pas l'en-tête `Sec-WebSocket-Version` et pense que la **requête de mise à niveau est correcte**. Il traduit ensuite la requête vers le backend.
À la deuxième étape, le backend envoie une **réponse avec le code d'état `426` car la version du protocole est incorrecte** dans l'en-tête `Sec-WebSocket-Version`. Cependant, le **proxy inverse ne vérifie pas** suffisamment la réponse du backend (y compris le code d'état) et **pense que le backend est prêt pour la communication WebSocket**. Il traduit ensuite la requête vers le client.
Enfin, le **proxy inverse pense** que **la connexion WebSocket est établie entre le client et le backend**. En réalité, il n'y a pas de connexion WebSocket - le backend a refusé la requête de mise à niveau. En même temps, le proxy maintient la connexion TCP ou TLS entre le client et le backend ouverte. Le **client peut facilement accéder à l'API REST privée en envoyant une requête HTTP via la connexion**.
La majorité des reverse proxies (par exemple NGINX) **vérifient le code d'état renvoyé par le backend** lors de la partie de l'établissement de la connexion. Cela rend l'attaque plus difficile mais pas impossible.
Observons le deuxième scénario. Nous avons un backend qui expose une **API WebSocket publique** et une **API REST publique pour la vérification de l'état de santé**, ainsi qu'une **API REST interne non accessible depuis l'extérieur**. Un client malveillant souhaite accéder à l'API REST interne. NGINX est utilisé comme proxy inverse. L'API WebSocket est disponible sur le chemin `/api/socket.io/` et l'API de vérification de l'état de santé sur le chemin `/api/health`.
L'API de vérification de l'état de santé est invoquée en envoyant une requête POST, le paramètre avec le nom `u` contrôle l'URL. Le backend accède à une ressource externe et renvoie le code d'état au client.
À la **première** étape, le client envoie une requête POST pour invoquer **l'API de vérification de l'état de santé mais avec un en-tête HTTP supplémentaire `Upgrade: websocket`**. NGINX pense que c'est une **requête de mise à niveau normale**, il ne recherche que l'en-tête `Upgrade` en ignorant les autres parties de la requête. Le proxy traduit ensuite la requête vers le backend.
À la **deuxième** étape, le backend invoque l'API de vérification de l'état de santé. Il accède à une ressource externe contrôlée par des utilisateurs malveillants qui renvoie une **réponse HTTP avec le code d'état `101`**. Le backend traduit cette réponse vers le proxy inverse. Étant donné que NGINX ne valide que le code d'état, **il pensera que le backend est prêt pour la communication WebSocket**. Il traduit ensuite la requête vers le client.
Notez que ce scénario est beaucoup plus complexe à exploiter car vous devez être en mesure de contacter un point final qui **renvoie le code d'état 101**.
{% endhint %}
Enfin, **NGINX pense que la connexion WebSocket est établie entre le client et le backend**. En réalité, il n'y a pas de connexion WebSocket - l'API REST de vérification de l'état de santé a été invoquée sur le backend. En même temps, le proxy inverse maintient la connexion TCP ou TLS entre le client et le backend ouverte. Le **client peut facilement accéder à l'API REST privée en envoyant une requête HTTP via la connexion**.
La majorité des reverse proxies devraient être affectés par ce scénario. Cependant, l'exploitation nécessite l'existence d'une vulnérabilité SSRF externe (généralement considérée comme un problème de gravité faible).
### Laboratoires
Consultez les laboratoires pour tester les deux scénarios sur [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git)
Trouvez les vulnérabilités les plus importantes afin de pouvoir les corriger plus rapidement. Intruder suit votre surface d'attaque, effectue des analyses de menace proactives et détecte des problèmes dans l'ensemble de votre pile technologique, des API aux applications web et aux systèmes cloud. [**Essayez-le gratuitement**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks) dès aujourd'hui.
- Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
- Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFT**](https://opensea.io/collection/the-peass-family)
- Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
- **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Partagez vos astuces de piratage en soumettant des PR au référentiel [hacktricks](https://github.com/carlospolop/hacktricks) et [hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
