{"id":110728,"date":"2023-10-11T03:10:14","date_gmt":"2023-10-11T01:10:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-protokole-http-2-zadejstvovannaya-v-krupnejshej-ddos-atake"},"modified":"2023-10-11T03:10:14","modified_gmt":"2023-10-11T01:10:14","slug":"uyazvimost-v-protokole-http-2-zadejstvovannaya-v-krupnejshej-ddos-atake","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/uyazvimost-v-protokole-http-2-zadejstvovannaya-v-krupnejshej-ddos-atake","title":{"rendered":"Vuln\u00e9rabilit\u00e9 dans le protocole HTTP\/2, exploit\u00e9e lors de la plus grande attaque DDoS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Google a enregistr\u00e9 la plus grande attaque DDoS sur son infrastructure, avec une intensit\u00e9 atteignant 398 millions de requ\u00eates par seconde. Cette nouvelle attaque est sept fois plus intense que l'ancienne attaque DDoS record, o\u00f9 les attaquants avaient r\u00e9ussi \u00e0 g\u00e9n\u00e9rer un flux de 47 millions de requ\u00eates par seconde. En comparaison, tout le trafic du Web est estim\u00e9 entre 1 et 3 milliards de requ\u00eates par seconde. En plus de Google, les entreprises Amazon et Cloudflare ont \u00e9galement \u00e9t\u00e9 confront\u00e9es \u00e0 cette attaque. La possibilit\u00e9 de cette nouvelle attaque est li\u00e9e \u00e0 la d\u00e9couverte d'une vuln\u00e9rabilit\u00e9 dans le protocole HTTP\/2 (CVE-2023-44487), permettant d'envoyer un immense flux de requ\u00eates au serveur avec une charge minimale du client. <\/p>\n

Une nouvelle technique d'attaque appel\u00e9e \u00ab Rapid Reset \u00bb tire parti des moyens de multiplexage des canaux de communication fournis par HTTP\/2, permettant ainsi de former un flux de requ\u00eates dans le cadre d'une connexion d\u00e9j\u00e0 \u00e9tablie, sans ouvrir de nouvelles connexions r\u00e9seau et sans attendre la confirmation de la r\u00e9ception des paquets. La vuln\u00e9rabilit\u00e9 est consid\u00e9r\u00e9e comme une cons\u00e9quence d'un manque de robustesse du protocole HTTP\/2, dont la sp\u00e9cification indique que, lorsqu'une tentative d'ouverture d'un trop grand nombre de flux est r\u00e9alis\u00e9e, seuls les flux d\u00e9passant la limite doivent \u00eatre annul\u00e9s, sans fermer toute la connexion r\u00e9seau. <\/p>\n

\u00c0 l'instar des m\u00e9thodes d'attaques pr\u00e9c\u00e9demment utilis\u00e9es sur HTTP\/2, la nouvelle attaque cr\u00e9e \u00e9galement un grand nombre de flux dans le cadre d'une seule connexion. La principale diff\u00e9rence avec la nouvelle attaque est que, au lieu d'attendre une r\u00e9ponse apr\u00e8s chaque requ\u00eate envoy\u00e9e, une trame avec le drapeau RST_STREAM est imm\u00e9diatement envoy\u00e9e, annulant la requ\u00eate. L'annulation de la requ\u00eate \u00e0 un stade pr\u00e9coce permet d'\u00e9liminer le trafic retour vers le client et de contourner les limites existantes sur les serveurs HTTP concernant le nombre maximum de flux simultan\u00e9ment ouverts dans le cadre d'une seule connexion HTTP\/2. Ainsi, dans la nouvelle attaque, le volume de requ\u00eates envoy\u00e9es au serveur HTTP ne d\u00e9pend plus des d\u00e9lais entre l'envoi de la requ\u00eate et la r\u00e9ception de la r\u00e9ponse (RTT, round-trip time) et est limit\u00e9 uniquement par la bande passante de la connexion.

\"Vuln\u00e9rabilit\u00e9<\/center> <\/p>\n

\u00c9tant donn\u00e9 que pour mener une attaque c\u00f4t\u00e9 client, il suffit d'envoyer des requ\u00eates sans recevoir de r\u00e9ponses, l'attaque peut \u00eatre r\u00e9alis\u00e9e avec des co\u00fbts op\u00e9rationnels minimaux. Par exemple, une attaque enregistr\u00e9e par Cloudflare \u00e0 201 millions de requ\u00eates par seconde a \u00e9t\u00e9 effectu\u00e9e \u00e0 l'aide d'un botnet relativement petit de 20 000 ordinateurs. Du c\u00f4t\u00e9 de serveurs<\/a> les co\u00fbts de traitement des requ\u00eates entrantes sont consid\u00e9rablement plus \u00e9lev\u00e9s, malgr\u00e9 leur annulation, car il est n\u00e9cessaire d'effectuer des op\u00e9rations telles que la cr\u00e9ation de structures de donn\u00e9es pour de nouveaux flux, l'analyse de la requ\u00eate, le d\u00e9ballage de l'en-t\u00eate et la correspondance de l'URL avec la ressource. Lors d'une attaque sur des proxies inverses, l'attaque peut se propager aux backends, car le proxy peut rediriger la requ\u00eate vers le backend avant le traitement du cadre RST_STREAM. <\/p>\n

Une attaque ne peut \u00eatre r\u00e9alis\u00e9e que sur des serveurs vuln\u00e9rables prenant en charge HTTP\/2 (script pour v\u00e9rifier la manifestation de la vuln\u00e9rabilit\u00e9 sur les serveurs, trousse \u00e0 outils pour mener l'attaque). Aucune attaque n'a encore \u00e9t\u00e9 enregistr\u00e9e pour HTTP\/3 et la possibilit\u00e9 de leur r\u00e9alisation n'a pas encore \u00e9t\u00e9 compl\u00e8tement analys\u00e9e, mais des repr\u00e9sentants de Google recommandent aux d\u00e9veloppeurs serveurs<\/a> d'ajouter dans les impl\u00e9mentations d'HTTP\/3 des mesures de protection similaires \u00e0 celles mises en place pour bloquer les attaques sur HTTP\/2. <\/p>\n

Vuln\u00e9rabilit\u00e9 et disponibilit\u00e9 des correctifs pour les serveurs HTTP et les proxies : <\/p>\n