Upgrade Header Smuggling

Reading time: 7 minutes

H2C Smuggling

HTTP2 Over Cleartext (H2C)

H2C, ou http2 sur cleartext, 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 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 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 :

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

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 intrinsèquement ces en-têtes lors du proxy-pass, permettant ainsi intrinsèquement le H2C smuggling :

• HAProxy
• Traefik
• Nuster

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 :

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

Les outils h2csmuggler by BishopFox et h2csmuggler by assetnote 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.

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 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, considère la requête Upgrade 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, négligeant le statut de réponse du backend, suppose qu'il est prêt pour la communication WebSocket et relaie 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.

Scénario 2

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.

Warning: 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é.

Labs

Vérifiez les labs pour tester les deux scénarios dans https://github.com/0ang3el/websocket-smuggle.git

Références

• https://blog.assetnote.io/2021/03/18/h2c-smuggling/
• https://bishopfox.com/blog/h2c-smuggling-request
• https://github.com/0ang3el/websocket-smuggle.git