HTTP Response Smuggling / Desync
Last updated
Last updated
La technique de ce post a été tirée de la vidéo : https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
Tout d'abord, cette technique exploite une vulnérabilité de Smuggling de Requêtes HTTP, donc vous devez savoir ce que c'est :
La principale différence entre cette technique et un Smuggling de Requêtes HTTP classique est que au lieu d'attaquer la requête de la victime en lui ajoutant un préfixe, nous allons dévoiler ou modifier la réponse que la victime reçoit. Cela se fait en envoyant non pas 1 requête et demie pour abuser du Smuggling de Requêtes HTTP, mais en envoyant 2 requêtes complètes pour désynchroniser la file des réponses des proxies.
Cela est dû au fait que nous allons être en mesure de désynchroniser la file 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.
HTTP/1.1 permet de demander différentes ressources sans attendre les précédentes. Par conséquent, s'il y a un proxy au milieu, c'est au proxy de maintenir une correspondance synchronisée des requêtes envoyées au backend et des réponses qui en proviennent.
Cependant, il y a un problème de désynchronisation de la file des réponses. Si un attaquant envoie une attaque de Smuggling de Réponses HTTP et que les réponses à la requête initiale et à celle smugglée sont répondues immédiatement, la réponse smugglée ne sera pas insérée dans la file de réponse de la victime mais sera simplement rejetée comme une erreur.
Par conséquent, il est nécessaire que la requête smugglée prenne plus de temps à être traitée à l'intérieur du serveur backend. Ainsi, au moment où la requête smugglée est traitée, la communication avec l'attaquant sera terminée.
Dans cette situation spécifique, si une victime a envoyé une requête et que la requête smugglée est répondue avant la requête légitime, la réponse smugglée 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 sera envoyée à l'attaquant, volant la réponse à la victime (qui peut contenir par exemple l'en-tête Set-Cookie).
Une autre différence intéressante avec le Smuggling de Requêtes HTTP classique est que, dans une attaque de Smuggling classique, le but est de modifier le début de la requête de la victime pour qu'elle effectue une action inattendue. Dans une attaque de Smuggling de Réponses HTTP, 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 les utilisateurs légitimes, cela pourrait également être utilisé pour provoquer un Déni de Service (DoS) sur le serveur.
Comme expliqué précédemment, pour exploiter cette technique, il est nécessaire que le premier message smugglé dans le serveur nécessite beaucoup de temps pour être traité.
Cette requête chronophage est suffisante si vous voulez simplement essayer de voler la réponse des victimes. Mais si vous voulez effectuer un exploit plus complexe, voici une structure commune pour l'exploit.
Tout d'abord, la requête initiale exploitant le Smuggling de Requêtes HTTP, puis la requête chronophage et ensuite 1 ou plusieurs requêtes de charge utile dont les réponses seront envoyées aux victimes.
Comme pour les charges utiles connues du Smuggling de Requêtes HTTP, vous pouvez voler la requête des victimes 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 dernière requête POST avec le paramètre reflété à la fin et une longue Content-Length
Ensuite, une fois que la requête initiale (bleue) a été traitée et pendant que la requête chronophage est en cours de traitement (jaune), la prochaine requête qui arrive d'une victime va être ajoutée dans la file juste après le paramètre reflété :
Ensuite, la victime va recevoir la réponse à la requête chronophage et si entre-temps l'attaquant envoie une autre requête, la réponse de la requête de contenu reflété lui sera envoyée.
Jusqu'à présent, nous avons appris comment exploiter les attaques de Smuggling de Requêtes HTTP pour contrôler la requête dont la réponse qu'un client va recevoir et comment vous pouvez ensuite voler la réponse qui était destinée à la victime.
Mais il est toujours 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 dans le 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 :
Ensuite, une fois que la requête bleue est répondue à l'attaquant, la prochaine requête de la victime va être introduite dans la file :
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 sera en fait la réponse à la requête jaune (également injectée par l'attaquant) :
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 la Content-Length, vous pouvez envoyer une requête comme celle-ci pour causer une XSS chez la victime sans que la page soit vulnérable à la XSS :
En exploitant l'attaque de Confusion de Contenu de désynchronisation de la réponse précédemment commentée, 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 une XSS, alors le cache est empoisonné.
Requête malveillante contenant la charge utile XSS :
Réponse malveillante à la victime contenant l'en-tête indiquant au cache de stocker la réponse :
Notez que dans ce cas, si le "victim" est l'attaquant, il peut maintenant effectuer un empoisonnement de cache dans des URL arbitraires car il peut contrôler l'URL qui va être mise en cache avec la réponse malveillante.
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 :
Le but de cette attaque est d'exploiter à nouveau la désynchronisation de la réponse afin de faire envoyer au proxy une réponse 100% générée par l'attaquant.
Pour y parvenir, l'attaquant doit trouver un point de terminaison de l'application web qui reflète certaines valeurs dans la réponse et connaître la longueur du 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 à la file :
La victime recevra en réponse le HEAD response + 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 conforme à la Content-Length de la réponse HEAD qui a généré une réponse HTTP valide dans la file de réponse.
Par conséquent, la prochaine requête du deuxième victime va recevoir en réponse quelque chose entièrement fabriqué par l'attaquant. Comme la réponse est entièrement fabriquée par l'attaquant, il peut également faire en sorte que le proxy mette en cache la réponse.
