{"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\/pt\/blog\/news\/uyazvimost-v-protokole-http-2-zadejstvovannaya-v-krupnejshej-ddos-atake","title":{"rendered":"Vulnerabilidade no protocolo HTTP\/2, utilizada no maior ataque DDoS da hist\u00f3ria","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

A Google registrou o maior ataque DDoS em sua infraestrutura, com uma intensidade de 398 milh\u00f5es de solicita\u00e7\u00f5es por segundo. O novo ataque supera em 7 vezes a intensidade do ataque DDoS recorde anterior, onde os invasores conseguiram criar um fluxo de 47 milh\u00f5es de solicita\u00e7\u00f5es por segundo. Para compara\u00e7\u00e3o, todo o tr\u00e1fego da Web \u00e9 avaliado em 1 a 3 bilh\u00f5es de solicita\u00e7\u00f5es por segundo. Al\u00e9m do Google, empresas como Amazon e Cloudflare tamb\u00e9m enfrentaram o ataque. A possibilidade de um novo ataque est\u00e1 relacionada \u00e0 descoberta de uma vulnerabilidade no protocolo HTTP\/2 (CVE-2023-44487), que permite, com uma carga m\u00ednima no cliente, direcionar um enorme fluxo de solicita\u00e7\u00f5es ao servidor. <\/p>\n

Uma nova t\u00e9cnica de ataque chamada «Rapid Reset» explora as capacidades de multiplexa\u00e7\u00e3o de canais em HTTP\/2, permitindo a forma\u00e7\u00e3o de um fluxo de solicita\u00e7\u00f5es dentro de uma conex\u00e3o j\u00e1 estabelecida, sem a necessidade de abrir novas conex\u00f5es de rede e sem aguardar a confirma\u00e7\u00e3o do recebimento dos pacotes. A vulnerabilidade \u00e9 considerada um resultado de falhas na especifica\u00e7\u00e3o do protocolo HTTP\/2, que indica que, ao tentar abrir um n\u00famero excessivo de fluxos, apenas os que excedem o limite devem ser anulados, sem fechar toda a conex\u00e3o de rede. <\/p>\n

De maneira semelhante aos m\u00e9todos de ataque anteriores realizados no HTTP\/2, o novo ataque tamb\u00e9m cria um grande n\u00famero de fluxos dentro de uma \u00fanica conex\u00e3o. A principal diferen\u00e7a \u00e9 que, em vez de aguardar uma resposta ap\u00f3s cada solicita\u00e7\u00e3o enviada, um quadro com o sinalizador RST_STREAM \u00e9 enviado imediatamente ap\u00f3s cada solicita\u00e7\u00e3o, cancelando a requisi\u00e7\u00e3o. O cancelamento da solicita\u00e7\u00e3o em um est\u00e1gio inicial ajuda a evitar o tr\u00e1fego de retorno em dire\u00e7\u00e3o ao cliente e a contornar as limita\u00e7\u00f5es existentes nos servidores HTTP sobre o n\u00famero m\u00e1ximo de fluxos que podem ser abertos simultaneamente dentro de uma \u00fanica conex\u00e3o HTTP\/2. Assim, no novo ataque, o volume de solicita\u00e7\u00f5es direcionadas ao servidor HTTP n\u00e3o depende mais das lat\u00eancias entre o envio da solicita\u00e7\u00e3o e o recebimento da resposta (RTT, round-trip time), mas apenas da largura de banda do canal de comunica\u00e7\u00e3o.

\"Vulnerabilidade<\/center> <\/p>\n

Como o ataque na lado do cliente pode ser realizado simplesmente enviando solicita\u00e7\u00f5es sem receber respostas, o ataque pode ser realizado com custos m\u00ednimos. Por exemplo, um ataque registrado pela Cloudflare, de 201 milh\u00f5es de solicita\u00e7\u00f5es por segundo, foi realizado com um botnet relativamente pequeno de 20 mil computadores. No lado servidor<\/a> os custos para processar as solicita\u00e7\u00f5es recebidas s\u00e3o significativamente mais altos, apesar de seu cancelamento, pois \u00e9 necess\u00e1rio realizar opera\u00e7\u00f5es como aloca\u00e7\u00e3o de estruturas de dados para novos fluxos, an\u00e1lise da solicita\u00e7\u00e3o, descompacta\u00e7\u00e3o do cabe\u00e7alho e correspond\u00eancia de URL com o recurso. Em um ataque a proxies reversos, o ataque pode se espalhar para os backends, j\u00e1 que o proxy pode redirecionar a solicita\u00e7\u00e3o para o backend antes do processamento do quadro RST_STREAM. <\/p>\n

Um ataque pode ser realizado apenas em servidores vulner\u00e1veis que suportam HTTP\/2 (script para verificar a manifesta\u00e7\u00e3o da vulnerabilidade em servidores, conjunto de ferramentas para realizar o ataque). No caso do HTTP\/3, ataques ainda n\u00e3o foram registrados e a possibilidade de sua realiza\u00e7\u00e3o n\u00e3o foi totalmente analisada, mas representantes do Google recomendam que os desenvolvedores servidores<\/a> adicionem \u00e0 implementa\u00e7\u00e3o do HTTP\/3 medidas de prote\u00e7\u00e3o semelhantes \u00e0s implementadas para bloquear ataques ao HTTP\/2. <\/p>\n

Susceptibilidade \u00e0 vulnerabilidade e disponibilidade de corre\u00e7\u00f5es para servidores HTTP e proxies: <\/p>\n