Upgrade Header Smuggling
Last updated
Last updated
Groupe de sécurité Try Hard
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 :
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.
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
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.
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.
Les outils h2csmuggler de BishopFox et h2csmuggler de assetnote 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.
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 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 :
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.
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.
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.
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 :
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.
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é.
Consultez les laboratoires pour tester les deux scénarios sur https://github.com/0ang3el/websocket-smuggle.git
Try Hard Security Group
