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 rationaliser 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 des applications, des services web et des 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 de identifiants de connexion à travers plusieurs applications.
Multi-Factor Authentication (MFA) : Renforce la sécurité en exigeant plusieurs formes de vérification.
Lifecycle Management : Automatise la création, la mise à jour et la désactivation des comptes utilisateurs.
Universal Directory : Permet la gestion centralisée des utilisateurs, des groupes et des appareils.
API Access Management : Sécurise et gère l'accès aux API.
Ces services visent collectivement à renforcer la protection des données et à rationaliser 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 entreprises 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 utilisateurs et groupes pour des applications externes. 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 un examen de sécurité d'un environnement Okta, vous devez demander un accès en lecture seule d'administrateur.
Résumé
Il y a des utilisateurs (qui peuvent être stockés dans Okta, connectés depuis des fournisseurs d'identité configurés ou authentifiés via Active Directory ou LDAP). Ces utilisateurs peuvent être regroupés 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 un certain mapping avec Okta pour partager des informations (comme des adresses email, des prénoms...). De plus, chaque application doit être intégrée dans une politique d'authentification, qui indique les authentificateurs nécessaires pour qu'un utilisateur accède à 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
Généralement, le portail d'une entreprise sera situé à companyname.okta.com. Sinon, essayez de simples variations 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 la 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.
Vérifiez l'attaque dans 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écryptant 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é maîtresse').
Vérifiez l'attaque dans https://trustedsec.com/blog/okta-for-red-teamers.
Détournement d'AD en tant qu'Admin
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 rationaliser ce processus, offrant une méthode fluide pour intercepter et gérer les données d'authentification dans l'environnement Okta.
Vérifiez l'attaque dans https://trustedsec.com/blog/okta-for-red-teamers.
Fournisseur SAML factice Okta
Vérifiez l'attaque dans 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 consiste à configurer un IdP SAML 2.0 dans Okta, à manipuler l'URL de connexion unique de l'IdP pour la 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. L'exécution réussie de ces étapes permet de s'authentifier en tant que n'importe quel utilisateur Okta, contournant le besoin d'identifiants d'utilisateur individuels, élevant considérablement le contrôle d'accès de manière potentiellement inaperçue.
Attaque de 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'imitation 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 à un attribut que l'utilisateur peut modifier, il pourra imiter 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 modifier ce champ), mais s'il fait confiance par exemple à primaryEmail, vous pourriez être en mesure de le changer pour l'adresse email d'un collègue et de l'imiter (vous devrez avoir accès à l'email et accepter le changement).
Notez que cette imitation dépend de la façon dont chaque application a été configurée. Seules celles qui font confiance au champ que vous avez modifié et acceptent les mises à jour seront compromises. Par conséquent, l'application doit 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 pourriez imiter quelqu'un sur chaque application serait de l'essayer !
Évasion des 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, évitant le tableau de bord principal d'Okta. Avec un jeton d'accès Okta, rejouez le jeton à l'URL spécifique à l'application Okta au lieu de la page de connexion principale.
Les recommandations clés incluent :
Évitez d'utiliser des proxys anonymes populaires et des services VPN lors de la relecture 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.
Évitez de rejouer des jetons d'utilisateurs différents 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 beaucoup de configurations possibles, sur cette page vous trouverez comment les examiner pour qu'elles soient aussi sécurisées que possible :
Références
Last updated
