Regarder de plus près les mécanismes d'attaque
Le 10 octobre, Google et Cloudflare ont publié des rapports concernant l'utilisation abusive d'une fonctionnalité spécifique du protocole HTTP/2, entraînant une augmentation de la charge et un risque de déni de service sur les serveurs qui ne peuvent pas répondre à un grand nombre de requêtes simultanées.
Leurs rapports décrivent en détail un scénario dans lequel un acteur peut contourner les restrictions mises en place pour limiter le nombre de demandes simultanées qui arrivent sur un serveur HTTP/2 (pour chaque client) en annulant une demande juste après qu'elle a été faite, réinitialisant ainsi le compteur de demandes interne pour chaque demande d'annulation. Cela signifie que l'acteur peut alors spammer à l'infini de nouvelles demandes au serveur sans atteindre ces limites.
Un serveur web bien optimisé où le service HTTP/2 est en interface directe avec le client et où aucune donnée externe n'est récupérée via la logique métier (c'est-à-dire un serveur qui ne transfère pas les requêtes à un autre serveur ou qui ne les transmet pas par proxy) verra certainement une certaine augmentation de l'utilisation, mais rien que le serveur ne soit pas en mesure de gérer. Le problème devient plus évident lorsque le serveur HTTP/2 tente d'acheminer chaque demande par proxy via une connexion réseau (comme un serveur Nginx acheminant des connexions par proxy vers un service API fonctionnant sur Apache).
Dans ce scénario, les données de la requête doivent être mises en mémoire tampon par le proxy, puis envoyées à un service backend ; ce service backend doit ensuite traiter ces données et renvoyer la réponse au serveur HTTP/2. Pendant ce temps, en attendant ces réponses proxy, plusieurs zones du processus en cours peuvent utiliser de la mémoire et des ressources qui n'ont pas encore été nettoyées.
En bref, un client envoie une requête HTTP/2 valide, le serveur HTTP/2 analyse cette requête, l'envoie à un serveur dorsal et attend une réponse. Cependant, le client annule immédiatement cette demande, de sorte que le serveur HTTP2 doit également annuler la demande au serveur dorsal, mais à ce moment-là, les données et les ressources ont déjà été allouées et utilisées. Et comme le compteur de requêtes maximales est continuellement remis à zéro, un nombre infini de requêtes peuvent arriver sans que rien ne les arrête.
C'est le blog de Google qui en parle le mieux :
"...le client peut ouvrir 100 flux et envoyer une requête sur chacun d'entre eux en un seul aller-retour ; le mandataire lira et traitera chaque flux en série, mais les requêtes adressées aux serveurs dorsaux peuvent à nouveau être parallélisées. Le client peut alors ouvrir de nouveaux flux au fur et à mesure qu'il reçoit des réponses aux flux précédents. Cela donne un débit effectif pour une seule connexion de 100 demandes par aller-retour, avec des constantes de temps similaires à celles des demandes HTTP/1.1. Cela conduit généralement à une utilisation presque 100 fois plus élevée de chaque connexion."
Baptisée à juste titre HTTP/2 "Rapid Reset Attack" (basée sur le fait que les clients réinitialisent chaque requête sortante), les méthodes décrites affectent techniquement toute implémentation de HTTP/2, ce qui signifie qu'il ne s'agit pas d'une faiblesse spécifique à un fournisseur ou à un produit, mais d'une faiblesse dans le protocole lui-même. Et tout produit qui supporte HTTP/2 (actuellement) est susceptible de subir cette attaque.
En bref, cette attaque exerce une forte pression entre les serveurs frontaux et les serveurs dorsaux avec lesquels ils communiquent, comme dans les environnements fortement proxifiés. C'est la raison pour laquelle la plupart des rapports sur cette attaque proviennent de fournisseurs de services qui s'occupent beaucoup d'équilibrage de charge et de proxys HTTP, comme Cloudflare et Google.
Ce que voit Censys
Censys peut déterminer si un service HTTP peut accepter et traiter des requêtes HTTP/2 entrantes, mais ne dispose d'aucune information supplémentaire sur l'implémentation sous-jacente en dehors de ce que les serveurs HTTP nous indiquent comme étant en cours d'exécution (par exemple, un en-tête de serveur qui nous indique qu'il s'agit d'Apache ou de Nginx). Il n'existe pas de correctifs concrets ou de solutions de contournement à l'heure où nous écrivons ces lignes. Si nous devions deviner, il ne s'agirait pas d'un changement dans le protocole sous-jacent mais d'une solution de contournement dans les implémentations du protocole elles-mêmes. Dans les deux cas, les implémentations du protocole HTTP/2 seront modifiées et les propriétaires d'hôtes devront mettre à jour leurs serveurs.
Étant donné que le protocole HTTP2 ne comporte pas de version ou d'identification sémantique spécifique, même si une solution de contournement ou un correctif est mis en place, Censys sera toujours en mesure d'identifier si le protocole HTTP/2 est pris en charge ou non.
Au 10 octobre 2023, Censys a observé 556,3 millions d'hôtes utilisant 719,8 millions de serveurs HTTP/2. Il convient de noter que ce chiffre inclut les serveurs HTTP ayant la possibilité de passer à HTTP/2, mais pas nécessairement tous ceux qui l'exécutent actuellement.
