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 sur 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 des applications, des services web et des appareils.
L'offre phare d'Okta est le Okta Identity Cloud. Cette plateforme englobe une suite de produits, comprenant notamment :
Authentification unique (SSO) : Simplifie l'accès des utilisateurs en permettant un ensemble d'identifiants de connexion pour plusieurs applications.
Authentification multi-facteurs (MFA) : Renforce la sécurité en exigeant plusieurs formes de vérification.
Gestion du cycle de vie : Automatise la création, la mise à jour et la désactivation des comptes utilisateurs.
Répertoire universel : Permet la gestion centralisée des utilisateurs, des groupes et des appareils.
Gestion de l'accès aux API : Sécurise et gère l'accès aux API.
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 aux grandes entreprises, aux petites sociétés et aux développeurs individuels. Au dernier bilan en septembre 2021, Okta est reconnue comme une entité importante 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 externes pour les utilisateurs et les groupes. Si vous parvenez à compromettre les privilèges d'administrateur dans un environnement Okta, vous pourrez très probablement 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 en lecture seule administrateur.
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 d'authentification comme le mot de passe, et plusieurs 2FA comme WebAuthn, e-mail, 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 un certain mapping avec Okta pour partager des informations (telles que les adresses e-mail, les prénoms...). De plus, chaque application doit être à l'intérieur d'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 le Super Administrateur.
Si un attaquant compromet Okta avec un accès Administrateur, toutes les applications faisant confiance à Okta seront très probablement compromises.
Attaques
Localisation du portail Okta
Généralement, le portail d'une entreprise se trouvera à companyname.okta.com. Sinon, essayez des variantes simples de companyname. Si vous ne le trouvez pas, il est également possible que l'organisation ait un enregistrement CNAME tel que 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 l'authentification multi-facteurs (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é à l'aide d'outils comme Rubeus ou Mimikatz, en vous assurant que clientname.kerberos.okta.com est dans la zone "Intranet" des Options Internet. L'accès à 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.
La compromission du compte de service Okta avec l'authentification de délégation SPN permet une attaque Silver Ticket. Cependant, l'utilisation d'Okta de AES pour le chiffrement des tickets nécessite la possession de la clé AES ou du 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 vous 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 l'accès à 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 l'AgentToken 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 de l'AD en tant qu'administrateur
Cette technique implique le détournement d'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 rationaliser ce processus, offrant une méthode fluide 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.
Fournisseur SAML Factice Okta
Consultez l'attaque sur https://trustedsec.com/blog/okta-for-red-teamers.
La technique implique le déploiement d'un fournisseur SAML factice. 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 implique la configuration d'un IdP SAML 2.0 dans Okta, la manipulation de l'URL de connexion unique IdP pour la redirection via le fichier hosts local, la génération d'un certificat auto-signé, et la configuration des paramètres Okta pour correspondre au nom d'utilisateur ou à l'e-mail. L'exécution réussie de ces étapes permet une authentification en tant qu'utilisateur Okta, contournant le besoin de mots de passe d'utilisateur individuels, élevant considérablement le contrôle d'accès de manière potentiellement non remarquée.
Phishing du portail Okta avec Evilgnix
Dans cet article de blog, il est expliqué comment préparer une campagne de phishing contre un portail Okta.
Attaque d'usurpation de collègue
Les attributs que chaque utilisateur peut avoir et modifier (comme l'e-mail ou le prénom) peuvent être configurés dans Okta. Si une application utilise comme ID un attribut que l'utilisateur peut modifier, il pourra usurper d'autres utilisateurs sur cette plateforme.
Par conséquent, si l'application fait confiance au champ userName, vous ne pourrez probablement pas le modifier (car vous ne pouvez généralement pas modifier ce champ), mais si elle fait confiance par exemple à primaryEmail, vous pourriez être en mesure de le changer pour l'adresse e-mail d'un collègue et l'usurper (vous devrez avoir accès à l'e-mail et accepter le changement).
Notez que cette usurpation dépend de la configuration de chaque application. 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 vulnérables qui n'avaient pas ce champ dans les paramètres d'Okta (au final, les différentes applications sont configurées différemment).
La meilleure façon de savoir si vous pourriez usurper 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.
Les recommandations clés incluent :
Éviter d'utiliser des proxys anonymiseurs populaires et des services VPN lors du replay des jetons d'accès capturés.
Assurez-vous que les chaînes d'agent utilisateur sont cohérentes entre le client et les jetons d'accès rejoués.
S'abstenir de rejouer des jetons d'utilisateurs différents à partir de la même adresse IP.
Faites preuve de prudence lors du replay des jetons contre le tableau de bord Okta.
Si vous connaissez les adresses IP de l'entreprise victime, restreignez le trafic à ces adresses IP ou à leur plage, en bloquant tout autre trafic.
Renforcement d'Okta
Okta offre de nombreuses configurations possibles, sur cette page vous trouverez comment les examiner pour qu'elles soient aussi sécurisées que possible :
Références
Dernière mise à jour
