El mayor ataque DDoS registrado alcanzó un pico de 398 millones de rps

 (cloud.google.com)
1 puntos por GN⁺ 2023-10-11 | 1 comentarios | Compartir por WhatsApp
  • Mientras el tamaño de los ataques DDoS crece rápidamente, Google mitigó en agosto de 2023 un ataque con un pico de 398 millones de rps, 7.5 veces mayor que el récord del año anterior, de 46 millones de rps
  • Los atacantes usaron la técnica Rapid Reset, que abusa de la multiplexación de streams de HTTP/2, y varias empresas de infraestructura de Internet se vieron afectadas
  • La oleada de ataques comenzó a finales de agosto de 2023 y continuó hasta septiembre; tuvo como objetivo a importantes proveedores de infraestructura, incluidos los servicios de Google, la infraestructura de Google Cloud y sus clientes
  • Google absorbió el ataque en el borde de la red y actualizó sus sistemas de defensa; los clientes de Application Load Balancer y Cloud Armor también reciben protección basada en la misma infraestructura
  • Los servidores, proxies, servidores de aplicaciones y balanceadores de carga que soportan HTTP/2 pueden verse afectados por CVE-2023-44487, por lo que es necesario verificar si son vulnerables y aplicar los parches de los proveedores

Magnitud del ataque y técnica Rapid Reset

  • El DDoS Response Team de Google observó que, en los últimos años, la magnitud de los ataques DDoS ha crecido de forma exponencial
  • El ataque bloqueado en agosto de 2023 fue 7.5 veces mayor que el récord máximo del año anterior
    • Alcanzó un pico de 398 millones de requests per second (rps)
    • El mayor ataque DDoS registrado en 2022 fue de 46 millones de rps
  • Este ataque, que duró 2 minutos, generó más solicitudes que el total de vistas de páginas reportadas por Wikipedia durante todo septiembre de 2023
  • La técnica clave fue el nuevo HTTP/2 Rapid Reset, que aprovecha la función de multiplexación de streams de HTTP/2

Objetivos del ataque e impacto en los servicios

  • La reciente oleada de ataques comenzó a finales de agosto de 2023 y siguió observándose durante septiembre
  • Entre los objetivos del ataque se incluyeron importantes proveedores de infraestructura
    • Servicios de Google
    • Infraestructura de Google Cloud
    • Clientes de Google
  • Google mantuvo sus servicios en operación mediante su infraestructura global de balanceo de carga y mitigación de DDoS
  • En colaboración con socios de la industria, identificó el mecanismo del ataque y coordinó medidas de mitigación para proteger a Google, a sus clientes y a Internet en general

Cómo mitigó Google el ataque y protección para clientes de Cloud

  • La investigación determinó que el ataque usó la técnica Rapid Reset, basada en la función de multiplexación de streams del ampliamente usado protocolo HTTP/2
  • Google mitigó el ataque en el borde de la red
    • Aprovechó sus inversiones en capacidad de borde para que los servicios de Google y los de sus clientes, en general, no se vieran afectados
    • Tras entender mejor la modalidad del ataque, desarrolló mitigaciones
    • Actualizó sus proxies y sistemas de defensa contra denegación de servicio para reducir eficazmente esta técnica
  • Application Load Balancer y Cloud Armor de Google Cloud usan la misma infraestructura de hardware y software que Google emplea para ofrecer sus propios servicios expuestos a Internet
  • Las aplicaciones web y servicios expuestos a Internet de los clientes de Cloud que usan esos servicios reciben una protección similar

CVE-2023-44487 y respuesta coordinada de la industria

  • Poco después de detectar los ataques iniciales de agosto, Google aplicó estrategias de mitigación adicionales y coordinó una respuesta conjunta de la industria con proveedores de nube y mantenedores de software que implementan stacks del protocolo HTTP/2
  • Mientras el ataque estaba en curso, compartió en tiempo real información sobre el ataque y métodos de mitigación
  • Esta colaboración derivó en parches y técnicas de mitigación usados por varios grandes proveedores de infraestructura
  • Se divulgó de forma coordinada el nuevo método de ataque y las posibles vulnerabilidades en varios proxies, servidores de aplicaciones y balanceadores de carga comunes, tanto open source como comerciales
  • La vulnerabilidad colectiva asociada con este ataque se rastrea como CVE-2023-44487
    • Su severidad es High
    • Su puntaje CVSS es 7.5/10

