Un chercheur démontre 4 nouvelles variantes d’attaque de contrebande de requêtes HTTP

Une nouvelle recherche a identifié quatre nouvelles variantes d’attaques de contrebande de requêtes HTTP qui fonctionnent contre divers serveurs Web commerciaux et serveurs proxy HTTP.

Amit Klein, vice-président de la recherche sur la sécurité chez SafeBreach, qui a présenté les résultats aujourd’hui à la Chapeau noir conférence sur la sécurité, a déclaré que les attaques mettent en évidence la façon dont les serveurs Web et les serveurs proxy HTTP sont toujours sensibles à la contrebande de requêtes HTTP, même 15 ans après leur première documentation.

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

Contrebande de requêtes HTTP (ou HTTP Desyncing) est une technique utilisée pour interférer avec la façon dont un site Web traite les séquences de requêtes HTTP reçues d’un ou plusieurs utilisateurs.

Les vulnérabilités liées à la contrebande de requêtes HTTP surviennent généralement lorsque le front-end (un équilibreur de charge ou un proxy) et les serveurs back-end interprètent différemment la limite d’une requête HTTP, permettant ainsi à un mauvais acteur d’envoyer (ou de « trafiquer ») un message ambigu demande qui est ajoutée à la prochaine demande d’utilisateur légitime.

Cette désynchronisation des demandes peut être exploitée pour détourner les informations d’identification, injecter des réponses aux utilisateurs, et même voler des données à la demande d’une victime et exfiltrer les informations vers un serveur contrôlé par un attaquant.

La technique était d’abord démontré en 2005 par un groupe de chercheurs de Watchfire, dont Klein, Chaim Linhart, Ronen Heled et Steve Orrin. Mais au cours des cinq dernières années, un nombre d’améliorations ont été conçus, élargissant considérablement le surface d’attaque pour relier les demandes à d’autres et «obtenir un accès privilégié maximum aux API internes», empoisonner les caches Web et compromettre les pages de connexion des applications courantes.

Quoi de neuf?

Les nouvelles variantes décrites par Klein impliquent l’utilisation de diverses combinaisons proxy-serveur, notamment Abyss d’Aprelium, Microsoft IIS, Apache et Tomcat en mode serveur Web, et Nginx, Squid, HAProxy, Caddy et Traefik en mode proxy HTTP.

La liste des quatre nouvelles variantes est la suivante, y compris une ancienne que le chercheur a exploitée avec succès dans ses expériences.

• Variante 1: « En-tête SP / CR indésirable:… »
• Variante 2 – « Attendez-le »
• Variante 3 – HTTP / 1.2 pour contourner la défense de type mod_security
• Variante 4 – une solution simple
• Variante 5 – « En-tête CR »

Lors du traitement des requêtes HTTP contenant deux Content-Length Les champs d’en-tête, Abyss, par exemple, a accepté le deuxième en-tête comme valide, tandis que Squid a utilisé le premier en-tête Content-Length, amenant ainsi les deux serveurs à interpréter les demandes différemment et à réaliser la contrebande de demandes.

Dans les situations où Abyss reçoit une requête HTTP avec un corps dont la longueur est inférieure à la valeur Content-Length spécifiée, il attend 30 secondes pour répondre à la requête, mais pas avant d’ignorer le corps restant de la requête. Klein a constaté que cela entraîne également des divergences entre Squid et Abyss, ce dernier interprétant des parties de la requête HTTP sortante comme une seconde requête.

Une troisième variante de l’attaque utilise HTTP / 1.2 pour contourner les défenses WAF telles que définies dans OWASP ModSecurity Ensemble de règles de base (CRS) pour empêcher les attaques de contrebande de requêtes HTTP créent une charge utile malveillante qui déclenche le comportement.

Enfin, Klein a découvert que l’utilisation du champ d’en-tête « Content-Type: text / plain » était suffisante pour contourner contrôles de niveau de paranoïa 1 et 2 spécifié dans CRS et génère une vulnérabilité HTTP Request Smuggling.

Quelles sont les défenses possibles?

Une fois les résultats divulgués à Aprelium, Squid et OWASP CRS, les problèmes ont été résolus dans Abyss X1 v2.14, Versions Squid 4.12 et 5.0.3 et CRS v3.3.0.

Appelant à la normalisation des requêtes HTTP sortantes des serveurs proxy, Klein a souligné la nécessité d’une solution de pare-feu d’applications Web open source et robuste, capable de gérer les attaques de trafic de requêtes HTTP.

« ModSecurity (combiné avec CRS) est en effet un projet open source, mais en ce qui concerne la robustesse et la généricité, mod_security présente plusieurs inconvénients », a noté Klein. « Il ne fournit pas une protection complète contre la contrebande de requêtes HTTP [and] il n’est disponible que pour Apache, IIS et nginx. « 

À cette fin, Klein a publié une bibliothèque basée sur C ++ qui garantit que toutes les requêtes HTTP entrantes sont entièrement valides, conformes et sans ambiguïté en imposant un respect strict du format d’en-tête HTTP et du format de ligne de demande. Il est accessible depuis GitHub ici.