Okta Security

Aprende a hackear AWS desde cero hasta convertirte en un experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Información Básica

Okta, Inc. es reconocida en el sector de gestión de identidad y acceso por sus soluciones de software basadas en la nube. Estas soluciones están diseñadas para agilizar y asegurar la autenticación de usuarios en diversas aplicaciones modernas. No solo se dirigen a empresas que buscan proteger sus datos sensibles, sino también a desarrolladores interesados en integrar controles de identidad en aplicaciones, servicios web y dispositivos.

La oferta principal de Okta es el Okta Identity Cloud. Esta plataforma abarca una serie de productos, que incluyen pero no se limitan a:

  • Inicio de Sesión Único (SSO): Simplifica el acceso de usuarios al permitir un conjunto único de credenciales de inicio de sesión en múltiples aplicaciones.

  • Autenticación Multifactor (MFA): Mejora la seguridad al requerir múltiples formas de verificación.

  • Gestión del Ciclo de Vida: Automatiza la creación, actualización y desactivación de cuentas de usuario.

  • Directorio Universal: Permite la gestión centralizada de usuarios, grupos y dispositivos.

  • Gestión de Acceso a API: Asegura y gestiona el acceso a las APIs.

Estos servicios tienen como objetivo fortalecer la protección de datos y agilizar el acceso de usuarios, mejorando tanto la seguridad como la conveniencia. La versatilidad de las soluciones de Okta las convierte en una opción popular en diversas industrias, beneficiando tanto a grandes empresas como a pequeñas compañías y desarrolladores individuales. Hasta la última actualización en septiembre de 2021, Okta es reconocida como una entidad prominente en el ámbito de Gestión de Identidad y Acceso (IAM).

El objetivo principal de Okta es configurar el acceso de diferentes usuarios y grupos a aplicaciones externas. Si logras comprometer privilegios de administrador en un entorno de Okta, es muy probable que puedas comprometer todas las demás plataformas que la empresa esté utilizando.

Para realizar una revisión de seguridad de un entorno de Okta, debes solicitar acceso de solo lectura de administrador.

Resumen

Existen usuarios (que pueden estar almacenados en Okta, registrados desde Proveedores de Identidad configurados o autenticados a través de Active Directory o LDAP). Estos usuarios pueden estar dentro de grupos. También existen autenticadores: diferentes opciones de autenticación como contraseña, y varios métodos de autenticación de dos factores como WebAuthn, correo electrónico, teléfono, Okta Verify (pueden estar habilitados o deshabilitados)...

Luego, hay aplicaciones sincronizadas con Okta. Cada aplicación tendrá un mapeo con Okta para compartir información (como direcciones de correo electrónico, nombres...). Además, cada aplicación debe estar dentro de una Política de Autenticación, que indica los autenticadores necesarios para que un usuario acceda a la aplicación.

El rol más poderoso es el de Super Administrador.

Si un atacante compromete Okta con acceso de Administrador, es muy probable que todas las aplicaciones que confían en Okta sean comprometidas.

Ataques

Localización del Portal de Okta

Por lo general, el portal de una empresa estará ubicado en nombredeempresa.okta.com. Si no es así, prueba con variaciones simples de nombredeempresa. Si no puedes encontrarlo, también es posible que la organización tenga un registro CNAME como okta.nombredeempresa.com apuntando al portal de Okta.

Inicio de Sesión en Okta a través de Kerberos

Si nombredeempresa.kerberos.okta.com está activo, se utiliza Kerberos para el acceso a Okta, generalmente evitando el MFA para los usuarios de Windows. Para encontrar usuarios de Okta autenticados con Kerberos en AD, ejecuta getST.py con los parámetros apropiados. Al obtener un ticket de usuario de AD, injéctalo en un host controlado utilizando herramientas como Rubeus o Mimikatz, asegurándote de que clientname.kerberos.okta.com esté en la zona "Intranet" de las Opciones de Internet. Al acceder a una URL específica, debería devolver una respuesta JSON "OK", indicando la aceptación del ticket de Kerberos y otorgando acceso al panel de control de Okta.

Comprometer la cuenta de servicio de Okta con el SPN de delegación habilita un ataque de Silver Ticket. Sin embargo, el uso de AES por parte de Okta para la encriptación de tickets requiere poseer la clave AES o la contraseña en texto plano. Utiliza ticketer.py para generar un ticket para el usuario víctima y entrégalo a través del navegador para autenticarte con Okta.

Ver el ataque en https://trustedsec.com/blog/okta-for-red-teamers.

Secuestro del Agente AD de Okta

