Plus tôt aujourd'hui, Cloudflare, Google et Amazon AWS ont révélé l'existence d'une nouvelle vulnérabilité zero-day, baptisée « HTTP/2 Rapid Reset ». Cette attaque exploite une faiblesse du protocole HTTP/2 afin de lancer d'immenses attaques hyper-volumétriques par déni de service distribué (DDoS). Au cours des derniers mois, Cloudflare a atténué un véritable barrage d'attaques de ce type, notamment une attaque trois fois plus importante que toutes les attaques que nous avions précédemment observées, qui a dépassé 201 millions de requêtes par seconde (r/s). Depuis la fin du mois d'août 2023, Cloudflare a atténué plus de 1 100 autres attaques dépassant 10 millions de r/s, dont 184 attaques plus vastes que la précédente attaque DDoS record que nous avions observée, de 71 millions de r/s.
Cette attaque zero-day a fourni aux acteurs malveillants un nouvel outil essentiel sur leur couteau suisse d'exploitations de vulnérabilités, leur permettant de lancer contre leurs victimes des attaques d'une ampleur encore jamais observée. Bien qu'elles soient parfois complexes et difficiles à combattre, ces attaques ont permis à Cloudflare de développer une technologie spécifique, permettant d'atténuer les effets de cette vulnérabilité zero-day.
Si vous utilisez Cloudflare pour l'atténuation des attaques DDoS HTTP, vous êtes protégé. Vous trouverez ci-dessous plus d'informations sur cette vulnérabilité, ainsi que des ressources et des recommandations sur les dispositions que vous pouvez prendre pour garantir votre sécurité.
Déconstruction de l'attaque : ce que chaque directeur de la sécurité doit savoir
Fin août 2023, l'équipe de Cloudflare a remarqué une nouvelle vulnérabilité zero-day, développée par un acteur malveillant inconnu, qui exploite le protocole standard HTTP/2 – un protocole fondamental, essentiel au fonctionnement d'Internet et de tous les sites web. Cette nouvelle attaque zero-day, baptisée Rapid Reset, exploite la fonction d'annulation de flux du protocole HTTP/2 en transmettant une requête, puis en l'annulant immédiatement, encore et encore.
En automatisant à grande échelle ce schéma trivial (« requête, annulation, requête, annulation »), les acteurs malveillants parviennent à provoquer un déni de service, et ainsi, à entraîner l'arrêt de n'importe quel serveur ou application utilisant l'implémentation standard du protocole HTTP/2. Par ailleurs, il est important de noter que cette attaque record a été lancée avec un botnet de taille modeste, constitué d'environ 20 000 machines. Cloudflare détecte régulièrement des botnets d'une taille bien supérieure, comptant des centaines de milliers, voire des millions de machines. Le fait qu'un botnet de taille relativement moindre puisse générer un tel volume de requêtes, offrant la possibilité de neutraliser pratiquement tous les serveurs ou applications prenant en charge le protocole HTTP/2, souligne la gravité de la menace que représente cette vulnérabilité pour les réseaux non protégés.
Les acteurs malveillants ont utilisé des botnets conjointement à la vulnérabilité du protocole HTTP/2 afin d'amplifier les requêtes à des taux encore jamais observés. Suite à cette attaque, l'équipe de Cloudflare a observé des phénomènes d'instabilité intermittente à la périphérie du réseau. Bien que nos systèmes aient été en mesure d'atténuer l'immense majorité des attaques entrantes, le volume a surchargé certains composants de notre réseau, entraînant une altération des performances pour un petit nombre de clients, qui ont constaté des erreurs 4xx et 5xx intermittentes ; toutes ont été rapidement résolues.
Lorsque nous sommes parvenus à atténuer ces problèmes et à mettre fin aux attaques potentielles pour l'ensemble des clients, notre équipe a immédiatement lancé une procédure de divulgation responsable. Nous avons commencé à échanger avec des homologues de l'industrie afin d'évaluer comment nous pourrions coopérer pour préserver la continuité de notre mission et protéger l'importante proportion d'Internet reposant sur notre réseau, avant de divulguer cette vulnérabilité au grand public.
Nous couvrons les aspects techniques détaillés de l'attaque dans un article de blog distinct : HTTP/2 Rapid Reset : anatomie de l'attaque record.
Comment Cloudflare et l'industrie déjouent-ils cette attaque ?
Il n'existe pas de « divulgation parfaite ». Pour déjouer les attaques et réagir aux nouveaux incidents, les entreprises et les équipes de sécurité doivent adopter un état d'esprit supposant l'existence d'une violation : il existera toujours une nouvelle vulnérabilité zero-day, des groupes d'acteurs malveillants nouveaux et changeants et des attaques et des techniques inédites.
Cet état d'esprit consistant à supposer l'existence d'une violation constitue une fondation essentielle pour la diffusion d'informations et pour garantir, dans des situations telles que celle-ci, que l'Internet demeure sûr. Pendant que Cloudflare subissait et atténuait ces attaques, nous travaillions également avec des partenaires de l'industrie afin de garantir que cette dernière serait, dans son ensemble, capable de résister à cette attaque.
Durant le processus d'atténuation de l'attaque, l'équipe de Cloudflare a développé une nouvelle technologie dédiée permettant d'arrêter ces attaques DDoS et d'améliorer encore nos mesures d'atténuation de cette attaque et d'autres futures attaques de très grande ampleur. Ces efforts ont considérablement amélioré nos capacités globales d'atténuation, ainsi que notre résilience. Si vous utilisez Cloudflare, nous pouvons vous assurer que vous êtes protégé.
Notre équipe a également alerté les partenaires développant les logiciels pour serveurs web, qui élaborent actuellement des correctifs afin d'assurer que cette vulnérabilité ne pourra pas être exploitée ; nous vous invitons à consulter leurs sites web pour plus d'informations.
Les divulgations ne sont jamais définitivement terminées. La raison d'être de Cloudflare est d'assurer un Internet meilleur, qui découle de situations telles que celle-ci. Lorsque nous avons l'occasion de coopérer avec les entreprises partenaires de l'industrie et les administrations afin d'assurer l'absence d'impacts généralisés pour l'ensemble d'Internet, nous contribuons à améliorer la cyber-résilience de chaque entreprise, quelle que soit sa taille ou son secteur d'activité.
Pour mieux comprendre les tactiques d'atténuation et les prochaines étapes de la mise en œuvre des correctifs, inscrivez-vous à notre webinaire.
Quelles sont les origines de l'attaque HTTP/2 Rapid Reset et de ces attaques record lancées contre Cloudflare ?
Il peut paraître étrange que Cloudflare ait été l'une des premières entreprises à observer ces attaques. Pourquoi des acteurs malveillants s'en prendraient-ils à une entreprise dont les systèmes de défense contre les attaques DDoS figurent parmi les plus robustes du monde ?
En réalité, Cloudflare a souvent l'occasion d'observer des attaques avant qu'elles ne soient lancées contre des cibles plus vulnérables. Les acteurs malveillants doivent développer et tester leurs outils avant de les déployer « dans la nature ». Les acteurs malveillants qui détiennent des méthodes permettant de lancer des attaques record peuvent se heurter à d'importantes difficultés pour tester et comprendre l'ampleur et l'efficacité de leurs méthodes, car ils ne disposent pas de l'infrastructure nécessaire pour absorber les attaques qu'ils lancent. La transparence avec laquelle nous partageons les performances de notre réseau et les mesures des attaques présentées sur les graphiques de performances que nous diffusons publiquement ont vraisemblablement incité à ces acteurs malveillants à nous cibler afin de mieux comprendre les capacités de cette exploitation de vulnérabilité.
Toutefois, ces tests et la capacité de détecter précocement l'attaque nous aident à élaborer des mesures d'atténuation qui profitent à la fois à nos clients et à l'industrie dans son ensemble.
D'un directeur de la sécurité à un autre : que devez-vous faire ?
Je suis directeur de la sécurité depuis plus de 20 ans, durant lesquels j'ai été le destinataire d'innombrables divulgations et annonces semblables à celle-ci. Toutefois, qu'il s'agisse de Log4J, de Solarwinds, d'EternalBlue WannaCry/NotPetya, de Heartbleed ou de Shellshock, tous ces incidents de sécurité ont un point commun : celui de provoquer une explosion colossale, qui se répercutait dans le monde entier, offrant l'opportunité de perturber profondément toutes les entreprises que j'ai dirigées, quel que soit leur secteur d'activité ou leur taille.
Il s'agissait, dans de nombreux cas, d'attaques ou de vulnérabilités que nous n'avons pas été en mesure de maîtriser. Indépendamment de l'origine du problème, qu'il soit ou non imputable à un paramètre qui échappait à mon contrôle, ce qui a toujours distingué les initiatives couronnées de succès de celles dont l'issue nous a été défavorable, c'est la capacité de réagir lorsque des vulnérabilités zero-day et des exploitations de vulnérabilités telles que celle-ci sont identifiées.
J'aimerais pouvoir dire que cette fois, l'attaque HTTP/2 Rapid Reset sera peut-être différente, mais ce n'est pas le cas. J'adresse ce message à tous les directeurs de la sécurité – que vous ayez, comme moi, l'expérience de décennies d'incidents de sécurité ou que ce soit votre premier jour à votre poste : le moment est venu de vous assurer d'être protégé et de mobiliser votre équipe de réponse aux cyber-incidents.
Nous avons préservé la confidentialité de l'information jusqu'à aujourd'hui, afin de laisser au plus grand nombre possible de fournisseurs de solutions de sécurité l'opportunité de réagir. À un moment donné, toutefois, l'approche responsable consiste à divulguer publiquement l'existence d'une menace zero-day comme celle-ci, et c'est aujourd'hui que nous devons le faire.Cela signifie qu'à partir d'aujourd'hui, les acteurs malveillants seront largement informés de l'existence de la vulnérabilité HTTP/2, et qu'il deviendra inévitablement facile de l'exploiter. Cela donnera le coup d'envoi d'une course entre défenseurs et acteurs malveillants : les premiers à appliquer un correctif contre les premiers à exploiter la vulnérabilité. Les entreprises doivent partir du principe que leurs systèmes seront testés et doivent prendre des mesures proactives afin d'assurer leur protection.
Cette situation me rappelle une vulnérabilité comme Log4J, en raison des nombreuses variantes qui apparaissent chaque jour et qui continueront à être finalisées au cours des semaines, des mois et des années à venir. À mesure que les chercheurs et les acteurs malveillants testent cette vulnérabilité, nous identifierons peut-être différentes variantes, avec des cycles d'exploitation de vulnérabilité encore plus courts, comportant des méthodes de contournement encore plus avancées.
Et à l'instar de Log4J, la gestion de ce type d'incidents est complexe et exige bien plus que la simple exécution d'un correctif.Vous devez transformer la gestion de l'incident, l'application des correctifs et l'amélioration de vos protections de sécurité en processus continus ; en effet, si les correctifs correspondant à chaque variante d'une vulnérabilité permettent d'atténuer le risque, ils ne l'éliminent pas pour autant.
Je ne veux pas être alarmiste, mais je serai direct : vous devez prendre cette menace au sérieux. Considérez-la comme un incident actif à part entière, afin de vous assurer qu'aucune conséquence délétère n'affectera votre entreprise.
Recommandations pour une nouvelle norme en matière de gestion du changement
Bien qu'aucun événement de sécurité ne soit jamais identique à un autre, il est possible d'en tirer des enseignements. Aussi, aux directeurs de la sécurité, voici mes recommandations, que je vous invite à mettre en œuvre immédiatement ;pas uniquement dans cette situation, mais dans les années à venir :
- Comprenez la connectivité externe de votre réseau et de celui de vos partenaires afin de contenir les menaces liées à tout système accessible depuis Internet, grâce aux mesures d'atténuation ci-dessous.
- Comprenez vos dispositifs existants de protection de la sécurité, ainsi que les capacités dont vous disposez pour protéger, détecter et réagir à une attaque, et remédiez immédiatement à tous les incidents observés sur votre réseau.
- Assurez-vous que votre solution de protection contre les attaques DDoS réside hors de votre datacenter, car si le trafic parvient à votre datacenter, il sera difficile d'atténuer l'attaque DDoS.
- Assurez-vous de disposer d'une protection contre les attaques DDoS pour les applications (couche 7) et de pare-feu d'applications web. En outre, une bonne pratique consiste à vous assurer de disposer d'une protection complète contre les attaques DDoS pour le DNS, le trafic réseau (couche 3) et les pare-feu d'API.
- Veillez à déployer des correctifs pour votre serveur web et votre système d'exploitation sur l'ensemble des serveurs web accessibles depuis Internet. Assurez-vous également que tous les systèmes d'automatisation, tels que les versions et images Terraform, aient reçu tous les correctifs nécessaires, afin que d'anciennes versions des serveurs web ne soient pas accidentellement déployées en production par le biais d'images sécurisées.
- En dernier recours, envisagez de désactiver HTTP/2 et HTTP/3 (probablement vulnérable, lui aussi) afin d'atténuer la menace. Il s'agit d'une solution de dernier recours, car l'utilisation de HTTP/1.1 entraînera d'importants problèmes de performances.
- Envisagez de faire appel à un fournisseur secondaire de services cloud de protection contre les attaques DDoS sur la couche 7, au niveau du périmètre, afin d'assurer la résilience.
Cloudflare s'est donné pour mission de contribuer à bâtir un Internet meilleur. Si vous êtes préoccupé par l'état actuel de votre protection contre les attaques DDoS, nous serons ravis de vous fournir gratuitement nos capacités de protection contre les attaques DDoS et notre résilience, afin d'atténuer toute tentative d'attaque de ce type. Nous sommes conscients du stress auquel vous devez faire face, car nous avons repoussé ces attaques au cours des 30 derniers jours et nous avons encore amélioré nos systèmes, déjà inégalés dans leur catégorie.
Si vous souhaitez en savoir plus, regardez notre webinaire expliquant les détails de la vulnérabilité zero-day et comment vous devez réagir à celle-ci. Contactez-nous si vous n'êtes pas sûr d'être protégé ou vous souhaitez comprendre comment vous pouvez l'être. Nous présentons également des informations techniques plus détaillées sur l'attaque dans un article de blog distinct : HTTP/2 Rapid Reset : anatomie de l'attaque record. Enfin, si vous êtes la cible d'une attaque ou si vous avez besoin d'une protection immédiate, veuillez contacter votre représentant Cloudflare local ou consulter la page https://www.cloudflare.com/fr-fr/under-attack-hotline/.