Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/h2c-smuggling.md

14 KiB
Raw Blame History

Mise à niveau du Header Smuggling

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

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 dès aujourd'hui.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

H2C Smuggling

HTTP2 sur texte clair (H2C)

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 :

Upgrade: h2c
HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
Connection: Upgrade, HTTP2-Settings

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.

Proxies vulnérables

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 :

  • HAProxy
  • Traefik
  • Nuster

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) :

  • AWS ALB/CLB
  • NGINX
  • Apache
  • Squid
  • Varnish
  • Kong
  • Envoy
  • Apache Traffic Server

Exploitation

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

{% hint style="danger" %} 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. {% endhint %}

En utilisant les outils https://github.com/BishopFox/h2csmuggler et 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.

Contrefaçon de WebSocket

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 :

Scénario 1

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.

Il a été constaté que les reverse proxies suivants sont affectés :

  • Varnish - l'équipe a refusé de corriger le problème décrit.
  • Proxy Envoy 1.8.0 (ou plus ancien) - dans les versions plus récentes, le mécanisme de mise à niveau a été modifié.
  • Autres - À déterminer.

Scénario 2

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.

{% hint style="warning" %} 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

Références

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 dès aujourd'hui.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