Esta técnica implica acceder al Agente AD de Okta en un servidor, que sincroniza usuarios y maneja la autenticación. Al examinar y descifrar las configuraciones en OktaAgentService.exe.config, especialmente el AgentToken utilizando DPAPI, un atacante potencialmente puede interceptar y manipular datos de autenticación. Esto permite no solo monitorear y capturar credenciales de usuario en texto plano durante el proceso de autenticación de Okta, sino también responder a intentos de autenticación, lo que permite el acceso no autorizado o proporciona autenticación universal a través de Okta (similar a una 'llave maestra').

Ver el ataque en https://trustedsec.com/blog/okta-for-red-teamers.

Secuestro de AD como Administrador

Esta técnica implica secuestrar un Agente AD de Okta obteniendo primero un Código OAuth, luego solicitando un token de API. El token está asociado con un dominio AD, y se nombra un conector para establecer un agente AD falso. La inicialización permite que el agente procese intentos de autenticación, capturando credenciales a través de la API de Okta. Hay herramientas de automatización disponibles para agilizar este proceso, ofreciendo un método fluido para interceptar y manejar datos de autenticación dentro del entorno de Okta.

Ver el ataque en https://trustedsec.com/blog/okta-for-red-teamers.

Proveedor SAML Falso de Okta

Ver el ataque en https://trustedsec.com/blog/okta-for-red-teamers.

La técnica implica implementar un proveedor SAML falso. Al integrar un Proveedor de Identidad externo (IdP) dentro del marco de Okta utilizando una cuenta privilegiada, los atacantes pueden controlar el IdP, aprobando cualquier solicitud de autenticación a voluntad. El proceso implica configurar un IdP SAML 2.0 en Okta, manipular la URL de Inicio de Sesión Único del IdP para redireccionarla a través del archivo de hosts local, generar un certificado autofirmado y configurar los ajustes de Okta para que coincidan con el nombre de usuario o correo electrónico. Al ejecutar con éxito estos pasos, se permite la autenticación como cualquier usuario de Okta, evitando la necesidad de credenciales de usuario individuales, elevando significativamente el control de acceso de una manera potencialmente desapercibida.

Phishing en el portal de Okta con Evilgnix

En esta publicación de blog se explica cómo preparar una campaña de phishing contra un portal de Okta.

Ataque de suplantación de colega

Los atributos que cada usuario puede tener y modificar (como el correo electrónico o el nombre) se pueden configurar en Okta. Si una aplicación está confiando en un atributo que el usuario puede modificar, podrá suplantar a otros usuarios en esa plataforma.

Por lo tanto, si la aplicación confía en el campo userName, probablemente no podrás cambiarlo (porque generalmente no se puede cambiar ese campo), pero si confía, por ejemplo, en primaryEmail es posible que puedas cambiarlo por la dirección de correo electrónico de un colega y suplantarlo (necesitarás tener acceso al correo electrónico y aceptar el cambio).

Ten en cuenta que esta suplantación depende de cómo se configuró cada aplicación. Solo las que confíen en el campo que modificaste y acepten actualizaciones estarán comprometidas. Por lo tanto, la aplicación debería tener este campo habilitado si existe:

También he visto otras aplicaciones que eran vulnerables pero no tenían ese campo en la configuración de Okta (al final, las diferentes aplicaciones se configuran de manera diferente).

La mejor manera de averiguar si podrías suplantar a alguien en cada aplicación sería ¡intentarlo!

Evadir políticas de detección de comportamiento

Las políticas de detección de comportamiento en Okta pueden ser desconocidas hasta que se encuentren, pero burlarlas se puede lograr dirigiéndose directamente a las aplicaciones de Okta, evitando el panel principal de Okta. Con un token de acceso de Okta, reproducir el token en la URL específica de la aplicación de Okta en lugar de la página principal de inicio de sesión.

Las recomendaciones clave incluyen:

  • Evitar el uso de proxies anonimizadores populares y servicios VPN al reproducir tokens de acceso capturados.

  • Asegurarse de que haya coherencia en las cadenas de agente de usuario entre el cliente y los tokens de acceso reproducidos.

  • Abstenerse de reproducir tokens de diferentes usuarios desde la misma dirección IP.

  • Tener precaución al reproducir tokens contra el panel de Okta.

  • Si se conocen las direcciones IP de la empresa víctima, restringir el tráfico a esas IPs o su rango, bloqueando todo otro tráfico.

Reforzamiento de la seguridad en Okta

Okta tiene muchas configuraciones posibles, en esta página encontrarás cómo revisarlas para que sean lo más seguras posible:

pageOkta Hardening

Referencias

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Última actualización