Quiénes pueden verse afectados y acciones necesarias

  • Las empresas o personas que ofrezcan cargas de trabajo basadas en HTTP en Internet pueden estar expuestas al riesgo de este ataque
  • Las aplicaciones web, servicios y API que se ejecutan sobre servidores o proxies capaces de comunicarse mediante HTTP/2 pueden ser vulnerables
  • Las organizaciones deben verificar que sus servidores compatibles con HTTP/2 no sean vulnerables
  • Si operan o administran servidores propios con soporte para HTTP/2, ya sean open source o comerciales, deben aplicar los parches correspondientes del proveedor tan pronto como estén disponibles
  • Los parches de proveedores para CVE-2023-44487 son una medida para limitar el impacto de este vector de ataque

Recomendaciones de defensa para entornos de Google Cloud

  • Defenderse de ataques DDoS a gran escala es difícil y, independientemente de si se aplicaron parches, mantener los servicios operativos ante ataques medianos o mayores requiere una inversión considerable en infraestructura
  • Las organizaciones que operan servicios en Google Cloud pueden aprovechar las inversiones de capacidad a escala global de Cross-Cloud Network para ofrecer y proteger sus aplicaciones
  • Los clientes de Google Cloud que exponen sus servicios mediante un Application Load Balancer global o regional están protegidos por Cloud Armor always-on DDoS protection
    • Los ataques que explotan vulnerabilidades como CVE-2023-44487 se mitigan rápidamente
  • Aunque Cloud Armor always-on DDoS protection puede absorber en el borde de la red de Google la mayor parte de cientos de millones de solicitudes por segundo, aún pueden pasar millones de solicitudes no deseadas por segundo
  • Para responder a ataques de Layer 7, se recomienda desplegar custom security policies de Cloud Armor, reglas proactivas de rate limiting y Adaptive Protection basado en IA
  • La información técnica sobre la oleada actual de ataques DDoS está disponible en Análisis del ataque DDoS HTTP/2 Rapid Reset

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-10-11
Opiniones en Hacker News
  • Hilos relacionados en curso:
    The novel HTTP/2 'Rapid Reset' DDoS attack - https://news.ycombinator.com/item?id=37830987
    HTTP/2 Zero-Day Vulnerability Results in Record-Breaking DDoS Attacks - https://news.ycombinator.com/item?id=37830998
  • Me pregunto quién tendría incentivos para ejecutar este tipo de ataques DDoS. No veo muy claro por qué alguien asumiría el costo de mucho dinero y de desarrollar un ataque sofisticado contra infraestructura cloud empresarial; la respuesta más razonable parece ser algún gobierno extranjero.
    Aun así, si el resultado apenas es incomodar durante unas horas a empresas tecnológicas estadounidenses y a sus clientes, no entiendo bien por qué siguen ocurriendo.
    • Llevo unos 20 años en defensa contra DDoS, y la respuesta es que a veces son actores estatales, pero muchas veces también son estafadores de Europa del Este. Lanzan ataques grandes para ganar reputación en comunidades de bots.
      Con esa reputación, cobran a clientes poco limpios que quieren atacar a competidores; a veces ese cliente es un gobierno y a veces una empresa sospechosa. El año pasado hubo muchos casos de empresas de criptomonedas atacándose los sitios web entre sí.
      Quienes hacen estas cosas suelen tener mucha habilidad técnica, pero por el lugar donde viven o el entorno en el que crecieron, muchas veces tienen pocas oportunidades de ganar dinero con esas habilidades.
    • Es por publicidad. Atacan a Google o Cloudflare, esperan a que publiquen un post de “el mayor ataque de la historia” y luego les dicen a clientes potenciales que su botnet puede hacer ataques más grandes que nadie, usando ese post como prueba.
    • Si el atacante es inexperto, el objetivo es presumir y ganar reputación en comunidades de hacking; no es muy distinto de dejar grafiti en un paso elevado de una autopista.
      Si el atacante es avanzado, está probando capacidades y respuestas. Los Taliban antes les pagaban a niños para que detonaran petardos afuera de las bases y así observar las tácticas, técnicas y procedimientos defensivos; además, eso ayudaba a que la gente se insensibilizara a los disparos.
      Un adversario realmente bueno sabe hacer lo segundo mientras parece estar haciendo lo primero.
    • Aunque es información vieja, antes se podía pagarle unos cientos de dólares al dueño de una botnet para molestar el servidor de alguien que no te caía bien. Por ejemplo, arruinar una partida de un clan rival en un juego competitivo. Hay una cantidad sorprendente de mezquindades así en el mundo.
      En el caso de la botnet Mirai, algunos de sus creadores también operaban una empresa de mitigación de DDoS. Es decir, vendían el arma por un lado y, por el otro, la defensa contra esa arma.
      A veces el motivo también es la reputación, la broma o el desafío en sí de crear una botnet.
    • En ataques masivos similares recientes, los autores del software de la botnet venían de una empresa de seguridad estadounidense que vendía soluciones de mitigación de DDoS (https://en.wikipedia.org/wiki/Mirai_(malware)).
  • En una empresa anterior recibíamos ataques de una escala mucho menor con bastante frecuencia. Internamente asumíamos que era un competidor intentando perjudicarnos, pero al final quedó como un misterio.
    Ya sea a escala de infraestructura de Internet o dirigido a una empresa específica, me pregunto si alguien que haya participado en este tipo de ataques sería lo bastante valiente o loco como para crear una cuenta temporal y contar sus motivaciones.
    • Me pasó algo parecido, y al principio pensé que eran script kiddies haciéndolo por diversión. Resultó que alguien había escrito un microservicio muy malo, y una consulta ineficiente de vez en cuando disparaba todas las alertas.
    • Una empresa local de hosting atacaba con DDoS a negocios locales que tenían infraestructura de IT y luego publicitaba su propia solución de hosting con protección contra DDoS incluida.
    • Universidades suecas fueron atacadas por “Turkey” después de una gran controversia por la quema del Corán. Incluso presumían de ello con una cuenta de Twitter, pero parecía bastante claro que era Rusia.
    • He oído que también hay ataques donde el objetivo es un subsistema. Atacan toda la red para no llamar la atención.
    • Un cliente fue víctima de DDoS por parte de sus competidores, aunque es muy probable que esos competidores no supieran que estaban haciendo DDoS. Raspaban sus listados de productos de forma muy agresiva, sin ninguna demora ni limitación de velocidad, y eso terminó convirtiéndose en un DDoS.
      No intentaban volver lento el sitio objetivo, pero sí estaban tratando de extraer datos a una velocidad en la que los costos de servidor para un cliente real de pago se volvían insostenibles.
      Este tipo de ataque es distinto de un DDoS real, pero según mi experiencia es mucho más común, y puede mitigarse relativamente fácil con algo como Cloudflare o Akamai, así que suelo recomendárselo a los clientes.
  • Cloudflare también sufrió el mismo ataque: https://blog.cloudflare.com/zero-day-rapid-reset-http2-recor...
  • Me parece interesante la parte que dice que “Google y AWS también estaban viendo este ataque al mismo tiempo”. Si hay alguien que trabaje a ese nivel en los principales proveedores, me da curiosidad saber qué pasa realmente durante un ataque de esta escala.
    Me pregunto si la gente de Cloudflare, Google y AWS entra en una videollamada en tiempo real para coordinarse y mitigarlo, o si cada uno observa de lejos lo que pasa en otros lugares mientras se concentra en resolver su propio problema.
    • Normalmente cada uno apaga su propio incendio, pero si alguien ve algo interesante o nuevo, después de apagarlo suele preguntar si otros vieron ataques similares. Podría tratarse de una botnet nueva, un método de ataque nuevo, etc.
      Esta vez se dieron cuenta de que todos estaban viendo lo mismo y, como el impacto podía ser muy grande para objetivos más pequeños, trabajaron juntos para entender el problema y coordinar la respuesta de seguridad con todos los proveedores de servidores web.
  • Me pregunto cómo funciona la mitigación de DDoS. ¿Qué significa exactamente “poner un sitio web detrás de Cloudflare para mitigar DDoS”?
    ¿Es simplemente contar con suficiente ancho de banda entrante para aguantar varios Gb/s y dejar capacidad sobrante para el tráfico legítimo?
    • Eso forma parte, pero hay muchos más elementos. Normalmente necesitas poder aumentar dinámicamente el ancho de banda y los recursos de cómputo para absorber la inundación entrante.

Mucho tráfico DDoS no es HTTP real, sino tráfico basura que llena la tubería hacia direcciones IP. Ayudan tuberías más grandes y varios servidores distribuidos geográficamente. También hay casos como las inundaciones TCP SYN, que solo abren conexiones TCP hasta agotar los puertos disponibles. A menudo estas solicitudes anómalas pueden manejarse con varios proxies inversos simples delante del servidor
Las consultas más sofisticadas, que en apariencia envían tráfico HTTP normal, al final hay que procesarlas. Puede ser respondiendo desde caché, poniendo un CAPTCHA para ralentizar a los atacantes e identificar el tráfico normal, o aplicando límites de velocidad. Lo que quieres es determinar si una solicitud es legítima antes de pasarla al servidor real, y para eso puedes desplegar varias herramientas

  • Cloudflare y otras empresas pueden detectar si una solicitud es tráfico DDoS y, en lugar de enviarla al servidor, descartarla, limitarla o verificarla
    El servidor solo tiene que configurarse para descartar todo lo que no sea tráfico enviado por Cloudflare, y este enfoque es eficiente
  • Cuando estaba en Google SRE, la gente solía bromear diciendo que “el tráfico DDoS simplemente se manda a Australia”
    En general, el tráfico entre los centros de datos internos de Google es mucho mayor que la cantidad que alguien podría enviar como DDoS, así que siempre se puede encontrar una forma de manejarlo
  • Si el ataque DDoS es basado en capacidad, la única forma de mitigarlo es tener una red lo suficientemente gruesa para procesar el tráfico y colaborar con los ISP para empezar a bloquearlo aguas arriba
    Pero no todos los DDoS están basados en capacidad. Algunos abusan de funciones básicas del protocolo, como los ataques slow loris
    https://www.cloudflare.com/learning/ddos/ddos-attack-tools/s...
  • La mitigación de la que se habla normalmente significa reconocer automáticamente las solicitudes DDoS y procesarlas a menor costo sin afectar a los usuarios legítimos
    En este caso, podría ser detectar si el cliente restablece rápidamente los streams y mandar ese tráfico a un carril lento o filtrarlo por completo
  • En este artículo hay enlaces a más información sobre la función HTTP/2 Rapid Reset usada como parte del DDoS: https://cloud.google.com/blog/products/identity-security/how...
  • ¿No se menciona el origen de este ataque? Parece que requeriría una cantidad enorme de hardware y, si no es alguna botnet, parecería fácil de rastrear
    • La noticia especialmente mala es que este ataque realmente no requiere una botnet gigantesca
      https://blog.cloudflare.com/zero-day-rapid-reset-http2-recor...
      “Un punto clave sobre el ataque récord es que participó una botnet de tamaño medio, compuesta por unas 20,000 máquinas”
    • Dada la escala, revelar el origen podría ser política y legalmente delicado
    • La conjetura inmediata es que lo está haciendo Irán. Ya lo ha hecho varias veces antes y es aliado de Hamas. No he visto pruebas, pero parece una suposición bastante segura
  • ¿No podría Cloudflare mostrar a las siguientes solicitudes HTTP de esa IP una página que diga “algo en tu red está participando en un ataque DDoS”?
    Me imagino que todos los grandes proveedores podrían hacer esto e insertar una pequeña página tipo Turnstile antes del siguiente sitio de Cloudflare que visites
    Si hay un dispositivo infectado en mi red, me gustaría saberlo, y ahora mismo no tengo monitoreo real para detectarlo. No es una solución completa, pero al menos avisarle al usuario que hay un problema sería un buen comienzo
    • Buena idea. Podríamos volver a la era previa a HTTPS, cuando los ISP insertaban anuncios en el HTML. Esta vez estaríamos normalizando que lo hagan los proveedores de CDN
    • En la era de CGNAT, no es una buena idea
  • Blog de Cloudflare: https://blog.cloudflare.com/zero-day-rapid-reset-http2-recor...