Incidente de seguridad del Día de Acción de Gracias de 2023

Incidente de seguridad del Día de Acción de Gracias de 2023

• El 23 de noviembre de 2023, durante el Día de Acción de Gracias, Cloudflare detectó a un actor de amenazas en un servidor de Atlassian alojado por la propia empresa.
• El equipo de seguridad inició de inmediato una investigación y bloqueó el acceso del actor de amenazas.
• El 26 de noviembre, se convocó al equipo forense de CrowdStrike para realizar un análisis independiente.
• CrowdStrike completó la investigación y Cloudflare comparte los detalles del incidente de seguridad a través de esta publicación de blog.
• Se enfatiza que los datos y sistemas de los clientes de Cloudflare no se vieron afectados por este incidente.
• Gracias a los controles de acceso, las reglas de firewall y la aplicación obligatoria de llaves de seguridad físicas con herramientas de Zero Trust, la capacidad de movimiento lateral del actor de amenazas quedó limitada.

Trabajo de recuperación y fortalecimiento “Code Red”

• Después de que el actor de amenazas fue eliminado del entorno, el equipo de seguridad movilizó a todas las personas necesarias en toda la empresa para completar la investigación de la intrusión y el bloqueo de accesos.
• A partir del 27 de noviembre, se movilizó al personal técnico para concentrarse en un proyecto llamado "Code Red".
• El objetivo de este proyecto era fortalecer y verificar todos los controles del entorno para prepararse ante futuras intrusiones y evitar que el actor de amenazas pudiera volver a acceder al entorno.
• CrowdStrike realizó una evaluación independiente sobre el alcance y la magnitud de la actividad del actor de amenazas.

Línea de tiempo del ataque

• El ataque comenzó con la brecha de seguridad de Okta en octubre, y desde mediados de noviembre el actor de amenazas apuntó a los sistemas de Cloudflare usando credenciales obtenidas en esa brecha de Okta.
• El 18 de octubre, la brecha de Okta permitió que el actor de amenazas accediera a credenciales.
• A partir del 14 de noviembre, el actor de amenazas comenzó a explorar sistemas e intentar obtener acceso.
• El 15 de noviembre, logró acceder con éxito a Atlassian Jira y Confluence.
• El 16 de noviembre, creó una cuenta de usuario de Atlassian.
• Del 17 al 20 de noviembre, no accedió a los sistemas de Cloudflare.
• El 22 de noviembre, instaló Sliver Adversary Emulation Framework para mantener acceso persistente.
• El 23 de noviembre, el equipo de seguridad detectó la presencia del actor de amenazas y comenzó a bloquear su acceso.

Conclusión

• Se estima que este incidente fue obra de un atacante patrocinado por un Estado, y Cloudflare hizo grandes esfuerzos para limitar el impacto del incidente y prepararse frente a futuros ataques.
• El equipo de ingeniería de Cloudflare protegió los sistemas, entendió el acceso del actor de amenazas, resolvió las prioridades inmediatas y estableció un plan para mejorar la seguridad general.
• CrowdStrike realizó una evaluación independiente y, una vez completado el informe final, Cloudflare publicó esta entrada del blog con confianza en su análisis interno y en las medidas tomadas frente a la intrusión.

Opinión de GN⁺:

1. Este incidente resalta la importancia de la arquitectura Zero Trust de Cloudflare. Funciona limitando la propagación de amenazas a toda la organización mediante el aislamiento entre sistemas.
2. La rápida respuesta de Cloudflare y sus esfuerzos de refuerzo de seguridad a través del proyecto "Code Red" ofrecen una visión sobre cómo las empresas responden a las amenazas de ciberseguridad.
3. Este artículo sirve como un caso útil para entender cómo debe responder una organización cuando ocurre un incidente de ciberseguridad y qué medidas debe tomar.

[GN⁺]

Comentarios en Hacker News

• Por qué acciones como esta publicación de blog de Cloudflare generan confianza

  • Cloudflare no es perfecta, pero resulta confiable por su enfoque de ingeniería y su manera de responder a problemas graves.
  • Expresan agradecimiento por la publicación del blog.

• El problema de las filtraciones de datos

  • Una vez que los datos se filtran, quedan permanentemente fuera de control.
  • El refuerzo y la conversación después del incidente son importantes, pero no pueden evitar lo que ya ocurrió.

• Problemas de seguridad en los sistemas de Okta

  • Preocupación porque los sistemas de Okta hayan sido golpeados por segunda vez.

• Tokens de servicio y cuentas que no fueron rotados

  • No se rotaron porque erróneamente se creyó que no estaban en uso.
  • Se cuestiona por qué no fueron revocados por completo.

• El acceso limitado del atacante y las medidas de respuesta

  • Aunque se creía que el acceso del atacante era limitado, se tomaron medidas amplias como rotar todas las credenciales de producción, realizar análisis forense de los sistemas, y volver a crear imágenes y reiniciar.
  • El intento de acceder a los nuevos sistemas del centro de datos de Brasil fracasó, y el equipo fue devuelto al fabricante para inspección y reemplazo.

• Análisis del objetivo del atacante

  • A partir del análisis de páginas wiki, bases de datos de bugs y repositorios de código fuente, parece que buscaban información sobre la arquitectura de la red global, la seguridad y la administración de Cloudflare.

• Sorpresa por el uso de BitBucket por parte de Cloudflare

  • Expresan sorpresa de que Cloudflare use BitBucket.

• Tratamiento de credenciales no utilizadas

  • Para credenciales que se consideraban sin uso, habría sido más apropiado eliminarlas que rotarlas.

• Propuesta de rotación de credenciales y honeypot tras el incidente de Okta

  • Se propone que, después de rotar las credenciales filtradas, se use un honeypot para observar el comportamiento del atacante.

• Dudas sobre Zero Trust (ZT)

  • Señalan que poder acceder a una aplicación con un solo bearer token no encaja con la definición de Zero Trust.

Contexto: Cloudflare es una empresa que ofrece servicios de seguridad de internet y servicios distribuidos de DNS, Okta ofrece servicios de gestión de identidad y acceso. Zero Trust es un modelo de seguridad de redes que parte de no confiar por defecto en ningún usuario ni dispositivo y verificar todo.