Hoy temprano, Cloudflare, Google y Amazon AWS, divulgaron la existencia de una nueva vulnerabilidad zero-day que se conoce como ataque “HTTP/2 Rapid Reset”. Este ataque aprovecha un punto débil en el protocolo HTTP/2 para generar enormes ataques hipervolumétricos por denegación de servicio distribuido (DDoS). Cloudflare ha mitigado un aluvión de estos ataques en los últimos meses, incluso uno tres veces más grande que cualquier ataque anterior que hayamos observado, que superó las 201 millones de solicitudes por segundo (rps). Desde fines de agosto de 2023, Cloudflare ha mitigado otros más de 1100 ataques con más de 10 millones de rps — y 184 ataques fueron de una magnitud mayor a nuestro récord de ataques DDoS previos de 71 millones de rps.
¿Estás siendo blanco de un ataque o necesitas mayor protección? Si necesitas ayuda, haz clic aquí.
Este zero-day brindó a los ciberdelincuentes una nueva herramienta fundamental en su navaja suiza de vulnerabilidades para aprovecharse de sus víctimas y atacarlas a una magnitud que nunca habíamos visto. Si bien a veces estos ataques son complejos y difíciles de combatir, brindaron a Cloudflare la oportunidad de desarrollar tecnología con el propósito de mitigar los efectos de la vulnerabilidad zero-day.
Si utilizas Cloudflare para la mitigación de HTTP DDoS, estás protegido. A continuación, incluimos más información sobre esta vulnerabilidad, recursos y recomendaciones sobre lo que puedes hacer para protegerte.
Deconstrucción del ataque: qué deben saber los directores de seguridad (CSO)
A fines de agosto de 2023, nuestro equipo de Cloudflare advirtió una nueva vulnerabilidad zero-day desarrollada por un ciberdelincuente desconocido que aprovecha los puntos débiles del protocolo HTTP/2 — un protocolo fundamental para que funcionen Internet y todos los sitios web. Este nuevo ataque de la vulnerabilidad zero-day, conocido como Rapid Reset, aprovecha la función de cancelación de flujo de HTTP/2 al enviar una solicitud y cancelarla de inmediato, y haciéndolo una y otro vez.
Al automatizar este simple patrón “solicitar, cancelar, solicitar, cancelar” a escala, los ciberdelincuentes pueden generar una denegación de servicio y provocar la caída de cualquier servidor o aplicación ejecutando la implementación estándar de HTTP/2. Además, un aspecto fundamental que se debe tener en cuenta con respecto a este ataque sin precedentes es que utilizó un botnet de tamaño mediano, de aproximadamente 20 000 máquinas. Cloudflare periódicamente detecta botnets que son órdenes de magnitud mayores que esto — que incluye cientos de miles e incluso millones de máquinas. Que un botnet relativamente pequeño genere un volumen tan grande de solicitudes, con la posibilidad de inhabilitar casi todos los servidores o aplicaciones que admiten HTTP/2, indica lo amenazante que resulta esta vulnerabilidad para las redes que no están protegidas.
Los ciberdelincuetes utilizaron botnets en tándem con la vulnerabilidad HTTP/2 para amplificar las solicitudes a un ritmo que nunca habíamos visto antes. A raíz de esto, nuestro equipo de Cloudflare sufrió una inestabilidad intermitente en el perímetro. Si bien nuestros sistemas pudieron mitigar la abrumadora mayoría de ataques entrantes, el volumen sobrecargó algunos componentes de nuestra red, y afectó el rendimiento de una pequeña cantidad de clientes con errores 4xx y 5xx intermitentes — los cuales fueron resueltos en su totalidad.
Una vez que mitigamos con éxito estos problemas y detuvimos los potenciales ataques a todos los clientes, nuestro equipo lanzó de inmediato un proceso de divulgación responsable. Iniciamos conversaciones con nuestros pares de la industria para analizar de qué manera podíamos trabajar juntos para proteger el gran porcentaje de Internet que depende de nuestra red antes de divulgar esta vulnerabilidad al público en general.
Cubrimos la información técnica del ataque de manera más detallada en la publicación de un blog por separado: HTTP/2 Rapid Reset: deconstrucción de un ataque sin precedentes.
¿Cómo Cloudflare y la industria están combatiendo este ataque?
No existe algo como una "divulgación perfecta". Combatir ataques y responder a los incidentes que surgen exige que las organizaciones y los equipos de seguridad asuman que siempre existe la posibilidad de una filtración — porque siempre habrá otro zero-day, y siempre surgen nuevas técnicas y nuevos ciberdelincuentes, y nuevas técnicas y ataques que nunca antes se habían registrado.
Esta idea de que siempre existe la posibilidad de potenciales ataques es la clave para compartir información y asegurar de que en instancias como esta Internet seguirá siendo segura. Mientras Cloudflare estaba sufriendo y mitigando estos ataques, también trabajábamos con socios de la industria para garantizar que todo el sector pudiera resistir este ataque.
Durante el proceso de mitigación de este ataque, nuestro equipo de Cloudflare desarrolló una nueva tecnología para detener estos ataques DDoS y mejorar nuestras propias mitigaciones tanto para este como para otros ataques de escala masiva. Estas iniciativas han aumentado de manera significativa nuestra resiliencia y nuestras capacidades de mitigación general. Si estás usando Cloudflare, estamos seguros de que estás protegido.
Nuestro equipo también alertó a los socios de software del servidor web que está desarrollando parches para garantizar que esta vulnerabilidad no sea aprovechada — revisa sus sitios web para obtener más información.
Las divulgaciones nunca ocurren una única vez. La esencia de Cloudflare es garantizar un mejor servicio de Internet, que proviene de hechos como estos. Cuando tenemos la oportunidad de trabajar con nuestros socios de la industria y con los gobiernos para garantizar que no se extienda el impacto en Internet, estamos haciendo lo que nos corresponde para mejorar la resiliencia informática de cada organización, independientemente de la magnitud o la verticalidad.
Para comprender mejor las tácticas de mitigación y los próximos pasos sobre el parcheado, inscríbete en nuestro seminario web.
¿Cuáles son los orígenes de HTTP/2 Rapid Reset y estos ataques sin precedentes sobre Cloudflare?
Puede parecer extraño que Cloudflare haya sido una de las primeras empresas que vieron estos ataques. ¿Por qué los ciberdelincuentes atacarían a una empresa que tiene una de las defensas más sólidas del mundo contra los ataques DDoS?
La realidad es que Cloudflare suele ver los ataques antes de que se dirijan a objetivos más vulnerables. Los ciberdelincuentes necesitan desarrollar y probar sus herramientas antes de implementarlas en toda la red. A los ciberdelincuentes que utilizan métodos de ataques sin precedentes les puede resultar sumamente difícil probar y entender la magnitud y la efectividad de estos, porque no tienen la infraestructura para absorber los ataques que están lanzando. Debido a la transparencia que compartimos sobre nuestro rendimiento en la red y las mediciones de los ataques que podrían recopilar de nuestros gráficos públicos sobre rendimiento, este ciberdelincuente probablemente estaba usándonos como objetivo para comprender las capacidades del ataque.
Pero esa prueba, y la capacidad para ver el ataque en una fase temprana, nos ayuda a desarrollar mitigaciones para el ataque que benefician tanto a nuestros clientes como a la industria en general.
De director de seguridad a director de seguridad: ¿Qué deberías hacer?
Hace más de 20 años que soy director de seguridad, y he recibido incontables divulgaciones y anuncios como este. Pero independientemente de si se trataba de Log4J, Solarwinds, EternalBlue WannaCry/NotPetya, Heartbleed o Shellshock, todos estos incidentes de seguridad tenían aspectos en común. Una tremenda explosión que se multiplica en todo el mundo y crea la ocasión para interrumpir por completo cualquiera de las organizaciones que he dirigido — independientemente de la industria o de la magnitud.
Muchos de estos fueron ataques o vulnerabilidades que podríamos haber no controlado. Pero independientemente de si el problema surgió de algo que estaba bajo mi control o no, lo que ha distinguido las iniciativas exitosas que he dirigido de las que no estaban a nuestro favor fue la capacidad para responder cuando vulnerabilidades zero-day y ataques como este son identificados.
Si bien desearía poder decir que Rapid Reset puede ser diferente esta vez, no lo es. Esta vez, apelo a todos los directores de seguridad — independientemente de si han visto los incidentes de seguridad que yo he visto durante décadas o si se trata de alguien en su primer día en el trabajo — para garantizar que estén protegidos y respalden a sus equipos de respuesta de incidentes informáticos.
Hemos mantenido la información reservada hasta hoy para dar a todos los proveedores de seguridad la oportunidad de reaccionar. Sin embargo, en algún punto, tenemos la responsabilidad de hacer públicas las amenazas zero-day como esta. Hoy es ese día. Esto significa que después de hoy, los ciberdelincuentes estarán muy al tanto de la vulnerabilidad HTTP/2; e inevitablemente se convertirá en algo simple para aprovechar y lanzar la carrera entre defensores y atacantes — crear parches primero frente a aprovechar primero. Las organizaciones deberían suponer que los sistemas serán probados y tomar medidas preventivas para garantizar la protección.
Para mí, esto es algo parecido a una vulnerabilidad como Log4J, debido a la cantidad de variantes que están surgiendo diariamente, y seguiremos obteniendo resultados en las semanas, meses y años venideros. A medida que investigadores y ciberdelincuentes experimenten con esta vulnerabilidad, podemos descubrir diferentes variantes con ciclos de aprovechamiento aún más cortos que contienen aún más atajos avanzados.
Y al igual que con Log4J, gestionar incidentes como este no es tan simple como “ejecutar el parche y listo”. Debes convertir la gestión del incidente, el parcheo y la evolución de las protecciones de seguridad en procesos constantes — porque los parches para cada variante de una vulnerabilidad reducen el riesgo, pero no lo eliminan.
No quiero ser alarmista, pero voy a ser directo: esto es algo que se debe tomar muy en serio. Esto se debe tratar como un incidente completamente activo para garantizar que no ocurra nada en sus organizaciones.
Recomendaciones para un nuevo estándar de cambio
Si bien ningún evento de seguridad es idéntico al siguiente, se pueden aprender lecciones. A los directores de seguridad, les sugiero implementar de inmediato mis recomendaciones. No solo en esta instancia, sino también para el futuro:
Comprender su conectividad externa y la conectividad externa de la red de sus socios para solucionar los sistemas conectados a Internet con las siguientes mitigaciones.
Comprender su protección de seguridad actual y las capacidades que tienen que proteger, detectar un ataque y responder a este, y solucionar de inmediato los problemas que tienen en la red.
Garantizar que su protección DDoS esté fuera de sus centro de datos, porque si el tráfico llega a sus centros de datos, resultará difícil mitigar el ataque DDoS.
Garantizar que tienen protección contra DDoS para aplicaciones (capa 7) y garantizar que tienen firewall para aplicaciones web. Además, como práctica recomendada, garantizar que tienen protección DDoS total para DNS y firewalls para el tráfico de red (capa 3) y API
Garantizar que el servidor web y los parches del sistema operativo están implementados en todos los servidores web conectados a Internet. Además, garantizar que toda la automatización como las estructuras e imágenes Terraform estén completamente parcheadas para que las versiones anteriores de servidores web no se implementen sobre las imágenes seguras por accidente.
Como último recurso, consideren desactivar HTTP/2 y HTTP/3 (probablemente también vulnerable) para mitigar la amenaza. Esto solo debe hacerse como último recurso, porque habrá problemas significativos de rendimiento si bajan de nivel a HTTP/1.1
Consideren un proveedor secundario de DDoS L7 en la nube en el perímetro para lograr resiliencia.
La misión de Cloudflare es ayudar a mejorar el servicio de Internet para todos. Si te preocupa el estado actual de tu protección DDoS, nos complace ofrecerte de manera gratuita nuestras capacidades y resiliencia para DDoS para que puedas mitigar los intentos de un ataque DDoS. Sabemos la tensión por la que estás atravesando, ya que hemos estado luchando contra estos ataques durante los últimos 30 días y hemos hecho que nuestros sistemas, los mejores en su tipo, sean aún mejores.
Si necesitas más información, mira nuestro seminario web con los detalles de zero-day y cómo responder. Comunícate con nosotros si no estás seguro si estás protegido o quieres saber cómo estarlo. También tenemos más información técnica del ataque con más detalles en la publicación de otro blog: HTTP/2 Rapid Reset: deconstrucción de un ataque sin precedentes. Por último, si estás siendo objetivo del ataque o necesitas protección inmediata, comunícate con tu representante local de Cloudflare o visita https://www.cloudflare.com/under-attack-hotline/.