[24/10/2023] Los atacantes consiguieron vulnerar el sistema de soporte de la empresa de gestión de identidades y accesos Okta utilizando credenciales robadas, y extrajeron tokens de sesión de cliente válidos de los archivos de soporte cargados, según un informe de la firma.
Las fuertes políticas de autenticación multifactor (MFA) aplicadas por uno de los clientes afectados de la empresa le permitieron detectar el acceso no autorizado, bloquearlo e informar de la brecha a Okta.
"En el curso normal de las operaciones, el servicio de asistencia de Okta pedirá a los clientes que suban un archivo HTTP (HAR), que permite solucionar problemas replicando la actividad del navegador", explicó David Bradbury, director de seguridad de Okta, en una entrada de blog. "Los archivos HAR también pueden contener datos confidenciales, incluidas cookies y tokens de sesión, que los actores maliciosos pueden utilizar para hacerse pasar por usuarios válidos".
El incidente fue descubierto por ingenieros de seguridad de BeyondTrust, un proveedor de soluciones de seguridad de identidad y acceso, cuya cuenta de administrador interna de Okta fue secuestrada. Los controles de políticas establecidos por el equipo de seguridad de la empresa bloquearon un intento de autenticación sospechoso procedente de una dirección IP de Malasia.
Se solicitó al atacante la autenticación MFA
La política de BeyondTrust en el entorno de Okta era permitir únicamente el acceso a la consola de administración de Okta desde dispositivos gestionados en los que se hubiera instalado Okta Verify, una aplicación de autenticación multifactor desarrollada por Okta. Debido a esta política, al atacante se le solicitaba autenticación MFA cuando intentaba acceder a la consola de administración, a pesar de que el token que robó le proporcionaba una sesión válida.
"Es importante que los clientes de Okta mejoren las políticas de seguridad a través de configuraciones como solicitar a los usuarios administradores MFA en cada inicio de sesión", dijo el equipo de seguridad de BeyondTrust en un aviso. "Si bien esto fue dentro de una sesión existente que el atacante secuestró, Okta todavía ve el acceso al tablero como un nuevo inicio de sesión y solicita MFA".
Además, la cuenta de administrador de BeyondTrust estaba configurada para autenticarse utilizando un dispositivo compatible con FIDO2. FIDO2 es un estándar de autenticación sin contraseña que utiliza criptografía de clave pública para validar a los usuarios, una opción mucho más segura que las implementaciones basadas en SMS, que son vulnerables a ataques como el intercambio de SIM y otras técnicas de intermediario.
Esto permitió a BeyondTrust eliminar rápidamente la posibilidad de que el robo del token de sesión se hubiera producido internamente, y empezar a sospechar que Okta tenía una brecha de seguridad. Esto también se debe a que la autenticación no autorizada se produjo 30 minutos después de que el administrador de BeyondTrust subiera un archivo HAR al sistema de soporte de Okta como parte de la resolución de un problema de soporte. Los archivos HAR son esencialmente grabaciones del navegador que permiten al ingeniero de soporte replicar lo que el usuario estaba haciendo.
Se creó una cuenta de servicio falsa
Cuando el atacante no pudo acceder al panel de administración de Okta, pasó a acceder a la cuenta a través de la API de Okta. Esto les permitió crear una cuenta de servicio falsa a la que llamaron svc_network_backup.
"Las cookies de sesión se pueden utilizar para autenticarse en la API oficial de Okta y, en muchos casos, estas carecen de las restricciones de políticas que se aplican a la consola de administración interactiva", advirtió el equipo de seguridad de BeyondTrust. "El atacante actuó rápidamente, pero nuestras detecciones y respuestas fueron inmediatas, desactivando la cuenta y mitigando cualquier exposición potencial".
La brecha fue rastreada hasta las credenciales robadas
BeyondTrust notificó las sospechas a Okta, que luego rastreó la brecha hasta las credenciales robadas que proporcionaban el acceso necesario para ver los archivos de los clientes en los tickets de soporte. La empresa informó a todos los clientes potencialmente afectados, y revocó todos los tokens de sesión incrustados en los archivos.
Aconseja a los clientes que eliminen las cookies y los testigos de sesión de los archivos HAR antes de cargarlos, y que revisen los registros del sistema Okta para detectar cualquier sesión sospechosa. El aviso de la compañía incluye las direcciones IP que los atacantes utilizaron para acceder a las cuentas de los clientes, y la mayoría de ellas son IP asociadas a servicios VPN comerciales.
Otra empresa afectada en este incidente fue Cloudflare, que también fue capaz de detectar y bloquear el uso indebido de sus credenciales de Okta antes de que Okta descubriera la brecha. La compañía recomienda encarecidamente que los clientes de Okta implementen MFA basado en hardware.
"Las contraseñas por sí solas no ofrecen el nivel necesario de protección contra ataques", afirmó Cloudflare en su informe. "Recomendamos encarecidamente el uso de claves de hardware, ya que otros métodos de MFA pueden ser vulnerables a ataques de phishing".
Investigue y responda a todos los cambios inesperados de contraseña y MFA para sus instancias de Okta y eventos sospechosos iniciados por el soporte, aconsejó la compañía. Asegúrese de que todos los restablecimientos de contraseña son válidos y fuerce un restablecimiento de contraseña para cualquiera bajo sospecha y asegúrese de que sólo las claves MFA válidas están presentes en la configuración de la cuenta del usuario.
Basado en el artículo de Lucian Constantin (CSO) y editado por CIO Perú