hacktricks/pentesting-web/http-response-smuggling-desync.md

HTTP Response Smuggling / Desync

{% hint style="success" %} Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Consultez les plans d'abonnement !
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des astuces de hacking en soumettant des PR aux HackTricks et HackTricks Cloud dépôts github.

{% endhint %}

La technique de ce post a été tirée de la vidéo : https://www.youtube.com/watch?v=suxDcYViwao&t=1343s

Désynchronisation de la file d'attente des requêtes HTTP

Tout d'abord, cette technique abuse d'une vulnérabilité de HTTP Request Smuggling, donc vous devez savoir ce que c'est :

La principale différence entre cette technique et un smuggling HTTP Request commun est que au lieu de cibler la requête de la victime en ajoutant un préfixe, nous allons fuiter ou modifier la réponse que la victime reçoit. Cela se fait en, au lieu d'envoyer 1 requête et demie pour abuser du HTTP Request smuggling, envoyer 2 requêtes complètes pour désynchroniser la file d'attente des réponses des proxies.

C'est parce que nous allons pouvoir désynchroniser la file d'attente des réponses afin que la réponse de la requête légitime de la victime soit envoyée à l'attaquant, ou en injectant du contenu contrôlé par l'attaquant dans la réponse à la victime.

Désynchronisation du pipeline HTTP

HTTP/1.1 permet de demander des ressources différentes sans avoir besoin d'attendre les précédentes. Par conséquent, s'il y a un proxy au milieu, c'est la tâche des proxies de maintenir une correspondance synchronisée des requêtes envoyées au backend et des réponses provenant de celui-ci.

Cependant, il y a un problème de désynchronisation de la file d'attente des réponses. Si un attaquant envoie une attaque de HTTP Response smuggling et que les réponses à la requête initiale et à celle smuggled sont répondues immédiatement, la réponse smuggled ne sera pas insérée dans la file d'attente de la réponse de la victime mais sera juste rejetée comme une erreur.

Par conséquent, il est nécessaire que la requête smuggled prenne plus de temps à être traitée à l'intérieur du serveur backend. Ainsi, au moment où la requête smuggled est traitée, la communication avec l'attaquant sera terminée.

Si dans cette situation spécifique une victime a envoyé une requête et que la requête smuggled est répondue avant la requête légitime, la réponse smuggled sera envoyée à la victime. Par conséquent, l'attaquant va contrôler la requête "effectuée" par la victime.

De plus, si l'attaquant effectue ensuite une requête et que la réponse légitime à la requête de la victime est répondue avant la requête de l'attaquant. La réponse à la victime va être envoyée à l'attaquant, volant la réponse à la victime (qui peut contenir par exemple l'en-tête Set-Cookie).

Injections imbriquées multiples

Une autre différence intéressante avec le HTTP Request Smuggling commun est que, dans une attaque de smuggling commune, le but est de modifier le début de la requête de la victime afin qu'elle effectue une action inattendue. Dans une attaque de HTTP Response smuggling, comme vous envoyez des requêtes complètes, vous pouvez injecter dans une charge utile des dizaines de réponses qui vont désynchroniser des dizaines d'utilisateurs qui vont recevoir les réponses injectées.

En plus de pouvoir distribuer plus facilement des dizaines d'exploits parmi des utilisateurs légitimes, cela pourrait également être utilisé pour provoquer un DoS sur le serveur.

Organisation de l'exploit

Comme expliqué précédemment, pour abuser de cette technique, il est nécessaire que le premier message smuggled dans le serveur prenne beaucoup de temps à être traité.

Cette requête consommatrice de temps est suffisante si nous voulons juste essayer de voler la réponse de la victime. Mais si vous voulez effectuer un exploit plus complexe, cela sera une structure commune pour l'exploit.

Tout d'abord la requête initiale abusant du HTTP Request smuggling, puis la requête consommatrice de temps et ensuite 1 ou plusieurs requêtes de charge utile dont les réponses seront envoyées aux victimes.

Abus de la désynchronisation de la file d'attente des réponses HTTP

Capturer les requêtes d'autres utilisateurs

Comme avec les charges utiles connues de HTTP Request Smuggling, vous pouvez voler la requête de la victime avec une différence importante : Dans ce cas, vous avez juste besoin que le contenu envoyé soit reflété dans la réponse, aucun stockage persistant n'est nécessaire.

