- Cloudflare anunció que el 23 de noviembre de 2023 detectó a un actor de amenazas en sus servidores Atlassian autoalojados, pero que los datos de clientes, los sistemas de clientes, y los sistemas y configuraciones de su red global no se vieron afectados.
- La ruta de intrusión fueron 1 token de acceso y 3 credenciales de cuentas de servicio que no se rotaron después de la brecha de Okta de octubre de 2023, y el acceso se concentró en el entorno Atlassian, incluidos Jira, Confluence y Bitbucket.
- El actor de amenazas realizó reconocimiento y accedió a documentación interna del 14 al 17 de noviembre; luego, el 22 de noviembre, instaló Sliver mediante ScriptRunner for Jira para asegurar acceso persistente.
- Como respuesta “Code Red”, Cloudflare rotó más de 5,000 credenciales de producción, realizó una revisión forense de selección en 4,893 sistemas, y volvió a crear las imágenes y reinició todas las máquinas de la red global y todos los productos Atlassian.
- La investigación independiente de CrowdStrike tampoco encontró actividad omitida, y la última evidencia de actividad del actor de amenazas se confirmó el 24 de noviembre de 2023 a las 10:44 UTC.
Resumen del incidente y alcance del impacto
- Cloudflare detectó a un actor de amenazas el 23 de noviembre de 2023 en sus servidores Atlassian autoalojados.
- El equipo de seguridad inició de inmediato la investigación y bloqueó el acceso.
- El 26 de noviembre convocó al equipo forense de CrowdStrike para realizar un análisis independiente.
- Este incidente no afectó datos de clientes ni sistemas de clientes.
- Los servicios no estuvieron involucrados.
- Tampoco hubo cambios en sistemas ni configuraciones de la red global.
- Los controles de acceso, las reglas de firewall y las llaves de seguridad de hardware aplicadas mediante sus propias herramientas Zero Trust limitaron el movimiento lateral.
- El alcance del acceso del actor de amenazas se limitó a Atlassian Confluence, la wiki interna; Jira, la base de datos de bugs; Bitbucket, el sistema de gestión de código fuente; y los servidores donde se ejecuta Atlassian.
Credenciales usadas en la intrusión
- La intrusión comenzó con 1 token de servicio y 3 cuentas de servicio que se filtraron después de la brecha de Okta de octubre de 2023, pero que no se habían rotado.
- Token de servicio de Moveworks: usado para acceso remoto a sistemas Atlassian.
- Cuenta de servicio de Smartsheet: tenía privilegios de administrador en la instancia de Atlassian Jira.
- Cuenta de servicio de Bitbucket: usada para acceder al sistema de gestión de código fuente.
- Cuenta del entorno AWS: no tenía permisos de acceso a la red global, datos de clientes ni datos sensibles.
- Se consideró erróneamente que ese token y esas cuentas no estaban en uso, por lo que quedaron fuera del proceso de rotación.
- Cloudflare aclaró que este problema no fue un error de Atlassian, AWS, Moveworks ni Smartsheet, sino el resultado de que Cloudflare no rotó las credenciales.
Cronología del ataque
- Desde el 14 de noviembre a las 09:22:49, el actor de amenazas comenzó a explorar sistemas y realizar reconocimiento.
- Los intentos de inicio de sesión en la instancia de Okta fueron rechazados.
- También se bloqueó el acceso al Cloudflare Dashboard.
- Accedió al entorno AWS que opera el marketplace de Cloudflare Apps, pero ese entorno estaba separado de la red global y de los datos de clientes.
- El 15 de noviembre a las 16:28:38 logró acceder a Atlassian Jira y Confluence.
- Pasó por la puerta de enlace con el token de servicio de Moveworks y accedió al conjunto de productos Atlassian con la cuenta de servicio de Smartsheet.
- En la wiki buscó términos como remote access, secret, client-secret, openconnect, cloudflared y token.
- Accedió a 36 de 2,059,357 tickets de Jira y a 202 de 194,100 páginas de la wiki.
- Los tickets de Jira accedidos incluían elementos relacionados con gestión de vulnerabilidades, rotación de secrets, bypass de MFA, acceso a redes y respuesta al incidente de Okta.
- El 16 de noviembre a las 14:36:37, usando las credenciales de Smartsheet, creó una cuenta de Atlassian que parecía un usuario común de Cloudflare y la agregó a varios grupos.
- Era una medida para mantener el acceso al entorno Atlassian incluso si se eliminaba la cuenta de servicio de Smartsheet.
- Desde el 17 de noviembre a las 14:33:52 hasta el 20 de noviembre a las 09:26:53, el acceso a los sistemas de Cloudflare se detuvo, salvo por breves pruebas de acceso.
- El 22 de noviembre a las 14:18:22, usando los privilegios de administrador de Jira de la cuenta de servicio de Smartsheet, instaló Sliver Adversary Emulation Framework mediante el plugin ScriptRunner for Jira.
- Sliver es una herramienta y framework que los equipos de red team y atacantes usan para C2, conectividad y acceso persistente y sigiloso.
- Con esto intentó mantener acceso persistente a los servidores Atlassian y realizar movimiento lateral.
- El intento de acceder a un servidor de consola no productivo en un centro de datos de São Paulo, Brasil, que aún no había entrado en producción, falló.
Acceso a código fuente y documentos
- Después del 22 de noviembre, durante un día, el actor de amenazas revisó 120 repositorios de código de un total de 11,904 repositorios.
- De ellos, 76 repositorios fueron descargados a los servidores Atlassian usando la función git archive de Atlassian Bitbucket.
- Cloudflare no pudo confirmar si hubo exfiltración externa, pero respondió bajo la suposición de que sí la hubo.
- Los 76 repositorios estaban relacionados en su mayoría con las siguientes áreas:
- Forma en que operan los respaldos.
- Configuración y gestión de la red global.
- Sistema de identidad de Cloudflare.
- Acceso remoto.
- Uso de Terraform y Kubernetes.
- Algunos repositorios contenían secrets cifrados, y Cloudflare los rotó de inmediato, aunque estuvieran fuertemente cifrados.
- Cloudflare centró su investigación no tanto en el código fuente en sí, sino en secrets incrustados en el código, vulnerabilidades y rutas que pudieran aprovecharse en ataques posteriores.
- Cloudflare explicó que ha publicado mucho código fuente como open source y que ha tratado públicamente en su blog los algoritmos y técnicas que utiliza.
Detección y bloqueo
- El 23 de noviembre a las 16:00, el equipo de seguridad recibió una alerta sobre la presencia del actor de amenazas.
- 15:58: el actor de amenazas agregó la cuenta de servicio de Smartsheet al grupo de administradores.
- 16:00: la alerta automática sobre ese cambio llegó al equipo de seguridad.
- 16:12: el SOC de Cloudflare inició la investigación.
- 16:35: se deshabilitó la cuenta de servicio de Smartsheet.
- 17:23: se descubrió y deshabilitó la cuenta de usuario de Atlassian creada por el actor de amenazas.
- 17:43: se declaró un incidente interno de Cloudflare.
- 21:31: se aplicó una regla de firewall para bloquear las direcciones IP conocidas del actor de amenazas.
- El 24 de noviembre se confirmó la última actividad y la eliminación de Sliver.
- 10:44: última actividad conocida del actor de amenazas.
- 11:59: eliminación de Sliver.
- El actor de amenazas intentó acceder a diversos sistemas, incluidos métricas internas, configuración de red, sistemas de build, sistemas de alertas y sistemas de gestión de releases, pero no tuvo éxito.
- No se encontró evidencia de acceso a la red global, centros de datos, claves SSL, bases de datos o información de configuración de clientes, Cloudflare Workers, modelos de IA, infraestructura de red, ni almacenes de datos como Workers KV, R2 o Quicksilver.
Respuesta “Code Red” y trabajos de refuerzo
- Después de retirar al actor de amenazas del entorno el 24 de noviembre, Cloudflare asignó personal de toda la compañía para investigar la intrusión y confirmar el alcance del acceso.
- A partir del 27 de noviembre, una gran cantidad de personal técnico, tanto dentro como fuera del equipo de seguridad, se concentró en el proyecto Code Red.
- Reforzó, verificó y corrigió controles del entorno para prepararse ante intrusiones futuras.
- Verificó que el actor de amenazas no pudiera seguir teniendo acceso.
- Investigó todos los sistemas, cuentas y logs para confirmar si había acceso persistente y cuáles eran los objetivos accedidos o intentados.
- Las principales medidas fueron las siguientes:
- Rotación de más de 5,000 credenciales de producción.
- Separación física de sistemas de prueba y staging.
- Revisión forense de selección en 4,893 sistemas.
- Reimaging y reinicio de todas las máquinas de la red global.
- Reimaging y reinicio de todos los productos Atlassian, incluidos Jira, Confluence y Bitbucket.
- El equipo del centro de datos de São Paulo fue devuelto al fabricante.
- El equipo forense del fabricante investigó si hubo acceso o persistencia.
- No se encontró nada, pero Cloudflare reemplazó el hardware.
- Además, se investigaron paquetes de software no actualizados, cuentas de usuario que pudieran haberse creado, cuentas activas de empleados que ya no se usaban, secrets que pudieran haber quedado en tickets de Jira o código fuente, y archivos HAR subidos a la wiki.
- Los archivos HAR fueron eliminados ante la posibilidad de que contuvieran tokens.
- El trabajo inmediato de Code Red terminó el 5 de enero de 2024, pero continúan los trabajos de gestión de credenciales, refuerzo de software, gestión de vulnerabilidades y mejoras adicionales de alertas.
Investigación de CrowdStrike e IOCs
- CrowdStrike evaluó de forma independiente el alcance de la actividad del actor de amenazas y la evidencia de persistencia.
- No encontró actividad que hubiera sido pasada por alto en la investigación de Cloudflare.
- Concluyó que la última evidencia de actividad del actor de amenazas fue el 24 de noviembre de 2023 a las 10:44 UTC.
- Cloudflare, con base en la colaboración con pares de la industria y del gobierno, determinó que este ataque fue realizado por un actor patrocinado por un Estado que buscaba obtener acceso persistente y amplio a la red global de Cloudflare.
- Cloudflare publicó indicadores de compromiso para que otras organizaciones que pudieran haberse visto afectadas por la brecha de Okta puedan revisar sus logs.
193.142.58[.]126: infraestructura principal del actor de amenazas, propiedad de M247 Europe SRL.198.244.174[.]214: servidor C2 de Sliver, propiedad de OVH SAS.idowall[.]com: infraestructura de entrega de payload de Sliver.jvm-agent: nombre de archivo del payload de Sliver, SHA256bdd1a085d651082ad567b03e5186d1d46d822bb7794157ab8cce95d850a3caaf
1 comentarios
Opiniones en Hacker News
Creo que puedo confiarle mis datos y mi negocio a Cloudflare por este tipo de análisis público y respuesta.
No son perfectos y hay cosas con las que no estoy de acuerdo, pero por la mentalidad de ingeniería compartida en toda la empresa y la actitud de tomarse estos temas en serio, me parecen confiables.
La estrategia es remarcar que tienen una integridad mayor que la competencia y compartir algunas investigaciones operativas tras un incidente de seguridad reciente.
Pero Cloudflare no ofrece un análisis de riesgos SOC como procesador de tarjetas de pago PCI/DSS, ni explica por qué se les pasaron cuentas con privilegios elevados o cómo esas cuentas fueron comprometidas inicialmente. Explican la remediation más que la responsabilidad.
Mencionan una auditoría de terceros, pero no es porque estén pensando en los usuarios, sino porque PCI/DSS exige auditorías presenciales anuales a las organizaciones en las que se comprometió información de tarjetas de pago. De lo contrario, las principales redes de tarjetas les habrían suspendido el procesamiento de pagos.
Me cuesta creer que no hayan perdido nada, y en la mayoría de los Jira/Confluence que he visto había un montón de información secreta.
Al leer la parte que dice: “Al analizar las páginas wiki, issues de la base de datos de bugs y repositorios de código fuente a los que accedieron, parece que estaban buscando información sobre la arquitectura, la seguridad y la administración de nuestra red global”, para un actor estatal el método más fácil sería colocar a un ciudadano leal como empleado de la empresa objetivo y hacer que esa persona envíe esa información.
Como anécdota interesante, aunque de veracidad incierta, se dice que hace más de 10 años, en reuniones sociales de SRE de Google, algunas personas admitieron que recibían sueldo de las agencias de inteligencia de sus países.
Si no, me pregunto qué drogas tan fuertes circularían en esas reuniones para que ocurriera un fracaso de seguridad operativa tan terrible.
Los australianos reciben la “oportunidad” de participar en ese tipo de espionaje como si fuera una condición básica de ciudadanía https://en.wikipedia.org/wiki/Mass_surveillance_in_Australia...
Si hay una ventaja, quizá sea que puede ayudar a imponer buenas prácticas en el desarrollo de procedimientos y sistemas de zero trust.
Al ver la parte que dice: “Fuimos víctimas por segunda vez de una intrusión en los sistemas de Okta”, me pregunto si Cloudflare está reconsiderando el uso de Okta.
Okta también merece críticas, pero esto se siente como si Cloudflare estuviera empujando la responsabilidad hacia abajo para tapar su propio error.
Yo sigo usando un MacBook viejo que recibí “al principio”, así que no tiene ningún software de administración. En ese momento no había TI y simplemente me dieron una laptop nueva sin tocar.
La empresa me ofreció actualizarme a un M1/M2 Pro, pero me negué porque, si en una computadora de trabajo hay aunque sea una contraseña o clave personal, no quiero usar el sistema de login de Okta.
Así que no podré actualizar hasta que eso cause un problema serio en mi trabajo. Tal vez pueda usar incidentes como este como argumento ante el departamento de TI para justificar mi postura.
Me suena raro eso de que “un token de servicio y tres cuentas no se rotaron porque se creyó erróneamente que no estaban en uso”. Si no estaban en uso, no entiendo por qué no los eliminaron directamente.
Seguramente falta algo o se perdió en la transmisión, pero tomado literalmente no lo entiendo bien.
Por ejemplo, puede que en algún lugar de la base de datos esas cuentas de servicio aparecieran marcadas como inactivas, con un estado tipo “retirada” o “limpiada”, pero que esa marca fuera incorrecta. Por eso habrían rotado todas las contraseñas de cuentas activas y omitido las inactivas.
Si lo miro solo desde el contexto de infraestructura de clave pública y revocación de certificados, que conozco bien, dejar que un certificado expire, marcarlo como “ya no se usa” y revocarlo por completo son cosas bastante distintas. En el primer caso, la autoridad certificadora no tiene que hacer nada; en el segundo, puede no hacer nada o revocarlo; y en el tercero, debe mantener y distribuir activamente una lista de revocación. Si alguien dice “sobrescribí por accidente la clave privada, dame un certificado para una clave nueva”, normalmente no se agrega el certificado anterior a la lista de revocación.
Es un buen punto que hayan escrito claramente: “Esto no fue en absoluto un error de AWS, Moveworks ni Smartsheet; simplemente fueron credenciales que no logramos rotar”.
Aunque Cloudflare creía, y luego confirmó, que el acceso del atacante había sido limitado, rotó más de 5,000 credenciales de producción, separó físicamente los sistemas de prueba y staging, realizó análisis forense en 4,893 sistemas y reimagenó y reinició todas las máquinas de su red global.
También falló un intento de acceso al servidor de consola del centro de datos de São Paulo, que aún no había entrado en producción, pero aun así enviaron el equipo del centro de datos de Brasil de vuelta al fabricante para análisis forense y, aunque no encontraron nada, reemplazaron el hardware.
Probablemente no era necesario llegar tan lejos y habría sido fácil no hacerlo, pero el hecho de que sí lo hicieran merece reconocimiento.
Infiltrarse en las primeras etapas de la construcción de un nuevo centro de datos es casi el exploit definitivo. Basta imaginarse estar en medio de un nuevo Meet-Me room(https://en.wikipedia.org/wiki/Meet-me_room) y obtener acceso persistente a los switches principales.
Los centros de datos de Cloudflare suelen ser hubs de enormes volúmenes de tráfico de datos. El hecho de que el atacante entendiera el valor de un centro de datos “preproducción” probablemente significa que Cloudflare también se dio cuenta de que, si alguien establecía una cabeza de playa allí antes de que estuviera implementado el esquema normal de seguridad, era 100% game over. Si alguien logra instalarse dentro de un centro de datos en construcción y puesta en marcha, puede ser un incidente que acabe con la empresa.
También hay que recordar que, en las primeras etapas de construcción de un centro de datos, todos los switches y equipos usan valores predeterminados o contraseñas root vacías (admin/admin), y el firmware suele estar desactualizado y lleno de vulnerabilidades. Si un ataque así ocurrió antes de que la automatización parchara todo el firmware, es un incidente del tipo “devolvamos todos los equipos y que el fabricante mande equipos nuevos”.
Si asumes que el atacante solo accedió al alcance que puedes demostrar, le estás dejando huecos para sobrevivir. Para decir que no hace falta hacer esto debería requerirse la aprobación de un quórum de varias personas.
Claro, hablo de un mundo ideal. Yo ya me doy por satisfecho con que a mi equipo le den tiempo para implementar funcionalidades sin beneficio directo monetario ni para usuarios.
Estar preparado para ejecutar este tipo de rotación de credenciales requiere disciplina y preparación y, francamente, la mayoría de los equipos no hacen esa inversión. Incluso equipos inteligentes y con muchos recursos.
Que el equipo de seguridad de Cloudflare pueda decidir rotar todos los secretos y reimagenar todas las máquinas, y que eso ocurra de verdad en un plazo razonable, es bastante impresionante.
† https://twitter.com/badthingsdaily?lang=en
Lo más sorprendente aquí es que Cloudflare use Bitbucket.
Una vez que una filtración de datos sale al exterior, en este caso el código fuente queda afuera de forma permanente, y no tienes ningún control sobre quién lo obtiene.
Puedes reforzar todo lo que quieras después del incidente y hablar de eso cuanto quieras, pero lo que se intentaba evitar ya ocurrió. No puedes volver a meter los huevos revueltos en el cascarón.
En código viejo también se pueden encontrar otros easter eggs. Casi todas las empresas tienen backdoors no documentados.
Una filtración de datos de clientes sería peor, pero esto también es realmente malo.
Los datos de clientes del próximo año tampoco son los mismos que los datos de clientes de este año.
En Confluence de Atlassian, incluso solo el motor de búsqueda Apache Lucene integrado puede filtrar información sensible, y este tipo de acceso puede ser muy difícil de rastrear e identificar.
Si la información sensible ya aparece en la página de resultados de búsqueda, el atacante ni siquiera necesita abrir la página de Confluence.
La parte que dice que “un token de servicio y tres cuentas no se rotaron porque se creyó erróneamente que no se usaban” suena rara. Las credenciales no utilizadas probablemente deberían eliminarse, no rotarse.
¿Fue una situación tipo: “¿Qué son estas cuentas?” “Ah, no se usan. Ni aparecen en los logs” “Igual hay que rotarlas” “No, dejemos ahí unas cuentas arbitrarias con credenciales antiguas que podrían haber sido comprometidas… por razones más o menos vagas”?
Después del incidente de Okta, si rotaron las credenciales filtradas, creo que deberían haber montado un honeypot encima y esperado a ver qué hacían los atacantes.
Un honeypot también tiene el efecto de frenar al atacante por miedo a ser descubierto.