Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-response-smuggling-desync.md

12 KiB
Raw Blame History

HTTP Response Smuggling / Desync

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

Autres moyens de soutenir HackTricks :

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 qu'au lieu d'attaquer la requête de la victime en ajoutant un préfixe, nous allons fuir ou modifier la réponse que la victime reçoit. Cela se fait en envoyant 2 requêtes complètes pour désynchroniser la file d'attente des réponses des proxies.

Cela permet de 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 un contenu contrôlé par l'attaquant dans la réponse à la victime.

Désynchronisation de pipeline HTTP

HTTP/1.1 permet de demander différentes ressources sans avoir à attendre les précédentes. Par conséquent, s'il y a un proxy au milieu, c'est la tâche du proxy 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 pour désynchroniser 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 à la requête introduite sont immédiatement répondues, la réponse introduite ne sera pas insérée dans la file d'attente de la réponse de la victime mais sera simplement écartée comme une erreur.

Il est donc nécessaire que la requête introduite prenne plus de temps à être traitée à l'intérieur du serveur backend. Ainsi, lorsque la requête introduite 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 réponse à la requête introduite est donnée avant la requête légitime, la réponse introduite sera envoyée à la victime. Par conséquent, l'attaquant contrôlera 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 destinée à la victime (qui peut contenir par exemple l'en-tête Set-Cookie).

Injections multiples imbriquées

Une autre différence intéressante avec le HTTP Request Smuggling classique est que, dans une attaque de smuggling classique, l'objectif est de modifier le début de la requête de la victime pour 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 seule 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 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 introduit dans le serveur nécessite beaucoup de temps pour être traité.

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

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

Exploitation 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 d'envoyer du contenu pour qu'il soit reflété dans la réponse, aucun stockage persistant n'est nécessaire.

D'abord, l'attaquant envoie une charge utile contenant une requête POST finale avec le paramètre reflété à la fin et une grande Content-Length

Ensuite, une fois la requête initiale (bleue) traitée et pendant que celle endormie 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 recevra la réponse à la requête endormie et si entre-temps l'attaquant envoie une autre requête, la réponse du contenu reflété sera envoyée à lui.

Désynchronisation des réponses

Jusqu'à présent, nous avons appris à exploiter les attaques de HTTP Request Smuggling pour contrôler la requête dont la réponse va être reçue par un client 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 doivent (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 recevra la réponse de la requête HEAD, qui va contenir un Content-Length mais pas de contenu du tout. Par conséquent, le proxy n'enverra pas cette réponse à la victime, mais attendra un contenu, qui en réalité va être 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 être reçue par la victime et qu'une réponse HEAD contient habituellement 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 :

Empoisonnement du cache

En abusant de l'attaque de désynchronisation de réponse et de confusion de contenu 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 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 le "victime" est l'attaquant, il peut maintenant effectuer l'empoisonnement du 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 du 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 :

Séparation de réponse

L'objectif de cette attaque est d'abuser à nouveau de la désynchronisation des réponses afin de faire envoyer par le proxy 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 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 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 selon le 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 aussi faire en sorte que le proxy mette la réponse en cache.

Références

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

Autres moyens de soutenir HackTricks :