11 KiB
Smuggling / Désynchronisation des Réponses HTTP
Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en équipe rouge AWS de HackTricks)!
Autres façons de soutenir HackTricks :
- Si vous souhaitez voir votre entreprise annoncée dans HackTricks ou télécharger HackTricks en PDF, consultez les PLANS D'ABONNEMENT !
- Obtenez le swag officiel PEASS & HackTricks
- Découvrez La famille PEASS, notre collection exclusive de NFTs
- Rejoignez le 💬 groupe Discord ou le groupe Telegram ou suivez-nous sur Twitter 🐦 @carlospolopm.
- Partagez vos astuces de piratage en soumettant des PR aux HackTricks et HackTricks Cloud dépôts GitHub.
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 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 proxys.
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 un contenu contrôlé par l'attaquant dans la réponse à la victime.
Désynchronisation de la File d'Attente des Pipelines HTTP
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.
Il est donc nécessaire que la requête smugglée prenne plus de temps à être traitée dans le serveur backend. Par conséquent, 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).
Injections Multiples et Emboîtées
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 sur le serveur.
Organisation de l'Exploitation
Comme expliqué précédemment, pour exploiter cette technique, il est nécessaire que le premier message smugglé dans le serveur prenne beaucoup de temps à être traité.
Cette requête chronophage est suffisante si vous voulez simplement essayer de voler la réponse de la victime. Mais si vous voulez effectuer un exploit plus complexe, voici une structure commune pour l'exploit.
Tout d'abord, la requête initiale abusant du 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.
Abus de la Désynchronisation de la File d'Attente des Réponses HTTP
Capture des requêtes d'autres utilisateurs
Comme pour les charges utiles connues de Smuggling de Requêtes HTTP, 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 dernière requête POST 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 endormie 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 endormie 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.
Désynchronisation des Réponses
Jusqu'à présent, nous avons appris comment abuser des 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 longueur du contenu 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 longueur de contenu 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) :
Confusion de contenu
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 celle-ci pour causer une XSS chez la victime sans que la page soit vulnérable à la XSS :
Empoisonnement de cache
Abusant de l'attaque de confusion de contenu par désynchronisation de 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 injection 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 :
{% hint style="warning" %} Notez que dans ce cas si le "victim" est l'attaquant il peut maintenant effectuer l'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. {% 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 mettra en cache des informations de la victime à l'intérieur du cache :
Fractionnement de réponse
Le but de cette attaque est d'abuser à nouveau de la désynchronisation de réponse pour faire en sorte que le proxy envoie 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 suit :
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 d'attente :
La victime recevra en réponse le HEAD response + le contenu de la deuxième réponse de la requête (contenant une partie des données réfléchies) :
Cependant, notez comment les données réfléchies avaient une taille conforme au Content-Length de la réponse HEAD qui a généré une réponse HTTP valide dans la file de réponses.
Par conséquent, la prochaine requête du deuxième victime recevra 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.