Tout d'abord, l'attaquant envoie une charge utile contenant une requête POST finale avec le paramètre réfléchi à la fin et une grande Content-Length.

Ensuite, une fois que la requête initiale (bleue) a été traitée et pendant que la requête lente est en cours de traitement (jaune), la prochaine requête qui arrive d'une victime va être ajoutée dans la file d'attente juste après le paramètre réfléchi :

Ensuite, la victime va recevoir la réponse à la requête lente et si entre-temps l'attaquant envoie une autre requête, la réponse de la requête de contenu réfléchi sera envoyée à lui.

Désynchronisation de la réponse

Jusqu'à présent, nous avons appris comment abuser des attaques de HTTP Request Smuggling pour contrôler la requête dont la réponse un client va recevoir et comment vous pouvez ensuite voler la réponse qui était destinée à la victime.

Mais il est encore possible de désynchroniser encore plus les réponses.

Il existe des requêtes intéressantes comme la requête HEAD qui sont spécifiées pour ne pas avoir de contenu à l'intérieur du corps des réponses et qui devraient (doivent) contenir la Content-Length de la requête comme si c'était une requête GET.

Par conséquent, si un attaquant injecte une requête HEAD, comme dans ces images :

Alors, une fois que la bleue est répondue à l'attaquant, la prochaine requête de la victime va être introduite dans la file d'attente :

Ensuite, la victime va recevoir la réponse de la requête HEAD, qui va contenir une Content-Length mais aucun contenu du tout. Par conséquent, le proxy ne va pas envoyer cette réponse à la victime, mais va attendre un contenu, qui en réalité va être la réponse à la requête jaune (également injectée par l'attaquant) :

Confusion de contenu

En suivant l'exemple précédent, sachant que vous pouvez contrôler le corps de la requête dont la réponse va être reçue par la victime et qu'une réponse HEAD **contient généralement dans ses en-têtes le Content-Type et le Content-Length, vous pouvez envoyer une requête comme la suivante pour provoquer un XSS chez la victime sans que la page soit vulnérable au XSS :

Poisoning de cache

En abusant de l'attaque de désynchronisation de réponse commentée précédemment, si le cache stocke la réponse à la requête effectuée par la victime et que cette réponse est une réponse injectée provoquant un XSS, alors le cache est empoisonné.

Requête malveillante contenant la charge utile XSS :

Réponse malveillante à la victime qui contient l'en-tête indiquant au cache de stocker la réponse :

{% hint style="warning" %} Notez que dans ce cas, si la "victime" est l'attaquant, il peut maintenant effectuer un empoisonnement de cache sur des URL arbitraires car il peut contrôler l'URL qui va être mise en cache avec la réponse malveillante. {% endhint %}

Tromperie de cache web

Cette attaque est similaire à la précédente, mais au lieu d'injecter une charge utile dans le cache, l'attaquant va mettre en cache des informations de la victime à l'intérieur du cache :

Division de réponse

Le but de cette attaque est d'abuser à nouveau de la désynchronisation de la réponse afin de faire en sorte que le proxy envoie une réponse générée à 100 % par l'attaquant.

Pour y parvenir, l'attaquant doit trouver un point de terminaison de l'application web qui reflète certaines valeurs à l'intérieur de la réponse et connaître la longueur de contenu de la réponse HEAD.

Il enverra un exploit comme :

Après que la première requête soit résolue et renvoyée à l'attaquant, la requête de la victime est ajoutée dans la file d'attente :

La victime recevra comme réponse la réponse HEAD + le contenu de la réponse de la deuxième requête (contenant une partie des données réfléchies) :

Cependant, notez comment les données réfléchies avaient une taille selon la Content-Length de la réponse HEAD qui a généré une réponse HTTP valide dans la file d'attente des réponses.

Par conséquent, la prochaine requête de la deuxième victime va recevoir comme réponse quelque chose complètement fabriqué par l'attaquant. Comme la réponse est complètement fabriquée par l'attaquant, il peut également faire en sorte que le proxy mette en cache la réponse.

{% hint style="success" %} Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Consultez les plans d'abonnement !
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des astuces de hacking en soumettant des PR aux HackTricks et HackTricks Cloud dépôts github.

{% endhint %}