Des sites Web peuvent tomber en 10 secondes : la nouvelle technique qui contourne les défenses et affole les experts

Les attaques par déni de service (DDoS) sont à la fois un cauchemar pour les gestionnaires des sites ciblés et une des attaques les plus basiques et simples. Il s'agit de bombarder un site de connexions afin de saturer ses serveurs et que le service devienne totalement inaccessible. Pour envoyer ce volume massif de requêtes simultanées, un grand réseau de machines (botnet) est nécessaire. Ces gigantesques réseaux de botnets peuvent être loués ou bien ces attaques reposent sur des milliers d'appareils mal sécurisés (caméras, routeurs, objets connectés et ordinateurs non mis à jour).

Imaginez maintenant qu'un seul ordinateur suffise pour réaliser ce type d'attaque. C'est justement la nouveauté que la société californienne de cybersécurité Calif vient de documenter. Les détails de cette technique seront présentés lors de la conférence Real World AI Security qui se tiendra du 23 au 25 juin à l'Université de Stanford aux États-Unis.

Pour la détecter, l'IA Codex d'OpenAI a été utilisée par les chercheurs de Calif. Cette nouvelle attaque DDoS a été baptisée « HTTP/2 Bomb ». À partir d'une seule machine, il est possible de mettre hors service des serveurs web en seulement quelques secondes.

Autopsie d’une attaque DDoS 2.0 très complexe

Cette technique fonctionne sur les configurations HTTP/2 des principaux serveurs web (NGINX, Apache HTTP Server, Microsoft IIS, Envoy et Cloudflare Pingora). Ce HTTP/2 est la version modernisée du protocole qui régit les échanges entre un navigateur et un serveur web. Il a été conçu pour être plus rapide que son prédécesseur (HTTP/1.1). Il y parvient en compressant les données et en ayant la capacité d'envoyer plusieurs requêtes simultanément sur une seule connexion. Ces deux facteurs accélèrent sensiblement le chargement des sites web.

Malheureusement, c'est à double tranchant parce que les optimisations qui rendent HTTP/2 rapide se retournent contre lui. La compression HPACK économise la bande passante en compressant les en-têtes. C'est plutôt vertueux... Mais, si l'attaquant envoie une information au serveur et qu'il y fait référence des milliers de fois, octet par octet, par la suite le serveur doit recréer l'information complète en mémoire pour chaque octet. De fait, il travaille énormément pour presque rien.

Déroulé de l’attaque DDoS, sur le graphique en bas, on peut voir que la mémoire vive du serveur s’engorge jusqu’à saturation. © Calif

Libérez la mémoire vive !

Après avoir saturé la mémoire, la seconde phase de l’attaque consiste à empêcher sa libération via l'outil de contrôle des flux. L'astuce revient à le faire fonctionner à l'envers de ce pour quoi il est conçu. Pour cela, il faut expliquer au serveur qu'il doit patienter avant d'envoyer une réponse. Celui-ci est alors contraint de conserver indéfiniment la mémoire allouée à la requête, sans jamais pouvoir la libérer.

En manipulant ces deux systèmes, un simple ordinateur personnel doté d'une connexion de 100 Mbps peut épuiser des dizaines de gigaoctets de mémoire vive en quelques secondes. En prenant l'exemple d'un serveur Apache ou bien Envoy, cette unique machine peut engorger 32 Go de mémoire serveur en une vingtaine de secondes.

Moins d’une minute pour faire planter un site

Les chercheurs de Calif expliquent que cette approche plutôt habile contourne les défenses existantes de ce système. Lors de leurs tests, les chercheurs de Calif ont fait tomber un serveur Envoy en une dizaine de secondes. Un Apache a épuisé ses 32 Go de mémoire vive en à peine 18 secondes. Enfin, il a fallu 45 secondes pour obtenir le même résultat avec un serveur nginx et ISS (Windows Server 2025). Bref, dans tous les cas, en moins d'une minute, le serveur tombe à coup sûr.

Si cette attaque HTTP/2 Bomb a de quoi inquiéter, ce n'est pas une fatalité. Tous les serveurs ne sont pas affectés et des correctifs ont déjà été publiés pour certaines plateformes. De plus, certaines configurations très personnalisées peuvent offrir une protection indirecte contre cette attaque. C'est notamment le cas des serveurs qui fonctionnent derrière des CDN ou des proxys inverses. Ces systèmes fonctionnent comme des intermédiaires placés devant le serveur pour filtrer le trafic et empêcher l'attaquant d'atteindre directement la cible vulnérable.

En attendant le déploiement de correctifs, les experts recommandent de désactiver HTTP/2, lorsque cela est possible, et de mettre en place un proxy/pare-feu imposant des limites strictes au nombre d'en-têtes. Comme toujours, et tant qu'ils ne seront pas menacés par ce type d'attaque, de très nombreux serveurs resteront des cibles potentielles pendant très longtemps.