Un hacker logró comprometer la infraestructura

Cloudflare dio a conocer mediante una publicación de blog, un informe sobre el hackeo de uno de los servidores de su infraestructura, en el informe detalla el incidente que sufrió el «Día de Acción de Gracias de 2023» y señaló que el 23 de noviembre de 2023, un hacker accedió al servidor Atlassian autohospedado de la compañía.

Este servidor operaba un sitio wiki interno basado en la plataforma Atlassian Confluence, el sistema de seguimiento de problemas Atlassian Jira y el sistema de gestión de códigos Bitbucket. El análisis reveló que el atacante pudo obtener acceso al servidor utilizando tokens obtenidos como resultado del hackeo de Okta en octubre, que resultó en la filtración de tokens de acceso.

Después de la divulgación del hackeo de Okta, Cloudflare comenzó el proceso de actualización de credenciales, claves y tokens utilizados a través de los servicios de Okta. Sin embargo, se descubrió que, como resultado, un token y tres cuentas (entre varios miles) permanecieron comprometidos y fue debido a que estas credenciales no fueron reemplazadas que el atacante aprovecho este descuido.

Queremos enfatizar a nuestros clientes que este evento no afectó los datos ni los sistemas de los clientes de Cloudflare. Debido a nuestros controles de acceso, reglas de firewall y el uso de claves de seguridad físicas aplicadas mediante nuestras propias herramientas Zero Trust, la capacidad del actor de amenazas para moverse lateralmente era limitada. Ningún servicio estuvo implicado y no se realizaron cambios en nuestros sistemas o configuración de red global. Esta es la promesa de una arquitectura Zero Trust: es como mamparos en un barco donde un compromiso en un sistema no puede comprometer a toda la organización.

Aunque estas credenciales se consideraron inutilizables, de hecho, permitieron el acceso a la plataforma Atlassian, el sistema de administración de código Bitbucket, una aplicación SaaS con acceso administrativo al entorno Atlassian Jira y un entorno en AWS que sirve el directorio de aplicaciones de Cloudflare. Es importante destacar que este entorno no tiene acceso a la infraestructura CDN y no almacena datos confidenciales.

El incidente no afectó los datos ni los sistemas de los usuarios de Cloudflare. Una auditoría determinó que el ataque se limitó a los sistemas que ejecutaban productos Atlassian y no se extendió a otros servidores. Esto se atribuye al modelo Zero Trust de Cloudflare y al aislamiento de partes de la infraestructura, que limitaron la propagación del ataque. Cloudflare menciona que también implementó reglas de firewall para bloquear las direcciones IP conocidas de los atacantes y que el marco de emulación Sliver Adversary fue eliminado el 24 de noviembre.

Se menciona que el hackeo del servidor de Cloudflare fue descubierto el 23 de noviembre, pero los primeros signos de acceso no autorizados a la wiki y al sistema de seguimiento de problemas se registraron el 14 de noviembre. El 22 de noviembre, el atacante instaló un backdoor para obtener acceso permanente, utilizando ScriptRunner para Jira. Ese mismo día, el atacante también obtuvo acceso al sistema de control, que utilizaba la plataforma Atlassian Bitbucket. Posteriormente, se intentó conectar al servidor de consola utilizado para acceder a un centro de datos en Brasil que aún no había sido puesto en funcionamiento, pero todos los intentos de conexión fueron denegados.

Al parecer, la actividad del atacante se limitó a estudiar la arquitectura de la red de distribución de contenidos y buscar puntos débiles. Utilizó una búsqueda en la wiki de palabras clave relacionadas con acceso remoto, secretos, openconnect, cloudflare y tokens.

El atacante accedió a 202 páginas wiki (de un total de 194,100) y 36 informes de problemas (de 2,059,357) relacionados con la gestión de vulnerabilidades y la rotación de claves. También se detectó la descarga de 120 repositorios de código (de un total de 11,904), la mayoría relacionados con backup, configuración y gestión de CDN, sistemas de identidad, acceso remoto, y uso de las plataformas Terraform y Kubernetes. Algunos de los repositorios contenían claves cifradas dejadas en el código, las cuales fueron reemplazadas inmediatamente después del incidente, a pesar del uso de métodos de cifrado confiables.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.