Au cours des deux derniers mois, des attaquants ont abusé d'une fonctionnalité du protocole de communication web HTTP/2 qui rend les serveurs d'applications web, les équilibreurs de charge et les proxys web vulnérables à des attaques par déni de service distribué (DDoS) d'une ampleur sans précédent. Google, AWS, Cloudflare et d'autres acteurs IT, ont travaillé sur des stratégies d'atténuation et des correctifs en privé avant de divulguer la faille.

Les attaques DDoS, baptisées HTTP/2 Rapid Reset, tirent parti de la capacité de multiplexage de flux du protocole HTTP/2. Il est capable d'envoyer plusieurs requêtes HTTP en parallèle sur la même connexion de transport TCP. Une fonction est en particulier ciblée, la réinitialisation unilatérale des flux. Les entreprises sont invitées à vérifier si leurs partenaires IT disposent de correctifs ou de recommandations d'atténuation pour cette faille répertoriée sous la référence CVE-2023-44487.

Des attaques DDoS plus efficaces

Dans l'ancienne version 1 du protocole HTTP, toujours prise en charge par la plupart des serveurs et des clients web, il est possible d’envoyer plusieurs requêtes sur une seule connexion TCP, mais cet envoi se fait en série et le serveur traite les requêtes et y répond dans l'ordre dans lequel elles ont été reçues. Dans le cas du HTTP/2, plusieurs requêtes appelées « flux » ou « streams » et composées de trames de type HEADERS ou DATA, peuvent être envoyées simultanément et dans le désordre sur une connexion TCP. En effet, dans le multiplexage de flux, chaque stream est associé à un identifiant, de sorte que le serveur sait toujours de quel flux fait partie la trame et comment y répondre.

Ce multiplexage offre une utilisation plus efficace des connexions TCP et accélère le temps de chargement des pages. Imaginons une page web moderne contenant une multitude de ressources, de scripts tiers et d'images chargées à partir de différents emplacements. Un navigateur accédant à une telle page via HTTP/2 commencera immédiatement à charger ces ressources en parallèle, en donnant la priorité à celles qui sont visibles par l'utilisateur. Si celui-ci clique immédiatement sur un bouton et quitte la page, le navigateur peut fermer les flux même si les ressources n'ont pas été entièrement chargées ou rendues sans fermer entièrement la connexion et ouvrir d’autres requêtes. « Depuis la fin 2021, la majorité des attaques DDoS de couche Layer 7 que nous avons observées sur les services de Google et les projets Google Cloud protégés par Cloud Armor sont basées sur le HTTP/2, à la fois en nombre d'attaques et en taux de requêtes maximales », ont déclaré les ingénieurs de Google dans un billet de blog expliquant la nouvelle attaque. « L'un des principaux objectifs du HTTP/2 était l'efficacité, et malheureusement, les fonctionnalités qui rendent le HTTP/2 plus efficace pour les clients légitimes peuvent également être utilisées pour rendre les attaques DDoS plus efficaces », ont ajouté les chercheurs.

Contournement des limites de flux simultanés

Étant donné qu'un serveur doit consommer des cycles de CPU et de la mémoire pour traiter chaque trame et chaque flux, les développeurs du protocole avaient conscience dès le départ qu’il serait possible d'abuser des flux simultanés pour épuiser les ressources d'un serveur, et donc de provoquer un déni de service. C'est pourquoi ils ont ajouté un paramètre appelé SETTINGS_MAX_CONCURRENT_STREAMS que le serveur communique aux clients des points terminaux lors de la première connexion via une trame SETTINGS. Par défaut, la valeur de ce paramètre est illimitée, mais les concepteurs du protocole recommandent qu'elle ne soit pas inférieure à 100 pour maintenir un parallélisme efficace. C'est pourquoi, dans la pratique, de nombreux clients n'attendent pas la trame SETTINGS et supposent simplement que la limite minimale est de 100 et envoient 100 trames dès le début. Le problème vient d'une autre fonctionnalité appelée RST_STREAM, qui signifie « reset stream » (réinitialisation du flux). Il s'agit d'un type de trame qu'un client peut envoyer à un serveur pour indiquer qu'un ID de flux précédemment ouvert doit être annulé.

