Les systèmes Web où le frontend accepte les connexions via HTTP / 2 et les transmet au backend via HTTP / 1.1 hont été exposés à une nouvelle version de l'attaque "HTTP Request Smuggling", Il permet en envoyant des requêtes client spécialement conçues, de répartir le contenu des requêtes des autres utilisateurs traitées dans le même flux entre le frontend et le backend.
L'attaque peut être utilisé pour injecter du code JavaScript malveillant dans une session avec un site légitime, contourner les systèmes de restriction d'accès et intercepter les paramètres d'authentification.
L'auteur de l'étude a démontré la possibilité d'attaquer les systèmes Netflix, Verizon, Bitbucket, Netlify CDN et Atlassian, et a reçu 56.000 5 $ en programmes de récompense pour l'identification des vulnérabilités. Le problème a également été confirmé dans les produits FXNUMX Networks.
Le problème affecte partiellement mod_proxy sur le serveur http Apache (CVE-2021-33193), correctifs attendus dans la version 2.4.49 (les développeurs ont été notifiés du problème début mai et ont reçu 3 mois pour le résoudre). Dans nginx, la possibilité de spécifier simultanément les en-têtes "Content-Length" et "Transfer-Encoding" était bloquée dans la version précédente (1.21.1).
Le principe de fonctionnement de la nouvelle méthode de requêtes correspondantes dans le trafic est similaire à la vulnérabilité découverte par le même chercheur il y a deux ans, mais il est limité aux interfaces qui acceptent les requêtes via HTTP / 1.1.
L'attaque classique "HTTP Request Smuggling" était basée sur le fait que les frontends et les backends interprètent différemment l'utilisation des en-têtes HTTP "Content-Length" (détermine la taille totale des données dans la requête) et "Transfer-Encoding: chunked" ( vous permet de transférer des données par morceaux) ...
Par exemple, si l'interface ne supporte que "Content-Length" mais ignore "Transfer-Encoding: fragmented", un attaquant peut envoyer une requête qui contient les en-têtes "Content-Length" et "Transfer-Encoding: fragmented", mais la taille fr La "Longueur du contenu" ne correspond pas à la taille de la chaîne fragmentée. Dans ce cas, le frontend traitera et redirigera la demande en fonction de la "Longueur du contenu", et le backend attendra la fin du bloc en fonction du "Transfer encoding: chunked".
Contrairement au protocole textuel HTTP/1.1, qui est analysé au niveau de la ligne, HTTP/2 est un protocole binaire et manipule des blocs données d'une taille prédéterminée. Cependant, HTTP/2 utiliser des pseudo-en-têtes qui correspondent aux en-têtes HTTP normaux. Lors de l'interaction avec le backend en utilisant le protocole HTTP/1.1, le frontend traduit ces pseudo-en-têtes dans des en-têtes HTTP / 1.1 HTTP similaires. Le problème est que le backend prend des décisions sur l'analyse de la transmission basé sur les en-têtes HTTP définis par le frontend, sans connaître les paramètres de la demande initiale.
Même sous forme de pseudo-en-têtes, les valeurs "Content-length" et "transfer-encoding" ils peuvent être diffusés en continu, bien qu'ils ne soient pas utilisés dans HTTP / 2, car la taille de toutes les données est déterminée dans un champ séparé. Cependant, lors de la conversion d'une requête HTTP/2 en HTTP/1.1, ces en-têtes sont transmis et peuvent être déroutants pour le backend.
Il existe deux options d'attaque principales : H2.TE et H2.CL, dans lequel le backend est trompé par un encodage de transfert incorrect ou une valeur de longueur de contenu qui ne correspond pas à la taille réelle du corps de la requête reçue par le frontend via le protocole HTTP/2.
À titre d'exemple de l'attaque H2.CL, une taille incorrecte est spécifiée dans le pseudo-en-tête longueur du contenu lors de la soumission d'une demande HTTP/2 vers Netflix. Cette demande entraîne l'ajout d'un en-tête Longueur du contenu HTTP similaire lors de l'accès au backend via HTTP / 1.1, mais puisque la taille dans Content-Length est inférieur à la valeur réelle, une partie des données de la file d'attente est traitée comme le début de la requête suivante.
Les outils d'attaque ont déjà été ajoutés à la boîte à outils de Burp et sont disponibles en tant qu'extension Turbo Intruder. Les proxys Web, les équilibreurs de charge, les accélérateurs Web, les systèmes de diffusion de contenu et d'autres configurations où les demandes sont redirigées dans un schéma frontend-backend sont sensibles au problème.
source: https://portswigger.net