# Amélioration du Header Smuggling
Apprenez le piratage AWS de zéro à héros avechtARTE (Expert en équipe rouge AWS de HackTricks)!
Autres façons de soutenir HackTricks :
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts GitHub.
**Groupe de sécurité Try Hard**
{% embed url="https://discord.gg/tryhardsecurity" %}
***
### H2C Smuggling
#### HTTP2 sur texte clair (H2C)
H2C, ou **http2 sur texte clair**, s'éloigne de la norme des connexions HTTP transitoires en améliorant une connexion HTTP standard en une connexion persistante. Cette connexion améliorée utilise le protocole binaire http2 pour la communication continue, contrairement à la nature de requête unique de HTTP en texte clair.
Le cœur du problème de smuggling réside dans l'utilisation d'un **proxy inverse**. Ordinairement, le proxy inverse traite et transfère les requêtes HTTP vers l'arrière-plan, renvoyant ensuite la réponse de l'arrière-plan. Cependant, lorsque l'en-tête `Connection: Upgrade` est présent dans une requête HTTP (couramment 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 du RFC nécessite la présence de trois en-têtes spécifiques :
```
Upgrade: h2c
HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
Connection: Upgrade, HTTP2-Settings
```
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 du proxy inverse appliquées lors du traitement des requêtes, telles que le routage basé sur le chemin, l'authentification et le traitement WAF, en supposant qu'une connexion H2C est initiée avec succès.
#### Proxies Vulnérables
La vulnérabilité dépend de la gestion par le proxy inverse des en-têtes `Upgrade` et parfois `Connection`. Les proxies suivants transmettent ces en-têtes de manière inhérente lors du proxy-pass, permettant ainsi de manière inhérente le H2C smuggling :
* HAProxy
* Traefik
* Nuster
En revanche, ces services ne transmettent pas de manière inhérente les deux en-têtes lors du proxy-pass. Cependant, ils peuvent être configurés de manière non sécurisée, permettant la transmission non filtrée des en-têtes `Upgrade` et `Connection` :
* AWS ALB/CLB
* NGINX
* Apache
* Squid
* Varnish
* Kong
* Envoy
* Apache Traffic Server
#### Exploitation
Il est crucial de noter que tous les serveurs ne transmettent pas de manière inhérente 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 est utile 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 être conformes aux normes.
{% hint style="danger" %}
Indépendamment du **chemin** spécifique désigné dans l'URL `proxy_pass` (par exemple, `http://backend:9999/socket.io`), la connexion établie se limite par défaut à `http://backend:9999`. Cela permet d'interagir avec n'importe quel chemin à l'intérieur de ce point de terminaison interne, en exploitant cette technique. Par conséquent, la spécification d'un chemin dans l'URL `proxy_pass` ne restreint pas l'accès.
{% endhint %}
Les outils [**h2csmuggler de BishopFox**](https://github.com/BishopFox/h2csmuggler) et [**h2csmuggler de assetnote**](https://github.com/assetnote/h2csmuggler) facilitent les tentatives de **contournement des protections imposées par le proxy** en établissant une connexion H2C, permettant ainsi l'accès aux 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).
## Websocket Smuggling
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.
### Scénario 1
Dans ce scénario, un backend offrant 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 demande de mise à niveau au proxy inverse avec une version de protocole `Sec-WebSocket-Version` incorrecte dans l'en-tête. Le proxy, ne parvenant pas à valider l'en-tête `Sec-WebSocket-Version`, considère la demande de mise à niveau comme 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 la disponibilité de la communication Websocket et transmet la réponse au client.
3. Par conséquent, le proxy inverse est trompé en croyant qu'une connexion Websocket a été établie entre le client et le backend, alors qu'en réalité, le backend a rejeté la demande de mise à niveau. Malgré cela, le proxy maintient une connexion TCP ou TLS ouverte entre le client et le backend, permettant au client un accès illimité à l'API REST privée via cette connexion.
Les proxies inverses affectés incluent Varnish, qui a refusé de traiter le problème, et le proxy Envoy version 1.8.0 ou plus ancienne, les versions ultérieures ayant modifié le mécanisme de mise à niveau. D'autres proxies peuvent également être vulnérables.
### Scénario 2
Ce scénario implique un backend avec à la fois une API Websocket publique et une API REST publique pour la vérification de l'état de 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 vérification de l'état de santé, incluant un en-tête HTTP supplémentaire `Upgrade: websocket`. NGINX, agissant en tant que proxy inverse, interprète cela comme une demande 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 vérification de l'état de santé, se connectant à 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 telle connexion n'existe ; l'API REST de vérification de l'état de 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 celle-ci.
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é.
#### 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)
### Références
* [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**
{% embed url="https://discord.gg/tryhardsecurity" %}
Apprenez le piratage AWS de zéro à héros avechtARTE (HackTricks AWS Red Team Expert)!
D'autres moyens de soutenir HackTricks :
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Rejoignez** 💬 le [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux** [**dépôts GitHub HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