Cela permet au client d'annuler les demandes de ressources à la volée qui ne sont plus nécessaires, parce que l'utilisateur a, par exemple, quitté la page avant que la ressource ne soit chargée. Elle est utile, car elle indique au serveur d'arrêter de répondre à une requête précédente et de ne pas gaspiller la bande passante. Mais il y a un hic. En envoyant une trame RST_STREAM, le flux ciblé n'est plus pris en compte dans la limite maximale de flux simultanés, de sorte que le client peut immédiatement ouvrir un nouveau flux après avoir envoyé une réinitialisation pour un flux précédent. Cela signifie que même avec une limite de 100 flux simultanés, le client peut ouvrir et réinitialiser des centaines de flux sur la même connexion TCP coup sur coup. Si bien que le serveur doit encore dépenser des ressources pour traiter les trames RST_STREAM. Même si ce n'est pas beaucoup, avec des millions de requêtes, cela s'accumule rapidement.

Des attaques DDoS plus puissantes

Grâce à cette technique, des attaquants ont réussi à lancer des attaques DDoS d'une ampleur sans précédent contre des serveurs hébergés par Google, Cloudflare et AWS. « Quand un serveur HTTP/2 est capable de traiter les trames RST_STREAM envoyées par les clients et de démanteler l'état assez rapidement, ces réinitialisations rapides ne posent pas de problème », ont expliqué les ingénieurs de Cloudflare dans leur rapport. « Les problèmes commencent à se poser en cas de retard ou de décalage dans le traitement. Le client peut envoyer tellement de requêtes qu'un arriéré de travail s'accumule, entraînant une consommation excessive des ressources sur le serveur ».

L'attaque HTTP/2 Rapid Reset la plus importante observée par Google a culminé à plus de 398 millions de requêtes par seconde (rps). À titre de comparaison, l'attaque la plus importante observée par l'entreprise en 2022 a culminé à 46 millions de requêtes par seconde. L'attaque ciblant Cloudflare en août a atteint 201 millions de requêtes par seconde, soit trois fois plus que la plus grande attaque DDoS détectée précédemment par le fournisseur. Cette attaque HTTP/2 Rapid Reset a été lancée à partir d'un botnet composé de 22 000 ordinateurs seulement, ce qui est peu par rapport à d'autres botnets.

Des mesures d'atténuation

Les stratégies d'atténuation de ces attaques ne sont pas simples, car certaines annulations RST_STREAM peuvent être légitimes, de sorte que chaque propriétaire de serveur doit décider quand il y a abus et comment adapter la réponse en fonction des statistiques de connexion et de la logique d'entreprise. Par exemple, si une connexion TCP a plus de 100 requêtes et que le client en annule plus de 50 %, la connexion peut être considérée comme abusive. Les réponses peuvent aller de l'envoi de trames GOAWAY énergiques à la fermeture immédiate de la connexion TCP. Une autre réponse pourrait consister à bloquer l'accès de l'adresse IP incriminée au service HTTP/2 et à la reléguer au seul HTTP 1.x de manière temporaire.

Le problème des filtres IP est que plusieurs clients peuvent partager la même adresse IP et qu'ils ne sont pas tous malveillants. En limitant les requêtes à HTTP 1.x, les clients non malveillants situés derrière une adresse IP filtrée pourront toujours accéder au service web, même si leurs performances s'en trouvent réduites. Les développeurs de Nginx, un reverse-proxy et équilibreur de charge très répandu, ont également proposé des mesures d'atténuation qui s'appuient sur des fonctionnalités spécifiques déjà mises en œuvre par le serveur, telles que keepalive_requests, limit_conn et limit_req. Ils livreront aussi un correctif dans les prochains jours qui limitera encore l'impact de ces attaques. Microsoft, AWS, F5 et d'autres entreprises d'infrastructure, de fournisseurs de serveurs web ou de logiciels de load balancing ont publié des mesures d'atténuation ou des correctifs. Les utilisateurs peuvent consulter régulièrement le formulaire officiel dans le CVE Tracker pour obtenir des liens avec les réponses mises à jour des fournisseurs.