Okta Security
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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. Atienden no solo 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 la Okta Identity Cloud. Esta plataforma abarca un conjunto de productos, incluyendo, pero no limitado a:
Single Sign-On (SSO): Simplifica el acceso del usuario al permitir un conjunto de credenciales de inicio de sesión en múltiples aplicaciones.
Multi-Factor Authentication (MFA): Mejora la seguridad al requerir múltiples formas de verificación.
Lifecycle Management: Automatiza la creación, actualización y desactivación de cuentas de usuario.
Universal Directory: Permite la gestión centralizada de usuarios, grupos y dispositivos.
API Access Management: Asegura y gestiona el acceso a APIs.
Estos servicios tienen como objetivo colectivo fortalecer la protección de datos y agilizar el acceso de los 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 a grandes empresas, pequeñas compañías y desarrolladores individuales por igual. Hasta la última actualización en septiembre de 2021, Okta es reconocida como una entidad prominente en el ámbito de la Gestión de Identidad y Acceso (IAM).
El objetivo principal de Okta es configurar el acceso a 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.
Hay usuarios (que pueden ser almacenados en Okta, iniciados desde Proveedores de Identidad configurados o autenticados a través de Active Directory o LDAP). Estos usuarios pueden estar dentro de grupos. También hay autenticadores: diferentes opciones para autenticar como contraseña, y varios 2FA como WebAuthn, correo electrónico, teléfono, okta verify (pueden estar habilitados o deshabilitados)...
Luego, hay aplicaciones sincronizadas con Okta. Cada aplicación tendrá algún 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 Super Administrador.
Si un atacante compromete Okta con acceso de Administrador, todas las aplicaciones que confían en Okta probablemente estarán comprometidas.
Usualmente, el portal de una empresa estará ubicado en companyname.okta.com. Si no, prueba variaciones simples de companyname. Si no puedes encontrarlo, también es posible que la organización tenga un registro CNAME como okta.companyname.com apuntando al portal de Okta.
Si companyname.kerberos.okta.com está activo, Kerberos se utiliza para el acceso a Okta, normalmente eludiendo MFA para usuarios de Windows. Para encontrar usuarios de Okta autenticados por Kerberos en AD, ejecuta getST.py con parámetros apropiados. Al obtener un ticket de usuario de AD, iníctalo en un host controlado usando herramientas como Rubeus o Mimikatz, asegurándote de que clientname.kerberos.okta.com esté en la zona "Intranet" de las Opciones de Internet. 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 permite 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. Usa ticketer.py para generar un ticket para el usuario víctima y entregarlo a través del navegador para autenticarte con Okta.
Consulta el ataque en https://trustedsec.com/blog/okta-for-red-teamers.
Esta técnica implica acceder al Agente AD de Okta en un servidor, que sincroniza usuarios y maneja la autenticación. Al examinar y desencriptar configuraciones en OktaAgentService.exe.config, notablemente el AgentToken usando DPAPI, un atacante puede potencialmente 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, permitiendo así el acceso no autorizado o proporcionando autenticación universal a través de Okta (similar a una 'llave maestra').
Consulta el ataque en https://trustedsec.com/blog/okta-for-red-teamers.
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 un conector se nombra 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.
Consulta el ataque en https://trustedsec.com/blog/okta-for-red-teamers.
Consulta el ataque en https://trustedsec.com/blog/okta-for-red-teamers.
La técnica implica desplegar un proveedor SAML falso. Al integrar un Proveedor de Identidad (IdP) externo dentro del marco de Okta usando 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, manipulando la URL de inicio de sesión único del IdP para redirigir a través del archivo de hosts local, generando un certificado autofirmado y configurando los ajustes de Okta para que coincidan con el nombre de usuario o correo electrónico. Ejecutar con éxito estos pasos permite la autenticación como cualquier usuario de Okta, eludiendo la necesidad de credenciales individuales de usuario, elevando significativamente el control de acceso de manera potencialmente inadvertida.
En este blog se explica cómo preparar una campaña de phishing contra un portal de Okta.
Los atributos que cada usuario puede tener y modificar (como correo electrónico o nombre) pueden ser configurados en Okta. Si una aplicación confía como ID 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 puedes cambiar ese campo), pero si confía, por ejemplo, en primaryEmail, podrías cambiarlo a 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ían en el campo que modificaste y aceptan 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, diferentes aplicaciones están configuradas de manera diferente).
¡La mejor manera de averiguar si podrías suplantar a alguien en cada aplicación sería intentarlo!
Las políticas de detección de comportamiento en Okta pueden ser desconocidas hasta que se encuentren, pero eludirlas se puede lograr dirigiéndose directamente a las aplicaciones de Okta, evitando el panel de control principal de Okta. Con un token de acceso de Okta, reproduce el token en la URL específica de la aplicación de Okta en lugar de la página de inicio de sesión principal.
Las recomendaciones clave incluyen:
Evitar usar proxies de anonimato populares y servicios VPN al reproducir tokens de acceso capturados.
Asegurarse de que haya cadenas de agente de usuario consistentes 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 control de Okta.
Si conoces las direcciones IP de la empresa víctima, restringe el tráfico a esas IP o su rango, bloqueando todo el tráfico restante.
Okta tiene muchas configuraciones posibles, en esta página encontrarás cómo revisarlas para que sean lo más seguras posible:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
