La plus grande attaque DDoS jamais observée a culminé à 398 millions de rps
(cloud.google.com)- Alors que l’ampleur des attaques DDoS augmente rapidement, Google a atténué en août 2023 une attaque culminant à 398 millions de rps, soit 7,5 fois le record de l’année précédente, fixé à 46 millions de rps
- Les attaquants ont utilisé la technique Rapid Reset, qui exploite le multiplexage des flux de HTTP/2, et plusieurs entreprises d’infrastructure Internet ont été touchées
- La vague d’attaques a commencé fin août 2023 et s’est poursuivie jusqu’en septembre, visant de grands fournisseurs d’infrastructure, dont les services Google, l’infrastructure Google Cloud et ses clients
- Google a absorbé l’attaque à la périphérie du réseau et mis à jour ses systèmes de défense ; les clients d’Application Load Balancer et de Cloud Armor bénéficient de la même base de protection
- Les serveurs, proxys, serveurs d’applications et équilibreurs de charge prenant en charge HTTP/2 peuvent être affectés par CVE-2023-44487 ; il est nécessaire de vérifier leur exposition et d’appliquer les correctifs des éditeurs
Ampleur de l’attaque et technique Rapid Reset
- La DDoS Response Team de Google observe depuis plusieurs années une croissance exponentielle de l’ampleur des attaques DDoS
- L’attaque bloquée en août 2023 était 7,5 fois plus importante que le précédent record annuel
- Elle a culminé à 398 millions de requests per second (rps)
- Le plus grand DDoS enregistré en 2022 avait atteint 46 millions de rps
- Cette attaque, qui a duré deux minutes, a généré plus de requêtes que le nombre total de consultations d’articles signalé par Wikipédia pour l’ensemble du mois de septembre 2023
- La technique clé était le nouveau HTTP/2 Rapid Reset, qui exploite la fonctionnalité de multiplexage des flux de HTTP/2
Cibles de l’attaque et impact sur les services
- La récente vague d’attaques a commencé fin août 2023 et a continué d’être observée tout au long de septembre
- Parmi les cibles figuraient de grands fournisseurs d’infrastructure
- Services Google
- Infrastructure Google Cloud
- Clients Google
- Google a maintenu ses services en fonctionnement grâce à son infrastructure mondiale d’équilibrage de charge et d’atténuation DDoS
- En coopération avec ses partenaires du secteur, l’entreprise a identifié le mécanisme de l’attaque et coordonné les mesures d’atténuation pour protéger Google, ses clients et l’Internet dans son ensemble
Méthode d’atténuation de Google et protection des clients Cloud
- L’enquête a montré que l’attaque utilisait la technique Rapid Reset, fondée sur la fonctionnalité de multiplexage des flux du protocole HTTP/2, largement utilisé
- Google a atténué l’attaque à la périphérie du réseau
- En s’appuyant sur ses investissements dans la capacité en edge, Google a fait en sorte que ses services et ceux de ses clients ne soient globalement pas affectés
- Après avoir mieux compris la méthode d’attaque, l’entreprise a développé des contre-mesures
- Elle a mis à jour ses proxys et ses systèmes de défense contre les attaques par déni de service afin de réduire efficacement l’impact de cette technique
- Application Load Balancer et Cloud Armor de Google Cloud utilisent la même infrastructure matérielle et logicielle que celle employée par Google pour ses propres services exposés à Internet
- Les applications web et services exposés à Internet des clients Cloud utilisant ces services bénéficient donc d’une protection similaire
CVE-2023-44487 et réponse coordonnée du secteur
- Dès la détection des premières attaques en août, Google a appliqué des stratégies d’atténuation supplémentaires et coordonné une réponse conjointe du secteur avec des fournisseurs cloud et des mainteneurs logiciels implémentant la pile du protocole HTTP/2
- Pendant l’attaque, les informations et méthodes d’atténuation ont été partagées en temps réel
- Cette coopération a débouché sur des correctifs et des techniques d’atténuation utilisés par plusieurs grands fournisseurs d’infrastructure
- La nouvelle méthode d’attaque ainsi que les vulnérabilités potentielles de plusieurs proxys, serveurs d’applications et équilibreurs de charge open source et commerciaux courants ont fait l’objet d’une divulgation coordonnée
- La vulnérabilité collective liée à cette attaque est suivie sous CVE-2023-44487
- Niveau de gravité : High
- Score CVSS : 7.5/10
Systèmes potentiellement affectés et mesures nécessaires
- Les entreprises comme les particuliers exposant sur Internet des charges de travail fondées sur HTTP peuvent être exposés au risque de cette attaque
- Les applications web, services et API reposant sur des serveurs ou proxys capables de communiquer en HTTP/2 peuvent être vulnérables
- Les organisations doivent vérifier que leurs serveurs prenant en charge HTTP/2 ne sont pas vulnérables
- Si vous exploitez ou administrez vos propres serveurs prenant en charge HTTP/2, il faut appliquer dès leur disponibilité les correctifs fournis par les éditeurs, qu’ils soient open source ou commerciaux
- Les correctifs des éditeurs pour CVE-2023-44487 constituent une mesure visant à limiter l’impact de ce vecteur d’attaque
Recommandations de défense dans l’environnement Google Cloud
- La défense contre des attaques DDoS de grande ampleur est difficile et, indépendamment de l’application des correctifs, maintenir les services en ligne face à des attaques de taille moyenne ou supérieure exige des investissements importants en infrastructure
- Les organisations opérant leurs services sur Google Cloud peuvent s’appuyer sur les investissements en capacité à l’échelle mondiale de Cross-Cloud Network pour fournir et protéger leurs applications
- Les clients Google Cloud exposant leurs services via un Application Load Balancer global ou régional bénéficient de la protection de Cloud Armor always-on DDoS protection
- Les attaques exploitant des vulnérabilités comme CVE-2023-44487 sont atténuées rapidement
- Même si Cloud Armor always-on DDoS protection peut absorber à la périphérie du réseau Google la majorité des centaines de millions de requêtes par seconde, plusieurs millions de requêtes indésirables par seconde peuvent encore passer
- Pour répondre aux attaques de couche 7, il est recommandé de déployer des custom security policies Cloud Armor, des règles proactives de rate limiting et la Adaptive Protection basée sur l’IA
- Des informations techniques sur l’actuelle vague d’attaques DDoS sont disponibles dans Analyse de l’attaque DDoS HTTP/2 Rapid Reset
1 commentaires
Avis de Hacker News
The novel HTTP/2 'Rapid Reset' DDoS attack - https://news.ycombinator.com/item?id=37830987
HTTP/2 Zero-Day Vulnerability Results in Record-Breaking DDoS Attacks - https://news.ycombinator.com/item?id=37830998
Mais si le résultat se limite à gêner pendant quelques heures des entreprises technologiques américaines et leurs clients, j’ai encore du mal à comprendre pourquoi cela continue à se produire.
Cette réputation leur permet ensuite de se faire payer par des clients peu scrupuleux qui veulent attaquer des concurrents ; ces clients peuvent être des gouvernements, ou des entreprises douteuses. L’an dernier, beaucoup de sociétés de crypto s’attaquaient mutuellement leurs sites web.
Les gens qui font ça ont souvent un haut niveau technique, mais peu d’occasions de gagner de l’argent avec ces compétences, à cause de l’endroit où ils vivent ou de leur environnement d’origine.
Pour des attaquants avancés, il s’agit de tester des capacités et des réponses. Les Taliban payaient autrefois des enfants pour faire exploser des pétards à l’extérieur des bases afin d’observer les tactiques, techniques et procédures défensives, et cela avait aussi pour effet de désensibiliser aux coups de feu.
Un adversaire vraiment doué sait faire la seconde chose tout en donnant l’impression de faire la première.
Dans le cas du botnet Mirai, certains de ses créateurs exploitaient aussi une société d’atténuation DDoS. En somme, ils vendaient l’arme d’un côté et la défense contre cette arme de l’autre.
La réputation, la plaisanterie, ou simplement le défi de créer un botnet peuvent aussi être des motivations.
Qu’il s’agisse de l’échelle de l’infrastructure Internet ou d’une entreprise précise, je me demande si quelqu’un ayant déjà participé à ce type d’attaque serait assez courageux, ou assez fou, pour créer un compte jetable et expliquer ses motivations.
Leur objectif n’était pas de ralentir le site ciblé, mais ils essayaient de récupérer des données à un rythme qui rendait les coûts serveur ingérables pour de vrais clients payants.
Ce genre d’attaque est différent d’une vraie attaque DDoS, mais d’après mon expérience il est beaucoup plus courant, et il peut être atténué assez facilement avec des solutions comme Cloudflare ou Akamai ; c’est donc ce que je recommande souvent aux clients.
Je me demande si les équipes de Cloudflare, Google et AWS rejoignent une visioconférence en temps réel pour coordonner l’atténuation, ou si chacune observe de loin ce qui se passe ailleurs tout en se concentrant sur son propre problème.
Cette fois, tout le monde s’est rendu compte qu’il voyait la même chose et, comme l’impact pouvait être très important pour de petites cibles, ils ont travaillé ensemble à comprendre le problème et à coordonner la réponse de sécurité avec tous les fournisseurs de serveurs web.
Est-ce seulement disposer d’une bande passante entrante suffisante pour encaisser plusieurs Gb/s tout en gardant de la capacité pour le trafic légitime ?
Une grande partie du trafic DDoS n’est pas du vrai HTTP, mais du trafic poubelle qui sature le tuyau en visant des adresses IP. Des tuyaux plus gros et plusieurs serveurs géographiquement distribués aident. Il arrive aussi que l’attaque se contente d’ouvrir des connexions TCP, comme dans une inondation TCP SYN, pour épuiser les ports disponibles. Ces requêtes anormales peuvent souvent être traitées par plusieurs reverse proxies simples placés devant le serveur
Les requêtes plus sophistiquées, qui en apparence envoient du trafic HTTP normal, doivent au final être traitées. On peut répondre depuis le cache, insérer un CAPTCHA pour ralentir les attaquants et identifier le trafic légitime, ou appliquer une limitation de débit. On veut déterminer si une requête est légitime avant de la transmettre au vrai serveur, et plusieurs outils peuvent être déployés pour cela
Il suffit de configurer le serveur pour rejeter tout trafic qui ne vient pas de Cloudflare, et cette approche est efficace
En général, le trafic interne entre les datacenters de Google est bien supérieur à tout ce qu’un tiers peut envoyer en DDoS, donc on trouve toujours un moyen de le gérer
Mais tous les DDoS ne sont pas volumétriques. Certains exploitent des fonctionnalités de base du protocole, comme les attaques slow loris
https://www.cloudflare.com/learning/ddos/ddos-attack-tools/s...
Dans le cas présent, cela pourrait consister à reconnaître que le client réinitialise rapidement les streams, puis à envoyer ce trafic sur une voie lente ou à le filtrer purement et simplement
https://blog.cloudflare.com/zero-day-rapid-reset-http2-recor...
« Un point essentiel à noter à propos de cette attaque record est qu’elle impliquait un botnet de taille moyenne composé d’environ 20 000 machines »
Si tous les grands fournisseurs faisaient cela, ils pourraient insérer une petite page de type Turnstile devant le prochain site Cloudflare visité
S’il y a un appareil infecté sur mon réseau, j’aimerais le savoir, et aujourd’hui je n’ai pas vraiment de surveillance pour le détecter. Ce ne serait pas une solution complète, mais au moins avertir l’utilisateur qu’il y a un problème serait un bon début