Vulnérabilité dans le protocole HTTP/2, exploitée lors de la plus grande attaque DDoS

Google a enregistré la plus grande attaque DDoS sur son infrastructure, avec une intensité atteignant 398 millions de requêtes par seconde. Cette nouvelle attaque est sept fois plus intense que l'ancienne attaque DDoS record, où les attaquants avaient réussi à générer un flux de 47 millions de requêtes par seconde. En comparaison, tout le trafic du Web est estimé entre 1 et 3 milliards de requêtes par seconde. En plus de Google, les entreprises Amazon et Cloudflare ont également été confrontées à cette attaque. La possibilité de cette nouvelle attaque est liée à la découverte d'une vulnérabilité dans le protocole HTTP/2 (CVE-2023-44487), permettant d'envoyer un immense flux de requêtes au serveur avec une charge minimale du client.

La nouvelle technique d'attaque est appelée « Rapid Reset » et exploite le fait que les mécanismes de multiplexage de canaux fournis dans HTTP/2 permettent de créer un flux de requêtes dans le cadre d'une connexion déjà établie, sans ouvrir de nouvelles connexions réseau et sans attendre la confirmation de la réception des paquets. La vulnérabilité est considérée comme une conséquence d'une lacune dans le protocole HTTP/2, dont la spécification stipule qu'en cas de tentative d'ouverture d'un nombre trop important de flux, il convient d'annuler uniquement les flux dépassant la limite, mais pas de fermer entièrement la connexion réseau.

À l'instar des méthodes d'attaques précédemment utilisées sur HTTP/2, la nouvelle attaque crée également un grand nombre de flux dans le cadre d'une seule connexion. La principale différence avec la nouvelle attaque est que, au lieu d'attendre une réponse après chaque requête envoyée, une trame avec le drapeau RST_STREAM est immédiatement envoyée, annulant la requête. L'annulation de la requête à un stade précoce permet d'éliminer le trafic retour vers le client et de contourner les limites existantes sur les serveurs HTTP concernant le nombre maximum de flux simultanément ouverts dans le cadre d'une seule connexion HTTP/2. Ainsi, dans la nouvelle attaque, le volume de requêtes envoyées au serveur HTTP ne dépend plus des délais entre l'envoi de la requête et la réception de la réponse (RTT, round-trip time) et est limité uniquement par la bande passante de la connexion.

Étant donné que pour mener une attaque côté client, il suffit d'envoyer des requêtes sans recevoir de réponses, l'attaque peut être réalisée avec des coûts opérationnels minimaux. Par exemple, une attaque enregistrée par Cloudflare à 201 millions de requêtes par seconde a été effectuée à l'aide d'un botnet relativement petit de 20 000 ordinateurs. Du côté de serveurs les coûts de traitement des requêtes entrantes sont considérablement plus élevés, malgré leur annulation, car il est nécessaire d'effectuer des opérations telles que la création de structures de données pour de nouveaux flux, l'analyse de la requête, le déballage de l'en-tête et la correspondance de l'URL avec la ressource. Lors d'une attaque sur des proxies inverses, l'attaque peut se propager aux backends, car le proxy peut rediriger la requête vers le backend avant le traitement du cadre RST_STREAM.

Une attaque ne peut être réalisée que sur des serveurs vulnérables prenant en charge HTTP/2 (script pour vérifier la manifestation de la vulnérabilité sur les serveurs, trousse à outils pour mener l'attaque). Aucune attaque n'a encore été enregistrée pour HTTP/3 et la possibilité de leur réalisation n'a pas encore été complètement analysée, mais des représentants de Google recommandent aux développeurs serveurs d'ajouter dans les implémentations d'HTTP/3 des mesures de protection similaires à celles mises en place pour bloquer les attaques sur HTTP/2.

Vulnérabilité et disponibilité des correctifs pour les serveurs HTTP et les proxies :

• nginx (annonce, explication que la vulnérabilité ne se manifeste pas pleinement dans nginx en configuration par défaut, car l'attaque se heurtera à une limite sur le nombre de requêtes par connexion (c'est-à-dire qu'après chaque 1000 requêtes, la connexion sera réinitialisée). Dans le correctif, une protection supplémentaire a été ajoutée pour limiter l'intensité des requêtes via la directive « limit_req »).
• Dans HAProxy, une protection efficace contre le dépassement de la limite du nombre de flux HTTP/2 a été ajoutée en 2018 et est en vigueur depuis la version 1.9-dev.
• Apache httpd (charge spécifique créée sur httpd, mais elle ne se propage pas aux backends et est limitée par des limites en vigueur depuis 2016 sur les connexions des clients).
• mod_h2 pour Apache httpd.
• caddy
• envoy
• golang (problème résolu dans les versions Go 1.21.3 et 1.20.10).
• h2o (patch).
• grpc-go
• hyper (la vulnérabilité ne se manifeste pas).
• jetty (corrigé dans 12.0.2, 11.0.17, 10.0.17 et 9.4.53.v20231009).
• netty
• nghttp2 (corrigé dans la version 1.57.0).
• Facebook proxygen
• .NET et ASP.NET Core (le serveur HTTP ASP.NET Core Kestrel est vulnérable).
• Node.js
• proxygen
• swift-nio-http2 (corrigé dans la version 1.28.0).
• Apache Tomcat (corrigé dans les versions 11.0.0-M12, 10.1.14, 9.0.81, 8.5.94).
• Apache Traffic Server (corrigé dans la branche 9.2.x).

Source : opennet.ru