Google, AWS et Cloudflare ont stoppé ce qui serait la plus grande attaque DDoS jamais enregistrée, selon les annonces des fournisseurs mardi.
L’attaque est le résultat d’une nouvelle vulnérabilité DDoS, identifiée comme CVE-2023-44487, qui concerne le protocole HTTP/2, l’ensemble standardisé de règles pour le transfert de fichiers sur Internet. Selon la page de la vulnérabilité sur le site Web de l’Institut national des normes et technologies, « Le protocole HTTP/2 permet un déni de service (consommation des ressources du serveur) car l’annulation de la demande peut réinitialiser rapidement de nombreux flux, comme cela a été exploité dans la nature entre août et octobre 2023. “.
Dans le cadre d’une divulgation coordonnée, Google Cloud, Amazon Web Services et Cloudflare ont publié des articles de blog et des avis fournissant des informations techniques supplémentaires concernant le vecteur d’attaque DDoS. Dans l’un des deux articles de blog publiés par Google, le géant de la technologie l’a décrit comme « la plus grande attaque DDoS à ce jour, culminant au-dessus de 398 millions de rps ». [requests per second]”.
Lors de la panne technique de Cloudflare, il a enregistré un pic de plus de 201 millions de requêtes par seconde, soit près de trois fois plus important que la précédente attaque record qu’il avait observée.
“Il est préoccupant que l’attaquant ait pu générer une telle attaque avec un botnet de seulement 20 000 machines”, ont écrit Lucas Pardue et Julien Desgats, ingénieurs de Cloudflare. « Il existe aujourd’hui des réseaux de zombies composés de centaines de milliers, voire de millions de machines. Étant donné que l’ensemble du Web ne reçoit généralement qu’entre 1 et 3 milliards de requêtes par seconde, il n’est pas inconcevable que l’utilisation de cette méthode puisse concentrer l’ensemble des requêtes d’un site Web. sur un petit nombre de cibles.”
Dans un autre article de blog consacré au fonctionnement de l’attaque et du vecteur d’attaque, les ingénieurs de Google, Juho Snellman et Daniele Iamartino, ont écrit que l’attaque, surnommée « Rapid Reset », s’est produite sur une série de mois et a culminé en août.
Les auteurs ont déclaré que depuis fin 2021, la majorité des attaques DDoS de la couche application, ou couche 7, observées sur les services Google étaient basées sur HTTP/2, « à la fois en termes de nombre d’attaques et de taux de demandes de pointe ».
“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”, peut-on lire dans le message.
Les attaques HTTP/2 sont dominantes, a expliqué Google, en raison de la capacité du protocole à traiter les requêtes sous forme de plusieurs « flux » simultanés, plutôt que de la nécessité pour HTTP/1.1 de traiter les requêtes en série. Ainsi, une attaque HTTP/2 peut exécuter bien plus de requêtes simultanées qu’une attaque exploitant un protocole plus ancien.
Avec Rapid Reset, le client attaquant “ouvre un grand nombre de flux à la fois comme dans l’attaque HTTP/2 standard, mais plutôt que d’attendre une réponse à chaque flux de requête du serveur ou du proxy, le client annule immédiatement chaque requête”.
“La possibilité de réinitialiser les flux immédiatement permet à chaque connexion d’avoir un nombre indéfini de requêtes en cours”, lit-on dans le message. “En annulant explicitement les requêtes, l’attaquant ne dépasse jamais la limite du nombre de flux ouverts simultanés. Le nombre de requêtes en cours ne dépend plus du temps d’aller-retour (RTT), mais uniquement de la bande passante disponible du réseau. ”
De plus amples détails techniques sont disponibles dans les articles de blog de Google, Cloudflare et Amazon.
Google a déclaré que son infrastructure d’équilibrage de charge avait réussi à stopper « en grande partie » les attaques de réinitialisation rapide à la périphérie de son réseau, évitant ainsi toute panne. Amazon a déclaré qu’AWS avait déterminé la nature de l’attaque “en quelques minutes” et que son réseau de diffusion de contenu CloudFront avait automatiquement atténué l’attaque.
Cloudflare, quant à lui, a déclaré avoir constaté des pics d’erreurs et de requêtes 502, mais avoir réagi rapidement en modifiant sa pile et en atténuant les détails dans sa ventilation technique. Selon l’entreprise, “tous nos clients sont protégés contre cette nouvelle méthode d’attaque DDoS sans aucun impact sur les clients”.
Concernant les mesures d’atténuation, Google a déclaré que le blocage des requêtes individuelles ne suffirait pas et qu’il était nécessaire de fermer l’intégralité de la connexion TCP dès qu’un abus était détecté. Des atténuations plus larges incluent le suivi des statistiques de connexion et la priorisation des connexions pour l’atténuation HTTP/2 intégrée du type de trame GOAWAY en fonction de divers signaux. Les trois fournisseurs ont également mis en œuvre des détections et des atténuations internes supplémentaires.
Un porte-parole d’AWS a déclaré à TechTarget Editorial que les serveurs Web seraient mis à jour pour résoudre le problème et qu’une adoption généralisée devrait permettre une atténuation plus large. De même, un porte-parole de Google a souligné le fait qu’un certain nombre d’éditeurs de logiciels ont publié des correctifs parallèlement à la divulgation de mardi. Ces fournisseurs incluent Apple, Microsoft, F5 et d’autres.
Dans le billet de blog Cloudflare, Pardue et Desgats ont averti que le risque d’attaques CVE-2023-44487 et Rapid Reset était omniprésent. “Comme l’attaque exploite une faiblesse sous-jacente du protocole HTTP/2, nous pensons que tout fournisseur ayant implémenté HTTP/2 sera soumis à l’attaque”, ont-ils écrit. “Cela inclut tous les serveurs Web modernes.”
Alex Forster, ingénieur logiciel Cloudflare pour l’atténuation des attaques DDoS, a déclaré que même si la divulgation publique d’aujourd’hui indique que des correctifs ont été publiés et que l’étape restante consiste pour les clients à les déployer, la gestion d’une infrastructure complexe est plus compliquée que l’exécution d’un correctif.
« Les organisations doivent transformer la gestion des incidents, les correctifs et l’évolution des protections de sécurité en processus continus », a déclaré Forster. « Les correctifs pour chaque variante d’une vulnérabilité réduisent le risque mais ne l’éliminent pas toujours complètement. Dans ce cas, Cloudflare a développé une technologie spécialement conçue pour atténuer les effets de la vulnérabilité Zero Day.
