9.6 KiB
HTTP Response Smuggling / Desync
{{#include ../banners/hacktricks-training.md}}
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 exploite une vulnérabilité de HTTP Request Smuggling, donc vous devez savoir ce que c'est :
La principale différence entre cette technique et un HTTP Request smuggling classique 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 exploiter le 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 classique est que, dans une attaque de smuggling classique, 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 un payload 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 exploiter 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 exploitant le HTTP Request smuggling, puis la requête consommatrice de temps et ensuite 1 ou plusieurs requêtes payload 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 payloads connus 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 un payload contenant une requête POST finale avec le paramètre reflété à la fin et un grand 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 reflété :
Ensuite, la victime va recevoir la réponse à la requête lente et si entre-temps l'attaquant a envoyé une autre requête, la réponse de la requête de contenu reflété 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 le 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 :
Ensuite, 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 un 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 recevoir 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 XSS chez la victime sans que la page soit vulnérable à 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 le payload XSS :
Réponse malveillante à la victime qui contient l'en-tête indiquant au cache de stocker la réponse :
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.
Tromperie de cache web
Cette attaque est similaire à la précédente, mais au lieu d'injecter un payload 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 reflétées) :
Cependant, notez comment les données reflétées avaient une taille correspondant au 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.
{{#include ../banners/hacktricks-training.md}}