Une vulnérabilité du protocole HTTP/2 baptisée « Rapid Reset » a provoqué des attaques DDoS record contre des serveurs web ces derniers mois. Google, AWS et Cloudflare ont révélé conjointement les attaques et la vulnérabilité aujourd’hui, mais ont précisé que tous les serveurs web modernes restaient vulnérables à cette technique d’attaque. Les fournisseurs et projets de serveurs web ont également annoncé des mesures d’atténuation et des plans de correctifs.
Google a indiqué que les attaques avaient atteint un pic de 398 millions de requêtes par seconde (rps), soit plus de cinq fois le volume du précédent record établi en février 2023 — et davantage de trafic web en deux minutes que Wikipedia n’en a reçu pendant tout le mois de septembre. Cloudflare a indiqué avoir observé un pic d’attaques légèrement supérieur à 201 millions de requêtes par seconde.
Google, AWS et Cloudflare ont déclaré avoir pu limiter les dommages causés par les attaques. « Alors qu’au départ nous avions constaté un certain impact sur le trafic des clients — environ 1 % des requêtes ayant été affectées lors de la première vague d’attaques — nous avons aujourd’hui pu affiner nos méthodes d’atténuation afin de bloquer l’attaque pour tous les clients de Cloudflare sans que cela n’affecte nos systèmes », a déclaré Cloudflare.
Un fait préoccupant est que les attaquants ont pu générer l’attaque avec un réseau de bots composé de seulement 20 000 machines. « Il existe aujourd’hui des réseaux de bots constitués de centaines de milliers, voire de millions de machines », a déclaré Cloudflare dans un billet de blog technique consacré à la vulnérabilité (CVE-2023-44487). « Étant donné que l’ensemble du web ne voit généralement passer qu’entre 1 et 3 milliards de requêtes par seconde, il n’est pas inconcevable que cette méthode permette de concentrer l’équivalent des requêtes de tout un web sur un petit nombre de cibles. »
La généralisation de la vulnérabilité est tout aussi préoccupante.
À lire aussi : Comment stopper les attaques DDoS en trois étapes
« Tous les serveurs web modernes » sont concernés
Cloudflare a indiqué que, comme l’attaque exploite une faiblesse sous-jacente du protocole HTTP/2, « nous pensons que tout fournisseur ayant implémenté HTTP/2 sera exposé à l’attaque. Cela concerne tous les serveurs web modernes. »
« Avec Google et AWS, nous avons signalé la méthode d’attaque aux fournisseurs de serveurs web, dont nous attendons la mise en œuvre de correctifs. En attendant, la meilleure défense consiste à utiliser un service d’atténuation des attaques DDoS comme celui de Cloudflare devant tout serveur web ou serveur d’API accessible depuis le web. »
Les fournisseurs de serveurs web et les projets open source, notamment Apache Tomcat, Microsoft et plusieurs autres, ont publié des recommandations pour faire face à la vulnérabilité ; le nombre croissant d’annonces peut être consulté dans la fiche CVE.
NGINX a par exemple recommandé plusieurs modifications de configuration afin de réduire la surface d’attaque :
- keepalive_requests doit conserver la valeur par défaut de 1 000 requêtes
- http2_max_concurrent_streams doit conserver la valeur par défaut de 128 flux
- limit_conn impose une limite au nombre de connexions autorisées depuis un même client et devrait être ajouté « avec un réglage raisonnable conciliant performances et sécurité de l’application »
- limit_req impose une limite au nombre de requêtes traitées depuis un même client pendant une période donnée et devrait également concilier performances et sécurité de l’application.
NGINX a indiqué qu’il publierait demain un correctif imposant une limite au nombre de nouveaux flux pouvant être introduits au cours d’une boucle d’événements. Cette limite sera fixée à deux fois la valeur configurée à l’aide de la directive http2_max_concurrent_streams. « La limite sera appliquée même si le seuil maximal n’est jamais atteint, par exemple lorsque les flux sont réinitialisés juste après l’envoi de la requête (comme dans le cas de cette attaque) », a déclaré NGINX.
À lire aussi :
- Comment prévenir les attaques DDoS : 5 étapes pour se protéger des DDoS
- Comment savoir si vous avez subi une attaque DDoS : 5 signes d’une attaque DDoS
Comment fonctionne l’attaque HTTP/2 « Rapid Reset »
Dans un billet de blog technique consacré à l’attaque HTTP/2 « Rapid Reset », Google a indiqué que « l’un des principaux objectifs de conception de HTTP/2 était l’efficacité et, malheureusement, les fonctionnalités qui rendent HTTP/2 plus efficace pour les clients légitimes peuvent également être utilisées pour rendre les attaques DDoS plus efficaces. »
En substance, l’attaque Rapid Reset exploite une fonctionnalité de HTTP/2 appelée « annulation de flux » en envoyant des requêtes à répétition, puis en les annulant immédiatement.
Le protocole HTTP/2 permet aux clients d’indiquer à un serveur qu’un flux précédent doit être annulé en envoyant une trame RST_STREAM, a indiqué Google. Le protocole n’exige pas que le client et le serveur coordonnent l’annulation, et le client peut agir unilatéralement. Il peut également supposer que l’annulation prendra effet immédiatement lorsque le serveur recevra la trame RST_STREAM, avant que toute autre donnée provenant de cette connexion TCP ne soit traitée.
« Cette attaque est appelée Rapid Reset, car elle repose sur la capacité d’un point d’accès à envoyer une trame RST_STREAM immédiatement après une trame de requête, ce qui amène l’autre point d’accès à commencer son traitement, puis réinitialise rapidement la requête », a indiqué Google. « La requête est annulée, mais la connexion HTTP/2 reste ouverte. »
L’attaque HTTP/2 Rapid Reset qui s’appuie sur cette fonctionnalité est simple, a indiqué Google :
« Le client ouvre simultanément un grand nombre de flux, comme dans une attaque HTTP/2 standard, mais au lieu d’attendre une réponse du serveur ou du proxy pour chaque flux de requête, il annule immédiatement chaque requête. La possibilité de réinitialiser immédiatement les flux permet à chaque connexion d’avoir un nombre indéfini de requêtes en cours. En annulant explicitement les requêtes, l’attaquant ne dépasse jamais la limite du nombre de flux ouverts simultanément. Le nombre de requêtes en cours ne dépend plus du temps aller-retour (RTT), mais uniquement de la bande passante réseau disponible. »
Dans une implémentation classique d’un serveur HTTP/2, le serveur « devra tout de même effectuer une quantité importante de travail pour les requêtes annulées, notamment allouer de nouvelles structures de données de flux, analyser la requête et décompresser les en-têtes, puis faire correspondre l’URL à une ressource », a indiqué Google.
Pour les implémentations de proxy inverse, « la requête peut être transmise au serveur principal avant le traitement de la trame RST_STREAM. Le client, en revanche, n’a pratiquement rien payé pour envoyer les requêtes. Cela crée une asymétrie de coûts exploitable entre le serveur et le client. L’attaquant bénéficie également du fait que l’annulation explicite des requêtes immédiatement après leur création signifie qu’un serveur proxy inverse n’enverra de réponse à aucune des requêtes. »
Les mesures d’atténuation peuvent prendre plusieurs formes, mais elles consistent principalement à suivre les statistiques des connexions et à utiliser des signaux ainsi que la logique métier pour déterminer l’utilité de chaque connexion, a indiqué Google. « Par exemple, si une connexion compte plus de 100 requêtes et que plus de 50 % de ces requêtes sont annulées, elle pourrait justifier une mesure d’atténuation. L’ampleur et le type de la réponse dépendent du risque pour chaque plateforme, mais les réponses peuvent aller de l’envoi de trames GOAWAY forcées, comme indiqué précédemment, à la fermeture immédiate de la connexion TCP.
« Pour se prémunir contre la variante non annulante de cette attaque, nous recommandons aux serveurs HTTP/2 de fermer les connexions qui dépassent la limite de flux simultanés. Cela peut être fait immédiatement ou après un petit nombre de récidives. »
À lire ensuite :