Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-12 14:22:56 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md

11 KiB
Raw Blame History

Détournement de requête dans les rétrogradations HTTP/2

Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :

Origines

L'origine principale de cette vulnérabilité est le fait que le reverse proxy va communiquer avec le client en utilisant HTTP/2 puis il va transformer cette communication avec le serveur back-end en HTTP/1.1.

Le problème avec cette approche est que l'utilisateur va pouvoir injecter des en-têtes inutilement dans la communication HTTP/2 qui probablement ne seront pas vérifiés par le proxy. Mais ensuite, lorsque ceux-ci sont injectés à l'aveugle dans la communication HTTP/1.1, une attaque de détournement de requête peut être réalisée.

Exemples

Désynchronisation H2.CL

La spécification HTTP/2 indique que l'en-tête Content-Length n'est pas nécessaire mais peut être indiqué. Par conséquent, le reverse proxy va traiter tout le contenu envoyé par les utilisateurs comme la requête, mais ensuite, lors de la rétrogradation en HTTP/1.1, cet en-tête va être injecté dans la requête et donc, le serveur back-end traitera la requête comme 2 requêtes différentes comme vous pouvez le voir dans l'image ci-dessous :

Détournement H2.TE et Hijack de Token d'URL

La spécification HTTP/2 indique également que tout message contenant des champs d'en-tête spécifiques à la connexion doit être traité comme malformé... mais si vous ne suivez pas cette règle, vous êtes vulnérable.

Cette technique a été abusée sur le load balancer AWS, donc s'assurer que les utilisateurs accèdent à un en-tête Host pointant vers un serveur contrôlé par l'attaquant les fera accéder à ce serveur.

Détournement H2.TE et Hijack d'En-tête

C'est exactement la même technique que précédemment, mais en vérifiant les requêtes, James a remarqué que les clients demandaient à lui envoyer leurs identifiants, il a donc juste modifié son serveur pour permettre à CORS de lui envoyer les identifiants des gens :

H2.TE via Injection d'En-tête de Requête

HTTP/2 n'autorisera également pas à mettre des caractères non autorisés dans les en-têtes, mais si le serveur ne respecte pas cette règle, vous pouvez injecter des en-têtes arbitraires lorsque la communication est rétrogradée en HTTP/1.1.

Dans ce cas, l'en-tête Transfer-Encoding a été injecté.

H2.TE via Injection de Nom d'En-tête

HTTP/2 sur certains serveurs vous permet de mettre un deux-points dans le nom de l'en-tête, et avec un vous pouvez injecter un nouvel en-tête à l'intérieur du nom de l'en-tête comme ceci :

Notez que si vous mettez juste les caractères de nouvelle ligne en envoyant un en-tête sans contenu, la requête va être traitée comme non valide :

H2.TE via Injection de Ligne de Requête

Dans ce cas, l'injection a été réalisée à l'intérieur de la ligne de requête :

Injection de Préfixe d'URL

À l'intérieur du schéma de la connexion HTTP/2, vous pourriez être capable d'envoyer une URL complète qui écrasera celle indiquée dans le chemin :

Injection de Ligne de Requête via des espaces

Réutilisation de la connexion frontend->backend

Parfois, vous constaterez qu'en effectuant une attaque de Détournement de Requête HTTP, vous ne pouvez attaquer que vous-même. Cela pourrait être parce que le reverse proxy a décidé d'utiliser une connexion différente avec le serveur back-end par IP.

Notez que même avec cette restriction, vous pouvez toujours réaliser des attaques telles que des contournements d'autorisation, des fuites d'en-têtes internes et des attaques de tromperie de cache et d'empoisonnement de cache.

Habituellement, cette restriction n'existe pas, vous pouvez donc détourner des requêtes dans la connexion entre le reverse proxy et le back-end que d'autres personnes utilisent, mais il est même possible que le proxy ne réutilise même pas une connexion avec des connexions de la même IP (restriction assez lourde pour ce type d'attaque).

Dans la restriction la plus lourde (pas de réutilisation de connexion), vous détecterez la vulnérabilité avec la technique basée sur le temps, mais en la testant, vous constaterez qu'il s'agit d'un "faux positif".

Confirmation de Tunneling

Une manière de confirmer si le point de terminaison est vulnérable mais que la connexion est à l'intérieur d'un "tunnel" est de détourner 2 requêtes complètes en 1.

Le problème avec HTTP/1.1 est que si vous recevez 2 réponses HTTP, vous ne savez pas si le point de terminaison était vulnérable ou non et la requête "détournée" a juste été traitée comme une requête régulière.

Cependant, cette technique peut être utilisée en HTTP/2 car si le point de terminaison était vulnérable et que vous avez détourné une requête, vous verrez les en-têtes de la réponse à la requête détournée dans la réponse du reverse proxy :

Problème de Vision en Tunnel

Il pourrait y avoir un autre problème, si la réponse à la requête légitime contient un Content-Length, le reverse proxy ne va lire que les octets spécifiés là et pas plus, donc vous ne pourrez pas lire la réponse de la requête détournée.

Cependant, la requête HEAD ne contient pas de corps mais elle contient généralement le Content-Length comme si la requête était une requête GET. Par conséquent, en envoyant une requête HEAD au lieu d'une requête POST, vous pouvez lire les octets du Content-Length HEAD de la réponse à la requête détournée.

Fuite d'En-têtes Internes via Tunneling

Si vous trouvez un paramètre POST à l'intérieur de l'application dont le contenu va être reflété dans la réponse, alors vous pouvez essayer d'injecter des caractères HTTP/1.1 \r\n à l'intérieur d'un en-tête de requête HTTP/2 afin que les nouveaux en-têtes injectés par le proxy soient ajoutés dans le paramètre POST qui sera reflété dans la réponse :

Notez que dans ce cas, l'attaquant se soucie juste de la réponse à la première requête, il n'a pas besoin de lire la requête à la deuxième requête détournée invalide.

{% hint style="info" %} Utiliser cette attaque contre différentes parties du web (méthode, chemin...) peut conduire à l'utilisation de différents back-ends et à la fuite d'informations sensibles différentes {% endhint %}

Empoisonnement de Cache via Tunneling

Dans ce scénario, une requête HEAD vers l'URL dont le cache va être empoisonné est envoyée tout en détournant une requête dont le contenu de la réponse contiendra le payload (peut-être un payload XSS).

Du fait que la réponse HEAD contient le Content-Type: text/html et parce que le reverse proxy pense que toute la réponse à la requête détournée est le corps de la requête HEAD, le payload XSS va être traité comme du HTML même si la page n'était pas vulnérable au XSS.

HTTP/2 Caché

Habituellement, les serveurs annoncent le support via le champ ALPN dans la poignée de main TLS, mais certains ne le font pas.

Il peut être facilement détecté en utilisant curl --http2 --http2-prior-knowledge

Outils

Références

Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :