Nouvelle attaque DDoS HTTP/2 « Rapid Reset »
(cloud.google.com)- Une attaque DDoS de couche 7 basée sur HTTP/2 visant les services Google et les clients de Google Cloud a culminé en août 2023, dépassant 398 millions de requêtes par seconde
- L’attaque a été en grande partie bloquée par l’infrastructure mondiale d’équilibrage de charge de Google, sans provoquer d’interruption, et des mesures de protection supplémentaires ont ensuite été ajoutées pour atténuer les attaques similaires
- Rapid Reset consiste à annuler uniquement le flux via une trame RST_STREAM juste après la requête, tout en conservant la connexion, afin de répéter la génération de requêtes en contournant la limite de flux simultanés
- Même pour des requêtes annulées, le serveur peut devoir effectuer des opérations comme la décompression des en-têtes, le mapping d’URL ou le proxy vers le backend, ce qui accentue l’asymétrie des coûts
- Les opérateurs HTTP/2 doivent vérifier leur exposition et appliquer les correctifs ; en cas de détection d’abus, la mesure d’atténuation clé consiste à mettre fin à la connexion TCP elle-même plutôt qu’aux requêtes individuelles
Ampleur de l’attaque et réponse de Google
- Les services Google et les clients Cloud ont été la cible d’une attaque DDoS de couche 7 basée sur HTTP/2 ayant atteint un pic en août 2023
- L’attaque maximale a dépassé 398 millions de requêtes par seconde, soit une ampleur bien supérieure aux précédentes attaques de couche 7 signalées
- L’infrastructure mondiale d’équilibrage de charge de Google a bloqué la majeure partie de l’attaque à la périphérie du réseau
- Aucune interruption ne s’est produite
- L’impact est resté limité
- Après examen de l’attaque, la Google DDoS Response Team a appliqué des protections supplémentaires pour réduire les attaques similaires
- Avec ses partenaires du secteur, Google a mené une procédure de divulgation coordonnée pour traiter ce nouveau vecteur d’attaque HTTP/2
Pourquoi HTTP/2 devient avantageux pour les DDoS
- Depuis fin 2021, une grande partie des attaques DDoS de couche 7 observées sur les services 1st-party de Google et sur les projets Google Cloud protégés par Cloud Armor reposaient sur HTTP/2
- Elles étaient nombreuses en nombre d’attaques
- Elles atteignaient aussi des pics élevés en taux de requêtes
- L’efficacité de HTTP/2 peut améliorer non seulement les clients légitimes, mais aussi l’efficacité des attaques DDoS
-
Multiplexage des flux
- HTTP/2 transmet des trames entre points de terminaison via des flux (stream), une abstraction bidirectionnelle
- Grâce au multiplexage des flux, plusieurs requêtes peuvent être traitées simultanément sur une seule connexion TCP
- La principale contrainte des attaques DoS de couche 7 est le nombre de connexions simultanées en transmission
- Chaque connexion consomme de la mémoire système pour les enregistrements de socket et les buffers
- La négociation TLS requiert du temps CPU
- Elle nécessite un 4-tuple unique composé des deux adresses IP et des deux ports
- HTTP/1.1 traite généralement les requêtes en série, si bien que le taux de requêtes par connexion unique est proche d’une requête par aller-retour réseau
- Avec HTTP/2, plusieurs flux simultanés peuvent être ouverts sur une seule connexion TCP, chaque flux correspondant à une requête HTTP
- En pratique, un client peut ouvrir 100 flux par requête et le serveur peut les traiter en parallèle, ce qui peut porter le débit utile d’une seule connexion à environ 100 requêtes par aller-retour
- En conséquence, l’utilisation d’une connexion peut devenir presque 100 fois plus élevée qu’en HTTP/1.1
Fonctionnement de Rapid Reset
- HTTP/2 permet au client d’envoyer une trame RST_STREAM pour informer le serveur de l’annulation d’un flux précédent
- L’annulation ne nécessite aucune coordination distincte entre le client et le serveur
- Le client peut annuler unilatéralement
- On peut supposer qu’un serveur recevant une trame RST_STREAM applique l’annulation avant les autres données sur la même connexion TCP
- Rapid Reset repose sur l’envoi d’une trame RST_STREAM immédiatement après l’envoi de la trame de requête
- Cela pousse l’autre extrémité à commencer le traitement puis réinitialise rapidement la requête
- La requête est annulée, mais la connexion HTTP/2 reste ouverte
- La procédure d’attaque est simple
- Comme dans une attaque HTTP/2 standard, de nombreux flux sont ouverts en une fois
- L’attaquant n’attend pas la réponse du serveur ou du proxy
- Chaque requête est annulée immédiatement
- Si cette réinitialisation immédiate est possible, chaque connexion peut en pratique maintenir un très grand nombre de requêtes à l’état en cours indéfiniment
- L’attaquant ne dépasse pas explicitement la limite des flux ouverts simultanément
- Le nombre de requêtes en cours dépend davantage de la bande passante réseau disponible que du temps d’aller-retour (RTT)
- Une implémentation classique de serveur HTTP/2 peut malgré tout devoir effectuer du travail pour des requêtes annulées
- Allocation de nouvelles structures de données de flux
- Analyse des requêtes
- Décompression des en-têtes
- Mapping des URL vers les ressources
- Dans les implémentations de reverse proxy, la requête peut être relayée vers le serveur backend avant que la trame RST_STREAM ne soit traitée
- Comme le client ne paie quasiment aucun coût pour émettre la requête, cela crée une asymétrie de coûts exploitable entre serveur et client
- Si la requête est annulée avant la rédaction de la réponse, le serveur de reverse proxy n’envoie pas de réponse, ce qui réduit aussi la bande passante descendante sortante du serveur ou du proxy vers l’attaquant
Variantes d’attaque observées
- Dans les semaines qui ont suivi le DDoS initial, des variantes de Rapid Reset ont été observées
- Ces variantes sont moins efficaces que la méthode initiale, mais peuvent rester plus efficaces que des attaques DDoS HTTP/2 standard
-
Variante d’annulation par lots
- La première variante n’annule pas immédiatement les flux ; elle ouvre un groupe de flux, attend brièvement, puis les annule en bloc
- Juste après l’annulation, elle ouvre à nouveau un nouveau grand groupe de flux pour poursuivre l’attaque
- Cette méthode peut contourner les atténuations fondées uniquement sur le taux de trames RST_STREAM entrantes
- Exemple : une politique qui n’autorise au maximum que 100 RST_STREAM par seconde et par connexion, puis ferme la connexion au-delà
- Elle n’optimise pas l’utilisation de la connexion, ce qui réduit le principal avantage de l’attaque par annulation
- Elle peut néanmoins rester plus efficace à implémenter qu’une attaque DDoS HTTP/2 standard ; une simple limitation du taux d’annulation des flux exigerait donc des seuils assez stricts
-
Variante sans annulation
- La deuxième variante n’annule aucun flux
- Elle tente à la place d’ouvrir de manière optimiste davantage de flux que le nombre simultané annoncé par le serveur
- Cela permet de maintenir en permanence le pipeline de requêtes plein et de réduire le goulot d’étranglement lié au RTT client-proxy
- Si les ressources visées sur le serveur HTTP/2 répondent immédiatement, le goulot d’étranglement RTT proxy-serveur peut aussi être éliminé
- L’actuelle RFC HTTP/2, RFC 9113, recommande d’invalider uniquement les flux dépassant la limite, et non la connexion entière, lorsqu’un pair tente d’ouvrir trop de flux
- Comme la plupart des serveurs HTTP/2 sont structurés pour ne pas traiter les flux excédentaires, ils peuvent souvent accepter et traiter presque immédiatement de nouveaux flux juste après la réponse aux flux précédents, ce qui rend cette variante sans annulation possible
Stratégies d’atténuation
- Pour cette famille d’attaques, bloquer les requêtes individuellement constitue difficilement une atténuation praticable
- Lorsqu’un abus est détecté, il faut fermer la connexion TCP entière
- HTTP/2 prend en charge la fermeture de connexion via le type de trame GOAWAY
- La RFC définit une procédure d’arrêt progressif consistant à envoyer d’abord un GOAWAY informatif ne fixant pas encore de limite d’ouverture de nouveaux flux, puis, après un aller-retour, un GOAWAY interdisant l’ouverture de flux supplémentaires
- Mais cette procédure progressive GOAWAY n’est souvent pas suffisamment robuste face à des clients malveillants
- Elle laisse la connexion exposée trop longtemps à l’attaque Rapid Reset
- Elle ne parvient pas à arrêter les requêtes entrantes
- À des fins d’atténuation, GOAWAY doit être configuré pour limiter immédiatement la création de flux
-
Identification des connexions abusives
- Le simple fait qu’un client annule des requêtes n’est pas toujours abusif
- La fonction d’annulation de HTTP/2 sert aussi à mieux gérer le traitement des requêtes
- Quand un utilisateur quitte une page et que le navigateur n’a plus besoin des ressources demandées
- Pour les applications utilisant le long polling avec des timeouts côté client
- L’atténuation se concentre donc sur le suivi des statistiques de connexion et l’évaluation de l’utilité de chaque connexion à l’aide de plusieurs signaux et de la logique métier
- Par exemple, si une connexion comporte plus de 100 requêtes et que plus de 50 % d’entre elles sont annulées, elle peut devenir candidate à une mesure d’atténuation
- L’ampleur et le type de réponse varient selon le risque propre à chaque plateforme
- Envoi forcé d’une trame GOAWAY
- Fermeture immédiate de la connexion TCP
- Pour atténuer la variante sans annulation, il est recommandé aux serveurs HTTP/2 de fermer les connexions qui dépassent la limite de flux simultanés
- Ils peuvent les fermer immédiatement
- Ou après un petit nombre de violations répétées
Applicabilité à HTTP/3
- Google ne considère pas que cette méthode d’attaque s’applique directement à HTTP/3 (QUIC), en raison des différences de protocole
- À ce stade, Google n’observe pas de cas où HTTP/3 serait utilisé comme vecteur de DDoS à grande échelle
- Il est néanmoins recommandé aux implémentations de serveurs HTTP/3 de mettre en place de manière préventive des mécanismes limitant la quantité de travail effectuée par une seule connexion de transport
- Dans un esprit similaire aux atténuations discutées pour HTTP/2
Coordination sectorielle et CVE
- Dès le début de l’enquête menée par la Google DDoS Response Team, il est apparu que ce type d’attaque pouvait avoir un impact large sur tous les services exposant HTTP/2
- Google a mené une procédure de divulgation coordonnée des vulnérabilités en s’appuyant sur un groupe de divulgation coordonnée existant
- La procédure de divulgation s’est concentrée sur l’information des principaux implémenteurs HTTP/2
- Entreprises d’infrastructure
- Fournisseurs de logiciels serveur
- L’objectif de cette notification préalable était de développer des mesures d’atténuation et de se préparer selon un calendrier de divulgation coordonné
- Par le passé, cette approche a déjà permis soit un déploiement étendu de protections chez les fournisseurs de services, soit la publication de mises à jour logicielles pour plusieurs packages et solutions
- Pendant la procédure coordonnée, CVE-2023-44487 a été réservé pour suivre les correctifs de plusieurs implémentations HTTP/2
Ce que doivent faire les opérateurs de services HTTP/2
- Cette attaque peut avoir un impact significatif sur des services de toute taille
- Tous les fournisseurs exposant des services HTTP/2 doivent évaluer leur niveau d’exposition à ce problème
- Des correctifs et mises à jour logicielles pour les serveurs web courants et les langages de programmation peuvent être disponibles dès maintenant ou dans un avenir proche
- Il est recommandé d’appliquer les correctifs fournis aussi vite que possible
- Pour les clients Google Cloud, il est recommandé d’utiliser en complément des correctifs logiciels Application Load Balancer et Google Cloud Armor
- Google Cloud Armor a protégé Google ainsi que les utilisateurs existants de Google Cloud Application Load Balancing
1 commentaires
Avis sur Hacker News
Fils en cours liés :
La plus grande attaque DDoS à ce jour, avec un pic à plus de 398 millions de requêtes par seconde - https://news.ycombinator.com/item?id=37831062
Une vulnérabilité zero-day HTTP/2 déclenche des attaques DDoS record - https://news.ycombinator.com/item?id=37830998
C’est rassurant de voir que l’équipe HAProxy semble avoir repéré et atténué ce type de problème avec HTTP/2 dès 2018 : https://www.mail-archive.com/haproxy@formilux.org/msg44134.h...
https://www.nginx.com/blog/http-2-rapid-reset-attack-impacti...
Dans une implémentation classique de serveur HTTP/2, même pour des requêtes annulées, il faut faire pas mal de travail : allouer une nouvelle structure de données de flux, parser la requête, décompresser les en-têtes, faire correspondre l’URL à une ressource, etc.
Dans une implémentation de proxy inverse, la requête peut même être transmise au serveur backend avant que la trame
RST_STREAMne soit traitée. À l’inverse, le client paie un coût quasi nul pour envoyer la requête, ce qui crée une asymétrie de coût exploitable entre serveur et client.C’est surprenant que cela n’ait pas été anticipé lors de la conception de HTTP/2. Les attaques par amplification étaient déjà bien connues dans d’autres protocoles. Il est tout aussi surprenant que cette attaque n’apparaisse que si tard, mais peut-être que, jusqu’à récemment, HTTP/2 n’était pas assez largement déployé pour constituer une cible intéressante.
RST_STREAMexistait déjà dans les premières versions de SPDY, et SPDY semble avoir été conçu globalement vers 2009.Des attaques comme Slowloris sont apparues à peu près à la même période, mais elles n’étaient pas largement connues à l’époque. En revanche, les SYN cookies ont été introduits en 1996, donc il existe clairement des précédents historiques pour les attaques où la victime paie Y et l’attaquant paie X.
La particularité, ici, c’est que quelqu’un a sérieusement essayé contre Google.
En gros, on avait besoin de HTTP/2 pour livrer plus vite les pubs, les trackers et les frameworks frontend obèses. Maintenant, il livre aussi les attaques plus vite.
Heureusement, HTTP/1.1 fonctionne toujours. Si ce protocole ne vous plaît pas, vous pouvez toujours activer HTTP/1.1 dans les paramètres du navigateur et sur le serveur web.
C’est une raison de plus de garder les protocoles de base petits. HTTP/2 existe depuis plus de dix ans si l’on inclut SPDY, et ce type d’attaque n’apparaît que maintenant.
Je me demande quelles surprises se cachent dans HTTP/3 et QUIC.
Il faudrait ajouter « annulation » à la liste des « problèmes difficiles en informatique ».
Comme les autres éléments de cette liste, par exemple les erreurs de décalage d’une unité ou l’invalidation de cache, ce n’est pas vraiment extrêmement difficile, mais c’est facile à sous-estimer et à négliger. Si l’on passait ne serait-ce que la moitié du temps consacré à la création, aux constructeurs et à l’initialisation à concevoir la destruction, le nettoyage, le démontage et l’annulation, il y aurait beaucoup moins de bugs, en particulier de bugs d’épuisement des ressources.
await, sans coopération des appels individuels, et d’annuler toute la pile d’appels avec lui.Je voudrais rappeler à tout le monde que Google est l’entreprise qui a créé HTTP/2.
Aujourd’hui, ils racontent qu’ils nous sauvent héroïquement d’un problème qu’ils ont eux-mêmes créé, sans mentionner qu’ils en sont à l’origine. Quelle impudence de la part de ces entreprises tech. Microsoft fait ça depuis des décennies.
Quelqu’un peut expliquer ce qu’il y a de nouveau dans cette attaque par rapport à une simple inondation de requêtes ?
Avec HTTP/1.1, on pouvait envoyer une requête par aller-retour[0]. Avec le multiplexage HTTP/2, on peut en envoyer 100 par aller-retour. Avec cette attaque, on peut envoyer un nombre de requêtes pratiquement illimité par aller-retour. J’espère que le schéma de l’article montre la différence, mais tu parles peut-être d’un autre type d’attaque.
[0] En tenant compte du pipelining HTTP/1.1, on peut éliminer un facteur lié à l’aller-retour, mais les clients réels utilisent très rarement le pipelining HTTP/1.1, donc son utilisation devient un signal très clair de trafic malveillant.
En envoyant à la fois des requêtes et des réinitialisations de flux dans une même connexion, on peut envoyer davantage de requêtes par connexion/client qu’auparavant, ce qui peut rendre l’attaque moins coûteuse ou plus difficile à bloquer.
L’en-tête du blog n’arrête pas de surgir et rend la page impossible à lire.