Contrebande de requêtes HTTP - nouvelles approches

Le 7 octobre 2019, le directeur de la recherche de PortSwigger (producteur de BurpSuite) a publié une étude sur les nouvelles approches de la contrebande de requêtes HTTP. Avec leur aide, il a gagné environ 70 000 $ en bugbounty. Dans cet article, nous découvrons brièvement l'essence de l'attaque, des outils et également des méthodes de recherche de serveurs Web vulnérables à cette vulnérabilité.

Qu'est-ce que la contrebande de requêtes HTTP

Contrebande de requête HTTP - une attaque visant à désynchroniser le frontend du serveur web et le backend du serveur web, à la suite de quoi un attaquant pourrait faire passer clandestinement une requête HTTP devant le serveur frontend. L'image de l'article original sert de bonne démonstration:

Une telle attaque peut entraîner diverses conséquences - introduction de XSS dans la session d'autres utilisateurs, redirection des utilisateurs vers des ressources tierces, empoisonnement du cache du serveur, similitude avec SSRF et plusieurs autres.

Dans l'Incarnation de la contrebande 2019 de 2019, James Kettle a exploité un traitement d'en-tête de serveur Web incorrect

Transfer-Encoding: chunked 

indiquant que le corps du message sera transmis par parties ( RFC ). Étant donné que certains serveurs Web ne prennent pas en charge la transmission par blocs ou ne gèrent pas l'en-tête différemment, le frontend ne «verra» qu'une seule demande et le backend la reconnaîtra comme deux. Plus de détails sur les détails de l'attaque peuvent être trouvés dans l' article d'origine , il y a aussi une tâche pratique sur laquelle vous pouvez vous entraîner pour trouver la vulnérabilité manuellement.

Pour une recherche rapide, James a développé un plug-in pour BurpSuit, qui reçoit une demande d'entrée et crée une note sur la vulnérabilité du service (le cas échéant) à la sortie.

Exemples de serveurs Web vulnérables

Je dois dire que le problème de la contrebande et d'autres vulnérabilités liées au fonctionnement des serveurs Web a longtemps été traité par un autre chercheur sous le surnom de regilero . Au cours des trois dernières années, il a publié trois articles décrivant les vulnérabilités qu'il a trouvées dans les serveurs Web populaires, dont la plupart se voient attribuer des CVE de criticité moyenne et élevée. Parmi les serveurs vulnérables figurent Apache Traffic Server, Jetty, Apsis.

Dans le sillage de l'intérêt pour le problème, un autre chercheur, Nathan Davison, a découvert une vulnérabilité dans HAProxy, qui ignorait un en-tête incorrectement formé.

 Transfer-Encoding:[\x0b]chunked 

et l'a converti sous la forme suivante:

 Transfer-Encoding: chunked 

Mais le serveur principal - gunicorn, mandatant l'application sur Flask, a lu l'en-tête, ce qui a provoqué la vulnérabilité.

Un peu plus tard, un certain nombre d'autres chercheurs ont découvert une vulnérabilité (affectée CVE-2019-16276) dans la mise en œuvre du serveur http golang - le serveur normalisait l'en-tête s'il y avait un espace avant le prélude.
Demande:

Après traitement par le serveur:

La vulnérabilité pourrait être exploitée si le serveur frontal ignorait l'en-tête avec un espace et utilisait Content-Length pour calculer la taille de la demande.

Le serveur Web Caddy écrit en Go était également vulnérable car il utilisait la même bibliothèque net / http. Les développeurs ont confirmé qu'après la mise à jour de GO et la reconstruction du package, le problème disparaît.

L'auteur de cet article a trouvé un problème similaire sur le serveur lighthttpd (aucun CVE n'a été attribué). La capture d'écran montre que le serveur accepte et traite l'en-tête contenant un espace:

