Hoy, 22 de marzo de 2022, a las 03:30 UTC, nos enteramos de una brecha de seguridad en Okta. Utilizamos Okta a nivel interno para verificar la identidad de los usuarios como parte de nuestras soluciones de autenticación. Hemos investigado esta brecha de seguridad con detenimiento y no creemos haber resultado afectados. No utilizamos Okta para las cuentas de los clientes, razón por la que no necesitan adoptar ninguna medida a menos que ellos sean usuarios de Okta.
Investigación y medidas
Según nuestra interpretación, durante el mes de enero de 2022, un grupo de hackers ajenos a Okta tuvieron acceso a la cuenta de un empleado subcontratado de Okta y pudieron realizar acciones como si se tratara del propio empleado. En una captura de pantalla compartida en las redes sociales, se veía la dirección de correo electrónico de un empleado de Cloudflare, junto con una ventana emergente que indicaba que el hacker se hacía pasar por un empleado de Okta y podía haber iniciado un restablecimiento de contraseña.
Nos enteramos de este incidente a través del SIRT interno de Cloudflare. SIRT es nuestro equipo de respuesta ante incidentes de seguridad, y cualquier empleado de Cloudflare puede alertar al SIRT de un posible problema. Exactamente a las 03:30 UTC, un empleado de Cloudflare envió un correo electrónico al SIRT con un enlace a un tuit que se había enviado a las 03:22 UTC. Este tuit informaba de la posible brecha de seguridad de Okta. Muchos otros empleados de Cloudflare se pusieron en contacto con el SIRT durante las dos horas siguientes.
La siguiente cronología resume los principales pasos que dimos después de ese correo electrónico inicial recibido a las 03:30 UTC al SIRT.
Cronología (horas en UTC)
03:30 - El SIRT recibe el primer aviso de la existencia de los tuits.
03:38 - Ve que los tuits contienen información sobre Cloudflare (logo, información del usuario).
03:41 - Crea una sala de incidentes para iniciar la investigación y comienza a reunir a las personas necesarias.
03:50 - El SIRT llega a la conclusión de que no hubo eventos de registro de auditoría relevantes (como cambios de contraseña) para el usuario que aparece en la captura de pantalla mencionada anteriormente.
04:13 - Contactamos directamente con Okta para solicitar información detallada que arroje luz a nuestra investigación.
04:23 - Se revisan todos los registros de Okta que se incluyen en nuestro sistema de Gestión de información y eventos de seguridad (SIEM) en busca de posibles actividades sospechosas, incluidos los restablecimientos de contraseña de los últimos tres meses.
05:03 - El SIRT suspende las cuentas de los usuarios que podrían haberse visto afectados.
Se suspende temporalmente el acceso del empleado de Cloudflare cuya dirección de correo electrónico aparecía en las capturas de pantalla del grupo de hackers.
05:06 - El SIRT inicia una investigación de los registros de acceso (direcciones IP, ubicaciones, métodos de autenticación multifactor) de los usuarios afectados.
05:38 - Primer tuit de Matthew Prince reconociendo el problema.
Parecía que un empleado subcontratado de Okta con acceso para realizar acciones como forzar un restablecimiento de contraseña en una cuenta de cliente de Okta estaba en riesgo, por lo que decidimos concentrarnos en cada empleado que había restablecido su contraseña o modificado su autenticación multifactor de modo alguno desde el 1 de diciembre hasta hoy. Desde el 1 de diciembre de 2021, 144 empleados de Cloudflare habían restablecido su contraseña o modificado su autenticación multifactor. Forzamos el restablecimiento de la contraseña de todos ellos y les informamos del cambio.
05:44 - Se ultima la lista de todos los usuarios que han cambiado su contraseña en los últimos tres meses. Todas las cuentas tuvieron que pasar por un restablecimiento de contraseña.
06:40 - Tuit de Matthew Prince sobre el restablecimiento de contraseña.
07:57 - Recibimos la confirmación de Okta de que no había eventos relevantes que pudieran indicar actividad maliciosa en su consola de soporte para las instancias de Cloudflare.
Cómo utilizamos Okta
Utilizamos Okta como nuestro proveedor de identidad, integrado con Cloudflare Access, para garantizar que nuestros usuarios puedan acceder de forma segura a los recursos internos. En publicaciones anteriores del blog, describimos cómo utilizamos Access para proteger los recursos internos y cómo integramos tokens de hardware para permitir que nuestro proceso de autenticación de usuarios sea más seguro y evitar la apropiación de cuentas.
En el caso de la brecha de Okta, no bastaría con cambiar la contraseña de un usuario. El atacante también tendría que cambiar el token de hardware (FIDO) configurado para el mismo usuario. Como resultado, sería fácil detectar las cuentas en riesgo basándose en las claves de hardware asociadas.
Aunque los registros están disponibles en la consola de Okta, también los almacenamos en nuestros propios sistemas. De este modo, añadimos una capa adicional de seguridad, ya que podemos almacenar los registros durante más tiempo del que ofrece la consola de Okta. Esta práctica también garantiza que una brecha de seguridad en la plataforma Okta no puede alterar las pruebas que ya hemos recopilado y almacenado.
No utilizamos Okta para verificar la autenticación de clientes en nuestros sistemas, y no almacenamos ningún dato de clientes en Okta. Solo se utiliza para gestionar las cuentas de nuestros usuarios.
Las principales medidas que adoptamos durante este incidente fueron:
- Ponernos en contacto con Okta para recabar más información sobre lo que se sabe del ataque.
- Suspender la única cuenta de Cloudflare visible en las capturas de pantalla.
- Buscar en los registros del sistema Okta cualquier indicio de brecha de seguridad (cambios de contraseña, cambios de token de hardware, etc.). Cloudflare lee los registros del sistema de Okta cada cinco minutos y los almacena en nuestro SIEM, de modo que si experimentamos un incidente como este, podemos remontarnos antes de los 90 días proporcionados en el panel de control de Okta. Algunos tipos de eventos dentro de Okta que buscamos son:
user.account.reset_password,user.mfa.factor.update,system.mfa.factor.deactivate,user.mfa.attempt_bypassyuser.session.impersonation.initiate. De las comunicaciones que hemos recibido de Okta hasta el momento, no queda claro de la información relativa a la brecha de seguridad de un empleado subcontratado de Okta, quién sería el actor del registro del sistema. - Buscar en los registros de correo electrónico de Google Workplace para ver los restablecimientos de contraseña. Confirmamos que estos coinciden con los registros del sistema de Okta utilizando una fuente distinta a la de Okta, teniendo en cuenta que fueron vulnerados, y no estábamos seguros de la fiabilidad de sus registros.
- Recopilamos una lista de las cuentas de los empleados de Cloudflare que cambiaron sus contraseñas en los últimos tres meses y exigimos el restablecimiento de la contraseña para todas ellas. Como parte de la recuperación de sus cuentas, cada usuario participará en una videollamada con el equipo informático de Cloudflare para verificar su identidad antes de que se vuelva a habilitar su cuenta.
Qué debes hacer si tu también eres cliente de Okta
Si también eres cliente de Okta, debes ponerte en contacto con ellos para obtener más información. Te aconsejamos que lleves a cabo las siguientes acciones:
- Habilitar la autenticación multifactor para todas las cuentas de usuario. Las contraseñas por sí solas no ofrecen el nivel necesario de protección contra ataques. Recomendamos encarecidamente el uso de claves seguras, ya que otros métodos de autenticación multifactor pueden ser vulnerables a ataques de phishing.
- Investiga y responde:
a. Comprueba todos los cambios de contraseña y autenticación multifactor para tus instancias de Okta.
b. Presta especial atención a los eventos iniciados de soporte.
c. Asegúrate de que todos los restablecimientos de contraseña son válidos o simplemente asume que todos están bajo sospecha y fuerza un nuevo restablecimiento de contraseña.
d. Si encuentras algún evento sospechoso relacionado con la autenticación multifactor, asegúrate de que solo hay claves de autenticación multifactor válidas en la configuración de la cuenta del usuario. - Asegúrate de que tienes otras capas de seguridad para proporcionar seguridad adicional en caso de que una de ellas falle.
Conclusión
Los equipos de informática y seguridad de Cloudflare siguen trabajando en esta brecha de seguridad. Si aparecen nuevos datos que indiquen un riesgo adicional a la cronología de enero, publicaremos más informes con nuestros hallazgos y acciones.
También hemos solicitado a Okta una serie de registros e información adicional. Si recibimos nuevos datos que alteren nuestra evaluación de la situación, actualizaremos el blog o publicaremos nuevas entradas.