Cloudflare ha revelado que sus sistemas se vieron comprometidos el Día de Acción de Gracias del año pasado, lo que provocó que los actores de amenazas accedieran al código fuente. El proveedor de servicios de TI cree que el ataque, que tuvo lugar el 23 de noviembre de 2023, fue perpetrado por un actor estatal, que utilizó credenciales robadas durante una violación del especialista en gestión de identidad y acceso (IAM), Okta. Cloudflare admitió que «no pudo rotar» sus credenciales que fueron robadas durante la violación de Okta. Ningún sistema o dato del cliente se vio afectado durante el incidente, lo que Cloudflare atribuyó a que su entorno de confianza cero limitaba la capacidad del actor de amenazas para moverse lateralmente. El ataque se detuvo el 24 de noviembre y se cancelaron todos los accesos y conexiones de los actores de la amenaza. Tras un análisis independiente realizado por Crowdstrike, Cloudflare proporcionó detalles del incidente en un blog publicado el 1 de febrero de 2024. ¿Cómo se vieron comprometidos los sistemas de Cloudflare? Durante la infracción de Okta el 18 de octubre de 2023, los atacantes robaron un token de servicio y tres credenciales de cuenta de servicio pertenecientes a Cloudflare. Estos proporcionaron el siguiente acceso a los sistemas del proveedor de la nube: Un token de servicio de Moveworks que otorgaba acceso remoto al sistema Atlassian de la empresa. Una cuenta de servicio utilizada por la aplicación Smartsheet basada en SaaS, que brindaba acceso administrativo a la instancia Atlassian Jira de Cloudflare. Una cuenta de servicio de Bitbucket que permitía el acceso. al sistema de gestión de código fuente Un entorno AWS que no tenía acceso a la red global o contenía datos confidenciales o de clientes. Estas credenciales no se rotaron porque “erróneamente se creía que no estaban en uso”, dijo Cloudflare. El actor de amenazas comenzó a buscar formas de acceder a los sistemas de Cloudflare el 14 de noviembre utilizando las credenciales robadas. El 15 de noviembre, accedió con éxito a Atlassian Jira y Confluence utilizando el token de servicio Moveworks. Luego se utilizó la cuenta de servicio de Smartsheet para acceder a la suite Atlassian. Una vez en estos sistemas, los atacantes buscaron detalles sobre la configuración y gestión de la red global de Cloudflare, accediendo a varios tickets de Jira. El actor de amenazas también creó una cuenta de usuario de Atlassian a través de la credencial de Smartsheet. Esto fue para garantizar que tuvieran acceso persistente al entorno de Atlassian en caso de que se eliminara la cuenta de Smartsheet. Después de unos días de “descanso” en el acceso a los sistemas de Cloudflare, el atacante obtuvo acceso continuo al servidor Atlassian el 22 de noviembre después de instalar la herramienta Silver Adversary Emulation Framework, lo que permite el comando y control. Durante el día siguiente, el actor de amenazas vio 120 repositorios de códigos y descargó 76 de ellos al servidor Atlassian. Casi todos estos repositorios descargados estaban relacionados con la configuración y gestión del sistema en Cloudflare, como el funcionamiento de la identidad y el acceso remoto. Es probable que esto encuentre formas de montar un ataque posterior contra el proveedor. La compañía ha tratado los 76 repositorios de código fuente descargados como exfiltrados por los atacantes. Detección y solución de Cloudflare El actor de la amenaza fue detectado a las 16:00 UTC del 23 de noviembre, lo que llevó al equipo de seguridad de Cloudflare a desactivar la cuenta de servicio de Smartsheet 35 minutos después. La cuenta de usuario creada por el atacante fue descubierta y desactivada 48 minutos más tarde, a las 17.23. La herramienta Sliver se eliminó a las 11:59 del 24 de noviembre y la última actividad conocida del actor de amenazas fue a las 10:44 del mismo día. Cloudflare reveló que el actor de amenazas intentó acceder a una «infinidad» de otros sistemas en su red, pero su presencia se limitó a la suite Atlassian. Esto incluyó un intento de acceder a un centro de datos que Cloudflare aún no había puesto en producción en São Paulo, Brasil. Esto significó que no se accedió a datos ni sistemas de clientes. La empresa dijo que esta imposibilidad de moverse lateralmente se debió a su arquitectura de confianza cero, que imponía controles de acceso, reglas de firewall y el uso de claves de seguridad físicas. «Estamos seguros de que entre nuestra investigación y la de CrowdStrike, entendemos completamente las acciones del actor de la amenaza y que se limitaron a los sistemas en los que vimos su actividad», escribió Cloudflare. Tras el incidente, Cloudflare instituyó un proyecto denominado «Código Rojo» para reforzar todos los controles en su entorno y protegerlo contra futuras intrusiones. Esto incluyó el análisis de los 76 repositorios de código fuente robados para remediar secretos incrustados, vulnerabilidades y otras formas en que un atacante podría usarlos para montar un ataque posterior. Para evitar que los atacantes encontraran una nueva forma de regresar, la empresa emprendió un esfuerzo de remediación “integral”, que incluyó: Se rotaron más de 5000 credenciales individuales Se rotaron físicamente todos los sistemas de prueba y preparación Se realizaron clasificaciones forenses en 4893 sistemas Cada máquina en su red global La red, incluidos todos los productos Atlassian, fue reinventada y reiniciada. Sospecha de intrusión de un Estado-nación La naturaleza sofisticada y metódica del ataque sugiere que el autor fue un atacante de un Estado-nación, añadió la firma. «Basándonos en nuestra colaboración con colegas de la industria y el gobierno, creemos que este ataque fue realizado por un atacante de un estado nación con el objetivo de obtener acceso persistente y generalizado a la red global de Cloudflare», escribió Cloudflare.

Source link