Les développeurs ne sont pas tout à fait d'accord avec la RFC 7230 (et l'auteur aussi) et pensent que la responsabilité du traitement incorrect des en-têtes incombe aux mandataires qui transmettent les demandes sans les normaliser et les vérifier. Cependant, le bug sera corrigé dans la nouvelle version:

Par défaut, lighttpd analyse (et normalise) les requêtes avant de les renvoyer par proxy aux backends. Cela contrecarre les attaques mentionnées dans https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn aux serveurs en amont de lighttpd.
Cependant, comme mentionné par stbuehler ci-dessus, les proxys en aval de lighttpd peuvent transmettre n'importe quoi à lighttpd.
La modification qui sera apportée dans la prochaine version de lighttpd consistera à rejeter les demandes avec espace ou tabulation après le nom du champ et avant les deux-points, mais uniquement lorsque lighttpd est configuré en mode (par défaut) de l'analyse stricte de l'en-tête http.

Le même bogue a été trouvé sur le serveur Web cheroot utilisé par le framework cherrypy. Ce mini-framework se retrouve dans les startups, il est souvent utilisé pour écrire des API. Le rapport de bogue se bloque dans l'état ouvert.

Conditions nécessaires et suffisantes pour la vulnérabilité

Quelles sont donc les conditions nécessaires pour vérifier et exploiter la vulnérabilité:

• Demande POST. Bien que la RFC n'interdise pas explicitement l'utilisation des en-têtes Content-Length et Transfer-Encoding pour les requêtes GET, en fait, ils ne sont utilisés que dans les requêtes POST.
• La présence de serveurs frontaux et principaux - s'il n'y en a pas, il n'y aura rien à synchroniser.
• Les serveurs Web doivent analyser différemment l'en-tête Transfer-Encoding, c'est-à-dire qu'il faut le "lire" et le second doit être ignoré.

Essais en laboratoire

Pour une meilleure compréhension et dépannage des serveurs Web et des proxys existants, il est judicieux de déployer un environnement de test localement à l'aide de Docker.

Un exemple de diagramme d'environnement de test:

Code d'application:

 from flask import Flask, request, jsonify app = Flask(__name__) @app.route('/', methods=['GET', 'POST']) def main(): # the next line is required for Transfer-Encoding support in the request request.environ['wsgi.input_terminated'] = True headers = {} for header in request.headers: headers[header[0]] = header[1] print (request.data) print (headers) return jsonify(body=str(request.data), headers=headers) 

Fichier avec les paramètres frontaux, par exemple, caddy:

 localhost:80 log ../access.log proxy / host.docker.internal:8888 

Alors tout est simple, lancez l'application:

 gunicorn --keep-alive 10 -k gevent --bind 0.0.0.0:8888 -w 4 backend:app 

Et conteneur:

 docker run -d -t --name caddy -p 80:80 -p 443:443 -v /Users/sun/work/caddyfile:/etc/Caddyfile abiosoft/caddy:latest 

À partir du magasin Burp, nous installons HTTP Request Smuggler et Logger ++ pour faciliter le débogage. Ensuite, dans Repeater, nous formons une demande simple, par exemple ceci:

 POST / HTTP/1.1 Host: localhost Content-Length: 8 Connection: close body=123 

Et envoyez-le pour vérifier que tout est correctement configuré:

 HTTP/1.1 200 OK Content-Length: 202 Content-Type: application/json Date: Mon, 07 Oct 2019 13:17:18 GMT Server: Caddy Server: gunicorn/19.9.0 Connection: close {"body":"b'body=123'","headers":{"Accept-Encoding":"gzip","Connection":"close","Content-Length":"8","Host":"host.docker.internal:8888","User-Agent":"Go-http-client/1.1","X-Forwarded-For":"172.17.0.1"}} 

Lancez maintenant Launch Smuggle Probe et regardez les réponses.

Le plus intéressant commence à ce moment. Il est nécessaire d'analyser les demandes et les réponses pour comprendre si les services sont vulnérables ou non. Cette partie est laissée au lecteur curieux.