El 23 de noviembre de 2023 (Día de Acción de Gracias en Estados Unidos), Cloudflare detectó un acceso malicioso a su servidor interno de Atlassian. Con el apoyo de Crowdstrike, que se especializa en análisis forense, el proveedor rastreó la verdad de este incidente de seguridad y lo resumió. En una última entrada del blogTras recordar de paso que ninguno de los datos o sistemas de sus clientes se vio afectado por este hackeo, el proveedor explicó que del 14 al 17 de noviembre, un actor malicioso realizó un reconocimiento antes de acceder a su wiki interna así como a su base de datos de errores, ambas basadas en soluciones Atlassian, concretamente Confluence y Jira respectivamente, instaladas en un servidor.
“El 20 y 21 de noviembre, vimos accesos adicionales que indicaban que podrían haber regresado para probar el acceso y asegurarse de que tenían conectividad”, dijo el proveedor de servicios de seguridad y CDN. “Luego regresaron el 22 de noviembre y establecieron acceso persistente a nuestro servidor Atlassian usando ScriptRunner para Jira, accedieron a nuestro sistema de administración de código fuente que se basa en 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”. Para hacer esto, los atacantes usaron un token de acceso y tres credenciales de servicio de la Compromiso con Okta el mes pasado - que resultó ser más grave de lo anunciado - pero por lo tanto no pudieron ir más allá, sabiendo que el último rastro de su actividad se estableció el 24 de noviembre de 2023.
76 repositorios de código fuente en la mira de los hackers
"Al analizar las páginas wiki a las que accedieron, las bases de datos de errores y los repositorios de código fuente, parece que buscaban información sobre la arquitectura, la seguridad y la gestión de nuestra red global, probablemente con el objetivo de establecerse más profundamente", informa Cloudflare. El impacto operativo parece limitado, pero no insignificante: 120 repositorios de código se vieron afectados, incluidos 76 para los que se utilizó la función de archivado sin saber si los piratas informáticos lograron exfiltrarlos, de un total de 11.904. Pero esto no es anecdótico: los 76 repositorios de código fuente que eran candidatos a filtraciones o que realmente fueron exfiltrados estaban de hecho casi todos vinculados al funcionamiento de las copias de seguridad, la configuración y la gestión de la red global, el funcionamiento de la identidad de Cloudflare, el acceso remoto y su uso de Terraform y Kubernetes. Saber que un pequeño número de repositorios contenían secretos cifrados que se rotaron inmediatamente a pesar de que ellos mismos estaban fuertemente cifrados. Esos son datos valiosos para los piratas informáticos que resultan ser particularmente experimentados.
Aunque a primera vista el impacto operativo parece desproporcionado en comparación con lo que podría haber sido si los piratas informáticos hubieran logrado acceder al servidor de consola conectado a su centro de datos, Cloudflare no se libró del desastre. Hay que decir que el pedigrí de los actores maliciosos que estaban al mando no tiene nada que ver con los cibercriminales novatos: "basándonos en nuestra colaboración con colegas de la industria y del gobierno, creemos que este ataque fue llevado a cabo por un estado con el objetivo de obtener un acceso persistente y generalizado a la red global de Cloudflare", afirma el proveedor.
Código de operación rojo para comprobar y bloquear todo
Tras el incidente, Cloudflare centró sus esfuerzos hasta el 5 de enero de 2024 en un proyecto denominado “código rojo” para reforzar sus protocolos de seguridad y evitar que el actor de amenazas penetrara en su red, así como para validar y remediar cualquier control en su entorno para garantizar su seguridad frente a futuras intrusiones. “Nos centramos específicamente en estos 76 repositorios de código fuente para buscar secretos integrados (los secretos almacenados en el código se rotaron), vulnerabilidades y formas en las que un atacante podría utilizarlos para montar un ataque posterior”, afirmó Cloudflare.
Como parte de la operación, se animó a cada miembro del equipo a señalar las áreas en las que el atacante podría haber influido. “Al involucrar a tantas personas de toda la empresa, buscamos no dejar piedra sin mover para encontrar evidencia de acceso o cambios que se pudieran realizar para mejorar la seguridad”, continúa Cloudflare. “Nuestro objetivo era evitar que el atacante usara información técnica sobre cómo funcionaba nuestra red como un medio para volver a ingresar”. [...] “Realizamos una rotación masiva de todas las credenciales de producción (más de 5000 credenciales individuales), segmentamos físicamente los sistemas de prueba y preparación, realizamos inventarios forenses en 4893 sistemas, reinstalamos y reiniciamos cada máquina en nuestra red global, incluidos todos los sistemas a los que accedió el actor de amenazas y todos los productos de Atlassian (Jira, Confluence y Bitbucket)”.
Otras noticias que te pueden interesar