Okta Security
Informations de base
Okta, Inc. est reconnue dans le secteur de la gestion des identités et des accès pour ses solutions logicielles basées sur le cloud. Ces solutions sont conçues pour simplifier et sécuriser l'authentification des utilisateurs à travers diverses applications modernes. Elles s'adressent non seulement aux entreprises cherchant à protéger leurs données sensibles, mais aussi aux développeurs intéressés par l'intégration de contrôles d'identité dans les applications, services web et appareils.
L'offre phare d'Okta est le Okta Identity Cloud. Cette plateforme comprend une suite de produits, y compris mais sans s'y limiter :
Single Sign-On (SSO) : Simplifie l'accès des utilisateurs en permettant un ensemble d'identifiants de connexion pour plusieurs applications.
Multi-Factor Authentication (MFA) : Renforce la sécurité en exigeant plusieurs formes de vérification.
Lifecycle Management : Automatise les processus de création, mise à jour et désactivation des comptes utilisateurs.
Universal Directory : Permet la gestion centralisée des utilisateurs, groupes et appareils.
API Access Management : Sécurise et gère l'accès aux APIs.
Ces services visent collectivement à renforcer la protection des données et à simplifier l'accès des utilisateurs, améliorant à la fois la sécurité et la commodité. La polyvalence des solutions d'Okta en fait un choix populaire dans divers secteurs, bénéfique pour les grandes entreprises, les petites sociétés et les développeurs individuels. À la dernière mise à jour en septembre 2021, Okta est reconnue comme une entité de premier plan dans le domaine de la gestion des identités et des accès (IAM).
Le principal objectif d'Okta est de configurer l'accès à différentes applications pour différents utilisateurs et groupes. Si vous parvenez à compromettre les privilèges d'administrateur dans un environnement Okta, vous serez très probablement capable de compromettre toutes les autres plateformes utilisées par l'entreprise.
Pour effectuer une revue de sécurité d'un environnement Okta, vous devriez demander un accès administrateur en lecture seule.
Résumé
Il y a des utilisateurs (qui peuvent être stockés dans Okta, connectés à partir de fournisseurs d'identité configurés ou authentifiés via Active Directory ou LDAP). Ces utilisateurs peuvent être dans des groupes. Il y a aussi des authentificateurs : différentes options pour s'authentifier comme le mot de passe, et plusieurs 2FA comme WebAuthn, email, téléphone, okta verify (ils peuvent être activés ou désactivés)...
Ensuite, il y a des applications synchronisées avec Okta. Chaque application aura une certaine correspondance avec Okta pour partager des informations (telles que les adresses email, les prénoms...). De plus, chaque application doit être dans une politique d'authentification, qui indique les authentificateurs nécessaires pour qu'un utilisateur puisse accéder à l'application.
Le rôle le plus puissant est Super Administrator.
Si un attaquant compromet Okta avec un accès administrateur, toutes les applications faisant confiance à Okta seront très probablement compromises.
Attaques
Localiser le portail Okta
Habituellement, le portail d'une entreprise sera situé sur companyname.okta.com. Sinon, essayez des variations simples de companyname. Si vous ne pouvez pas le trouver, il est également possible que l'organisation ait un enregistrement CNAME comme okta.companyname.com pointant vers le portail Okta.
Connexion à Okta via Kerberos
Si companyname.kerberos.okta.com est actif, Kerberos est utilisé pour l'accès à Okta, contournant généralement le MFA pour les utilisateurs Windows. Pour trouver les utilisateurs Okta authentifiés par Kerberos dans AD, exécutez getST.py avec les paramètres appropriés. Après avoir obtenu un ticket utilisateur AD, injectez-le dans un hôte contrôlé en utilisant des outils comme Rubeus ou Mimikatz, en vous assurant que clientname.kerberos.okta.com est dans la zone "Intranet" des options Internet. Accéder à une URL spécifique devrait renvoyer une réponse JSON "OK", indiquant l'acceptation du ticket Kerberos, et accordant l'accès au tableau de bord Okta.
Compromettre le compte de service Okta avec le SPN de délégation permet une attaque Silver Ticket. Cependant, l'utilisation par Okta de AES pour le chiffrement des tickets nécessite de posséder la clé AES ou le mot de passe en clair. Utilisez ticketer.py pour générer un ticket pour l'utilisateur victime et livrez-le via le navigateur pour s'authentifier avec Okta.
Consultez l'attaque sur https://trustedsec.com/blog/okta-for-red-teamers.
Détournement de l'agent AD Okta
Cette technique implique d'accéder à l'agent AD Okta sur un serveur, qui synchronise les utilisateurs et gère l'authentification. En examinant et en déchiffrant les configurations dans OktaAgentService.exe.config, notamment le AgentToken en utilisant DPAPI, un attaquant peut potentiellement intercepter et manipuler les données d'authentification. Cela permet non seulement de surveiller et de capturer les identifiants des utilisateurs en clair pendant le processus d'authentification Okta, mais aussi de répondre aux tentatives d'authentification, permettant ainsi un accès non autorisé ou fournissant une authentification universelle via Okta (semblable à une 'clé passe-partout').
Consultez l'attaque sur https://trustedsec.com/blog/okta-for-red-teamers.
Détournement d'AD en tant qu'administrateur
Cette technique implique de détourner un agent AD Okta en obtenant d'abord un code OAuth, puis en demandant un jeton API. Le jeton est associé à un domaine AD, et un connecteur est nommé pour établir un faux agent AD. L'initialisation permet à l'agent de traiter les tentatives d'authentification, capturant les identifiants via l'API Okta. Des outils d'automatisation sont disponibles pour simplifier ce processus, offrant une méthode transparente pour intercepter et gérer les données d'authentification dans l'environnement Okta.
Consultez l'attaque sur https://trustedsec.com/blog/okta-for-red-teamers.
Faux fournisseur SAML Okta
Consultez l'attaque sur https://trustedsec.com/blog/okta-for-red-teamers.
La technique consiste à déployer un faux fournisseur SAML. En intégrant un fournisseur d'identité externe (IdP) dans le cadre d'Okta en utilisant un compte privilégié, les attaquants peuvent contrôler l'IdP, approuvant toute demande d'authentification à volonté. Le processus consiste à configurer un IdP SAML 2.0 dans Okta, à manipuler l'URL de connexion unique de l'IdP pour une redirection via le fichier hosts local, à générer un certificat auto-signé et à configurer les paramètres Okta pour correspondre au nom d'utilisateur ou à l'email. La réussite de ces étapes permet de s'authentifier en tant que tout utilisateur Okta, contournant le besoin d'identifiants utilisateur individuels, élevant considérablement le contrôle d'accès de manière potentiellement inaperçue.
Phishing du portail Okta avec Evilgnix
Dans cet article de blog est expliqué comment préparer une campagne de phishing contre un portail Okta.
Attaque d'usurpation d'identité de collègue
Les attributs que chaque utilisateur peut avoir et modifier (comme l'email ou le prénom) peuvent être configurés dans Okta. Si une application fait confiance en tant qu'ID à un attribut que l'utilisateur peut modifier, il pourra usurper l'identité d'autres utilisateurs sur cette plateforme.
Par conséquent, si l'application fait confiance au champ userName, vous ne pourrez probablement pas le changer (car vous ne pouvez généralement pas changer ce champ), mais si elle fait confiance par exemple à primaryEmail, vous pourriez être capable de le changer pour l'adresse email d'un collègue et usurper son identité (vous devrez avoir accès à l'email et accepter le changement).
Notez que cette usurpation dépend de la façon dont chaque application a été configurée. Seules celles faisant confiance au champ que vous avez modifié et acceptant les mises à jour seront compromises. Par conséquent, l'application devrait avoir ce champ activé s'il existe :
J'ai également vu d'autres applications qui étaient vulnérables mais n'avaient pas ce champ dans les paramètres Okta (à la fin, différentes applications sont configurées différemment).
La meilleure façon de savoir si vous pouvez usurper l'identité de quelqu'un sur chaque application serait de l'essayer !
Éviter les politiques de détection comportementale
Les politiques de détection comportementale dans Okta peuvent être inconnues jusqu'à ce qu'elles soient rencontrées, mais les contourner peut être réalisé en ciblant directement les applications Okta, en évitant le tableau de bord principal d'Okta. Avec un jeton d'accès Okta, rejouez le jeton à l'URL spécifique de l'application Okta au lieu de la page de connexion principale.
Recommandations clés :
Évitez d'utiliser des proxys anonymiseurs populaires et des services VPN lors de la relecture des jetons d'accès capturés.
Assurez-vous que les chaînes user-agent sont cohérentes entre le client et les jetons d'accès rejoués.
Évitez de rejouer des jetons de différents utilisateurs depuis la même adresse IP.
Faites preuve de prudence lors de la relecture des jetons contre le tableau de bord Okta.
Si vous connaissez les adresses IP de l'entreprise victime, limitez le trafic à ces IP ou à leur plage, en bloquant tout autre trafic.
Renforcement d'Okta
Okta a de nombreuses configurations possibles, sur cette page vous trouverez comment les examiner pour qu'elles soient aussi sécurisées que possible :
Okta HardeningRéférences
Last updated
