{"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\/es\/blog\/news\/uyazvimost-v-protokole-http-2-zadejstvovannaya-v-krupnejshej-ddos-atake","title":{"rendered":"Vulnerabilidad en el protocolo HTTP\/2, utilizada en el mayor ataque DDoS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La empresa Google ha registrado el mayor ataque DDoS a su infraestructura, cuya intensidad alcanz\u00f3 398 millones de solicitudes por segundo. Este nuevo ataque supera en 7 veces la intensidad del anterior ataque DDoS r\u00e9cord, en el cual los atacantes lograron generar un flujo de 47 millones de solicitudes por segundo. Para comparaci\u00f3n, todo el tr\u00e1fico de la Web se estima entre 1 y 3 mil millones de solicitudes por segundo. Adem\u00e1s de Google, las empresas Amazon y Cloudflare tambi\u00e9n se enfrentaron a este ataque. La posibilidad de un nuevo ataque est\u00e1 relacionada con la identificaci\u00f3n de una vulnerabilidad en el protocolo HTTP\/2 (CVE-2023-44487), que permite dirigir un enorme flujo de solicitudes al servidor con una carga m\u00ednima sobre el cliente. <\/p>\n

Una nueva t\u00e9cnica de ataque se ha denominado \u00abRapid Reset\u00bb y aprovecha que los medios de multiplexi\u00f3n de canales proporcionados en HTTP\/2 permiten formar un flujo de solicitudes dentro de una conexi\u00f3n ya establecida, sin abrir nuevas conexiones de red y sin esperar la confirmaci\u00f3n de recepci\u00f3n de paquetes. La vulnerabilidad se considera una consecuencia de la falta de desarrollo del protocolo HTTP\/2, en cuya especificaci\u00f3n se indica que al intentar abrir un n\u00famero excesivo de flujos, solo se deben anular los flujos que superen el l\u00edmite, pero no cerrar toda la conexi\u00f3n de red. <\/p>\n

Siguiendo el ejemplo de los m\u00e9todos de ataque utilizados anteriormente en HTTP\/2, en el nuevo ataque tambi\u00e9n se crean un gran n\u00famero de flujos dentro de una \u00fanica conexi\u00f3n. La clave de la nueva t\u00e1ctica es que, en lugar de esperar una respuesta despu\u00e9s de cada solicitud enviada, se env\u00eda un marco con la bandera RST_STREAM, cancelando inmediatamente la solicitud. Cancelar la solicitud en una etapa temprana permite evitar el tr\u00e1fico de retorno hacia el cliente y eludir las restricciones existentes en los servidores HTTP sobre el n\u00famero m\u00e1ximo de flujos que se pueden abrir simult\u00e1neamente en una sola conexi\u00f3n por HTTP\/2. De este modo, el volumen de solicitudes dirigidas al servidor HTTP deja de depender de los retrasos entre el env\u00edo de la solicitud y la recepci\u00f3n de la respuesta (RTT, tiempo de ida y vuelta) y se basa \u00fanicamente en el ancho de banda del canal de comunicaci\u00f3n.

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

Dado que para llevar a cabo un ataque del lado del cliente es suficiente enviar solicitudes sin recibir respuestas, el ataque puede realizarse con un costo m\u00ednimo. Por ejemplo, el ataque registrado por Cloudflare de 201 millones de solicitudes por segundo se llev\u00f3 a cabo con un botnet relativamente peque\u00f1o de 20,000 computadoras. Del lado servidores<\/a> los costos de procesamiento de las solicitudes entrantes son significativamente mayores, a pesar de su cancelaci\u00f3n, ya que es necesario realizar operaciones como la asignaci\u00f3n de estructuras de datos para nuevos flujos, el an\u00e1lisis de la solicitud, la descompresi\u00f3n del encabezado y la coincidencia de la URL con el recurso. En un ataque a proxies inversos, el ataque puede extenderse a los backends, ya que el proxy puede redirigir la solicitud al backend antes de procesar el marco RST_STREAM. <\/p>\n

El ataque solo puede realizarse contra servidores vulnerables que soporten HTTP\/2 (script para verificar la manifestaci\u00f3n de vulnerabilidad en servidores, herramienta para realizar el ataque). Hasta ahora no se han registrado ataques contra HTTP\/3 y la posibilidad de realizarlos no ha sido completamente analizada, pero representantes de Google recomiendan a los desarrolladores servidores<\/a> agregar medidas de protecci\u00f3n en las implementaciones de HTTP\/3, similares a las implementadas para bloquear ataques en HTTP\/2. <\/p>\n

Vulnerabilidad y disponibilidad de parches para servidores HTTP y proxies: <\/p>\n