# Seguridad de Okta {{#include ../../banners/hacktricks-training.md}} ## Información Básica [Okta, Inc.](https://www.okta.com/) 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). > [!CAUTION] > 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**, probablemente podrás **comprometer todas las demás plataformas que la empresa está utilizando**. > [!TIP] > Para realizar una revisión de seguridad de un entorno de Okta, deberías solicitar **acceso de solo lectura de administrador**. ### Resumen Hay **usuarios** (que pueden ser **almacenados en Okta,** iniciar sesión desde **Proveedores de Identidad** configurados o autenticarse 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. > [!CAUTION] > 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**. ## Ataques ### Localizando el Portal de Okta 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**. ### Inicio de Sesión en Okta a través de Kerberos 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 utilizando herramientas como Rubeus o Mimikatz, asegurando 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**](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 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**](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 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**](https://trustedsec.com/blog/okta-for-red-teamers)**.** ### Proveedor SAML Falso de Okta **Consulta el ataque en** [**https://trustedsec.com/blog/okta-for-red-teamers**](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 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, 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. ### Ataque de Suplantación de Colega 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 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 ¡intentar hacerlo! ## Evadiendo 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 **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. - **Evitar reproducir** tokens de diferentes usuarios desde la misma dirección IP. - Tener cuidado 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 IPs o su rango, bloqueando todo el tráfico restante. ## Fortalecimiento de Okta Okta tiene muchas configuraciones posibles, en esta página encontrarás cómo revisarlas para que sean lo más seguras posible: {{#ref}} okta-hardening.md {{#endref}} ## Referencias - [https://trustedsec.com/blog/okta-for-red-teamers](https://trustedsec.com/blog/okta-for-red-teamers) - [https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23](https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23) {{#include ../../banners/hacktricks-training.md}}