Une attaque sur les systèmes frontend-backend, permettant de s'immiscer dans des requêtes tierces

Dévoilé détails de la nouvelle attaque sur les sites utilisant le modèle frontend-backend, par exemple, ceux fonctionnant via des réseaux de diffusion de contenu, des équilibreurs de charge ou des proxy. L'attaque permet, en envoyant des requêtes spécifiques, d'interférer dans le contenu d'autres requêtes traitées dans le même flux entre le frontend et le backend. La méthode proposée a été appliquée avec succès pour mener une attaque permettant d'intercepter les paramètres d'authentification des utilisateurs du service PayPal, qui a versé environ 40 000 dollars aux chercheurs dans le cadre d'un programme de signalement de vulnérabilités non corrigées. L'attaque est également applicable aux sites utilisant le réseau de diffusion de contenu Akamai.

La essence du problème est que les frontends et backends offrent souvent différents niveaux de support pour le protocole HTTP, tout en encapsulant les requêtes de différents utilisateurs dans un canal commun. Une connexion TCP persistante est établie entre le frontend, qui reçoit les requêtes, et le backend, qui les traite, à travers laquelle les requêtes des utilisateurs sont transmises en chaîne, les unes après les autres, avec séparation par les moyens du protocole HTTP. Pour séparer les requêtes, les en-têtes « Content-Length » (déterminant la taille totale des données dans la requête) et «Transfer-Encoding: chunked» (permettant de transmettre des données par morceaux, en spécifiant des blocs de tailles différentes au format «{taille}\r\n{bloc}\r\n{taille}\r\n{bloc}\r\n0»).

Le problème survient si le frontend ne prend en charge que « Content-Length », mais ignore « Transfer-Encoding: chunked » (par exemple, c'était le cas du CDN Akamai) ou vice versa. En cas de prise en charge de « Transfer-Encoding: chunked » des deux côtés, les particularités de l'implémentation des analyseurs d'en-tête HTTP peuvent être utilisées pour l'attaque (par exemple, lorsque le frontend ignore des lignes telles que « Transfer-Encoding: xchunked », « Transfer-Encoding: chunked », « Transfer-Encoding:[tab]chunked », « X: X[\n]Transfer-Encoding: chunked », « Transfer-Encoding[\n]: chunked » ou « Transfer-Encoding : chunked », tandis que le backend les traite avec succès).

Dans ce cas, un attaquant peut envoyer une requête contenant simultanément les en-têtes « Content-Length » et « Transfer-Encoding: chunked », mais la taille dans « Content-Length » ne correspond pas à la taille de la chaîne chunked, qui est inférieure à la valeur réelle. Si le frontend traite et redirige la requête en fonction de « Content-Length », mais que le backend attend la fin du bloc en fonction de « Transfer-Encoding: chunked », alors la fin des données basée sur « Transfer-Encoding: chunked » sera déterminée plus tôt, et le reste de la requête de l'attaquant se retrouvera au début de la requête suivante, c'est-à-dire que l'attaquant aura la possibilité d'attacher des données arbitraires au début de la requête d'un tiers transmise ensuite.

Pour identifier le problème dans la chaîne frontend-backend utilisée, vous pouvez envoyer une requête de type :

POST /about HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 4

1
Z
Q

Le problème est présent si le backend ne traite pas immédiatement la requête et attend l'arrivée du bloc de terminaison nul final des données chunked. Pour un contrôle plus complet préparée un utilitaire spécial qui teste également les méthodes possibles pour masquer l'en-tête « Transfer-Encoding: chunked » du frontend.

La conduite d'une attaque réelle dépend des capacités du site attaqué, par exemple, lors d'une attaque sur l'application web Trello, il est possible de remplacer le début de la requête (insérer des données telles que « PUT /1/members/1234… x=x&csrf=1234&username=testzzz&bio=cake ») et d'envoyer un message contenant la requête originale d'un utilisateur tiers et les Cookies d'authentification associés. Pour l'attaque sur saas-app.com, il a été possible d'injecter du code JavaScript dans la réponse, à travers son insertion dans un des paramètres de la requête. Pour l'attaque sur redhat.com, un gestionnaire interne a été utilisé pour rediriger vers le site de l'attaquant (une requête de type « POST /search?dest=..\/assets\/idx?redir=\/\/redhat.com@evil.net\/ HTTP/1.1 » a été insérée).

L'utilisation de la méthode pour les réseaux de livraison de contenu permettait de simplement intercepter le site demandé en substituant l'en-tête « Host: ». L'attaque est également applicable pour organiser la contamination des systèmes de mise en cache de contenu et extraire des données sensibles mises en cache. Le point culminant de cette méthode a été l'organisation d'une attaque contre PayPal, permettant d'intercepter les mots de passe envoyés par les utilisateurs lors de l'authentification (la requête iframe a été modifiée pour exécuter JavaScript dans le contexte de la page paypal.com/us/gifts, pour laquelle la CSP (Content Security Policy) n'était pas appliquée).

Fait intéressant, en 2005, il y avait proposée une technique de substitution de requêtes similaire, permettant de modifier les données dans des proxies de mise en cache (Tomcat, squid, mod_proxy) ou de contourner les bloqueurs de pare-feu en passant plusieurs requêtes « GET » ou « POST » dans un même session HTTP.

Source : opennet.ru