La empresa Cloudflare, que proporciona una red de entrega de contenido que maneja aproximadamente el 20% del tráfico de internet, publicó un informe sobre el hackeo de uno de los servidores en su infraestructura, donde funcionaba un sitio wiki interno basado en la plataforma Atlassian Confluence, el sistema de seguimiento de errores Atlassian Jira y el sistema de control de código Bitbucket. El análisis mostró que el atacante pudo acceder al servidor utilizando tokens obtenidos durante el hackeo de octubre de la empresa Okta, que llevó a la filtración de tokens de acceso.
Tras la divulgación en otoño de la información sobre el hackeo de Okta, la empresa Cloudflare inició el proceso de actualización de credenciales, claves y tokens utilizados a través de los servicios de Okta, pero resultó que un token y tres cuentas (de varios miles) comprometidos como resultado del hackeo de Okta no fueron reemplazados y continuaron activos, lo que fue aprovechado por el atacante. Las credenciales en cuestión se consideraban inactivas, pero en realidad permitían acceder a la plataforma Atlassian, al sistema de control de código Bitbucket, a una aplicación SaaS con acceso administrativo al entorno de Atlassian Jira, y al entorno en AWS que sirve el catálogo de Cloudflare Apps, pero que no tenía acceso a la infraestructura de CDN ni almacenaba datos confidenciales.
El incidente no afectó los datos y sistemas de los usuarios de Cloudflare. La auditoría realizada determinó que el ataque se limitó a los sistemas con productos de Atlassian y no se propagó a otros servidores, gracias a la aplicación en Cloudflare de un modelo de confianza cero (Zero Trust) y a la aislamiento de partes de la infraestructura.
El hackeo del servidor de Cloudflare fue detectado el 23 de noviembre, y las primeras huellas de acceso no autorizado al wiki y al sistema de seguimiento de errores se registraron el 14 de noviembre. El 22 de noviembre, el atacante instaló una puerta trasera para obtener acceso permanente, creada con la ayuda de ScriptRunner para Jira. Ese mismo día, el atacante accedió al sistema de control de versiones que utilizaba la plataforma Atlassian Bitbucket. Después de esto, se intentó conectarse a la consola servidor, utilizada para acceder a un centro de datos que aún no estaba operativo en Brasil, pero todos los intentos de conexión resultaron fallidos.
Parece que la actividad del atacante se limitó al estudio de la arquitectura de la red de entrega de contenido y la búsqueda de vulnerabilidades. Durante su actividad, el atacante utilizó la búsqueda en wiki con palabras clave relacionadas con acceso remoto, secretos, openconnect, cloudflared y tokens. Se registró la apertura de 202 páginas wiki (de 194100) y 36 informes de problemas (de 2059357) relacionados con la gestión de la remoción de vulnerabilidades y la rotación de claves. También se identificó la descarga de 120 repositorios de código (de 11904), la mayoría de los cuales estaban relacionados con copias de seguridad, configuraciones y gestión de CDN, sistemas de identificación, acceso remoto y el uso de plataformas Terraform y Kubernetes. En algunos de los repositorios se encontraron claves encriptadas dejadas en el código, que fueron reemplazadas inmediatamente después del incidente, a pesar del uso de métodos de encriptación confiables.
Fuente: opennet.ru
