Un Estado-nación utilizó los recientes ataques a Okta para piratear los sistemas de Cloudflare

Cloudflare ha revelado que un actor de un Estado-nación pirateó el servidor Atlassian autoalojado de la empresa en noviembre de 2023, pero el ataque fue detenido por el equipo interno a los pocos días de acceder. El pirata informático, que utilizó tokens y credenciales robadas, pudo acceder a "parte de la documentación y a una cantidad limitada de código fuente" antes de ser frustrado.

"El día de Acción de Gracias, 23 de noviembre de 2023, Cloudflare detectó al actor de la amenaza en nuestro servidor Atlassian autoalojado", dijo Cloudflare en una entrada de blog. "Nuestro equipo de seguridad comenzó inmediatamente una investigación y cortó el acceso del actor de la amenaza". Después de investigar internamente y bloquear el acceso malicioso, Cloudflare encargó a CrowdStrike una investigación independiente, que concluyó que el hackeo no tuvo impacto en ningún sistema o dato de Cloudflare.

El atacante obtuvo acceso a través del compromiso de Okta

El ataque comenzó con el actor obteniendo acceso a algunas credenciales de Cloudflare a través de una reciente violación de Okta, el proveedor de gestión de identidad y acceso (IAM) de la compañía.

"Fuimos víctimas de un ataque a los sistemas de Okta que dio lugar a que un actor de amenazas obtuviera acceso a un conjunto de credenciales. Se suponía que todas estas credenciales debían ser rotadas", dijo Cloudflare. "Desafortunadamente, no pudimos rotar un token de servicio y tres cuentas de servicio (de miles) de credenciales que se filtraron durante el incidente de Okta".

Entre las credenciales robadas había un token de servicio de Moveworks que otorgaba acceso remoto a los sistemas de Atlassian. Otros compromisos incluyeron una cuenta de Smartsheet con acceso administrativo a la instancia de Atlassian Jira, una cuenta de servicio Bitbucket con acceso al sistema de gestión de código fuente Cloudflare, y un entorno AWS con "ningún acceso a la red global y ningún cliente o datos sensibles".

"Del 14 al 17 de noviembre, el actor de la amenaza hizo un reconocimiento y luego accedió a nuestra wiki interna (que utiliza Atlassian Confluence) y a nuestra base de datos de errores (Atlassian Jira)", añadió Cloudflare. "Luego regresaron el 22 de noviembre y establecieron un acceso persistente a nuestro servidor Atlassian utilizando ScriptRunner para Jira, obtuvieron acceso a nuestro sistema de gestión de código fuente (que utiliza Atlassian Bitbucket) e intentaron, sin éxito, acceder a un servidor de consola que tenía acceso al centro de datos que Cloudflare aún no había puesto en producción en São Paulo, Brasil".

La compañía añadió que el incidente no fue en ningún caso un error por parte de Atlassian, AWS, Moveworks o Smartsheet, y que ocurrió por no rotar las credenciales robadas asumiendo que no estaban en uso.

Los esfuerzos de confianza cero contribuyeron a la eliminación de la infección

Cloudflare afirmó que pudo contener y eliminar completamente la infección gracias a la adopción de una arquitectura de confianza cero. "Gracias a nuestros controles de acceso, reglas de cortafuegos y el uso de claves de seguridad reforzadas con nuestras propias herramientas de confianza cero, la capacidad del actor de la amenaza para moverse lateralmente fue limitada", dijo la compañía. "Ningún servicio se vio implicado, y no se realizaron cambios en nuestros sistemas de red globales o en la configuración".

Reconociendo la intención del ataque para establecer persistencia y temiendo una persistencia pasada por alto, Cloudflare recurrió a un enfoque de remediación integral con medidas proactivas adicionales para futuros ataques.

"A pesar de que creíamos, y más tarde confirmamos, que el atacante tenía un acceso limitado, llevamos a cabo un esfuerzo exhaustivo para rotar todas las credenciales de producción (más de 5.000 credenciales individuales), segmentar físicamente los sistemas de prueba y de ensayo, realizar triajes forenses en 4.893 sistemas, reimaginar y reiniciar todas las máquinas de nuestra red global, incluyendo todos los sistemas a los que accedió el actor de la amenaza y todos los productos de Atlassian (Jira, Confluence y Bitbucket)", reza el blog de Cloudflare.

Entre otras medidas correctivas adoptadas por Cloudflare, cabe destacar la comprobación de paquetes de software obsoletos, cuentas de usuario que pudieran haberse creado, cuentas de empleados activas no utilizadas y secretos dejados en tickets de Jira o código fuente.