L'an dernier, le laboratoire de détection des menaces de Varonis a découvert et divulgué des systèmes de contournement d'authentification et des attaques d'ingénierie sociale sur plusieurs services cloud populaires tels que Box, Google et Zoom.
Sachant qu’Okta est la référence en matière d’authentification sécurisée pour des dizaines de milliers de clients, nous avons décidé de rechercher des problèmes similaires dans leur suite de produits de gestion des identités.
Notre recherche d’API non documentées nous a conduits dans les méandres des solutions d’identité hybride d’Okta et à de multiples divulgations de sécurité :
- CrossTalk : attaque d’ingénierie sociale qui a permis à un compte de développeur gratuit contrôlé par un hacker d’orchestrer des attaques de phishing par SMS et par e-mail.
- Secret Agent : utilisation d’un jeton SSWS déchiffré sur le serveur de synchronisation d’Okta pour enregistrer un agent malveillant, intercepter les demandes d’authentification et détourner les identifiants en texte brut de tout utilisateur au sein de l’entreprise.
Comme toute équipe de recherche, nous aimons raconter nos histoires et partager nos techniques, mais nous savons aussi que ces informations pourraient finir entre de mauvaises mains. Bien que nous ayons découvert ces failles l’an dernier, nous avons décidé de retarder la publication plus longtemps que d’habitude afin de donner à l’incroyable équipe d’Okta suffisamment de temps pour répondre à chaque découverte.
L’équipe d’Okta a également créé un guide des bonnes pratiques qui explique comment configurer vos instances en toute sécurité et faire face à ce type d’attaques. Contactez votre représentant Okta pour en savoir plus.
Nous apprécions grandement le partenariat et le professionnalisme de l’équipe de sécurité des produits Okta ainsi que leur volonté de rendre leurs solutions résilientes aux attaques que nous avons identifiées.
Hameçonnage des utilisateurs avec CrossTalk
Okta fournit un mécanisme permettant aux clients d’envoyer des SMS et des e-mails à leurs utilisateurs. Les administrateurs peuvent créer des modèles et déclencher l’envoi de messages lorsque certaines actions se produisent (par exemple, envoyer un code MFA lorsqu’un utilisateur tente de se connecter).
Notre laboratoire de détection des menaces a découvert CrossTalk, un bug qui permettait à un administrateur d’Okta d’envoyer des SMS et des e-mails à n’importe quel utilisateur de la solution au sein de n’importe quelle entreprise.
En exploitant CrossTalk, un pirate informatique ayant accès à n’importe quel tenant Okta pourrait :
- modifier leurs modèles de SMS et d’e-mail pour qu’ils correspondent à une entreprise cible
- créer des utilisateurs avec des adresses e-mail et des numéros de téléphone correspondant aux employés de leur victime
- envoyer des e-mails et des SMS à ces utilisateurs peu méfiants
L’utilisateur recevrait le message du service Okta légitime, sans aucune indication ni aucun signe laissant penser que le message provient d’un autre tenant ou potentiellement d’une personne mal intentionnée.
Pour exploiter CrossTalk, les pirates doivent commencer par compromettre un tenant Okta. Nous avons donc tenté de créer un compte développeur gratuit dans Okta pour lancer nos attaques. Cependant, il convient de noter que la personnalisation des modèles est désactivée dans la version gratuite.
En revanche, en ce qui concerne les comptes développeur, c’est une autre histoire ! Nous avons créé un compte développeur gratuit dans Okta et, en quelques minutes, nous avons pu envoyer à notre équipe marketing des messages suspects « provenant d’Okta ».
Vous remarquerez que le message du hacker est ajouté à l’historique des messages de l’utilisateur via le service SMS officiel Okta. Par conséquent, il n’y a quasiment aucune chance que l’employé détecte un problème :
Message malveillant envoyé par le service SMS d’Okta
En créant un compte développeur gratuit dans Okta, un pirate anonyme pourrait envoyer des SMS ou des e-mails, semblant provenir du vrai compte Okta, à la base d’utilisateurs. Cette méthode peut être utilisée pour lancer une attaque de phishing, contourner la MFA, distribuer des logiciels malveillants ou inciter les utilisateurs à effectuer des actions associées à des privilèges.
Explorer les agents de synchronisation d’Okta
Les attaques d’ingénierie sociale fonctionnent très bien, mais nous voulions aller plus loin, nous avons donc créé notre propre environnement Okta sur site pour examiner la façon dont le cloud d’Okta communique avec les appareils sur site.
Okta fournit plusieurs agents pour faciliter les communications avec le domaine sur site. Nous avons décidé de nous concentrer sur les agents les plus utilisés par les entreprises : Active Directory (AD) et LDAP. Voici comment fonctionne l’agent de synchronisation AD :
Architecture d’Okta pour Active Directory
Trouver des mots de passe en texte brut
Après avoir configuré l’environnement de recherche et déployé les agents Okta, nous avons immédiatement tenté de supprimer le protocole SSL (Secure Sockets Layer) de la communication entre les terminaux d’Okta et notre environnement de laboratoire. Bien qu’il soit très amusant de décompiler le langage intermédiaire (IL), c’est une activité extrêmement chronophage. Nous avons donc opté pour une méthode plus rapide qui nous permettrait d’inspecter le trafic d’Okta en texte brut.
Il a été facile de configurer notre proxy d’interception SSL, car les produits permettent généralement de contourner l’épinglage SSL pour les proxys d’entreprise. Après avoir intercepté certaines requêtes, nous avons fait une étrange découverte : chaque fois que les utilisateurs d’Okta essayaient de se connecter à leur tableau de bord, leur mot de passe était transmis en texte brut dans la couche SSL.
Ce n’est pas le seul comportement inhabituel que nous avons remarqué dans notre environnement de recherche. Lors de l’installation, les agents Okta demandent à un utilisateur privilégié d’autoriser les demandes pour tous les utilisateurs entre le site et Okta. Cette procédure est courante, mais pour une raison inconnue, le programme d’installation d’Okta a enregistré les données d’identification des comptes à privilèges en texte brut dans les fichiers journaux du programme d’installation.
Ces derniers peuvent être lus par tous les utilisateurs de la machine et peuvent être ainsi utilisés pour les déplacements latéraux au sein du réseau de l’entreprise si le serveur de synchronisation d’Okta est compromis. Ce constat souligne la nécessité d’analyser continuellement les secrets exposés dans votre environnement.
Depuis, l’équipe d’Okta a mis à jour son programme d’installation pour inclure une case à cocher intitulée "Do not log in installer" (« Ne pas se connecter au programme d’installation »), qui empêche les données d’identification d’être stockées dans les journaux de l’installateur.
Attaque de l’API LDAP
Après avoir effectué une analyse de protocole, nous avons tenté de répliquer les processus et les agents Okta pour nous assurer que nous en comprenions les rouages.
En nous penchant sur l’intégration LDAP, nous avons examiné le terminal API concerné dans Okta. C’est ici que les demandes de connexion et API transitent (sans grande manipulation) depuis l’appareil de l’utilisateur, en passant par le cloud, jusqu’au serveur LDAP sur site. Notre première idée a été de tenter une injection LDAP et, comme par hasard, notre stratégie a fonctionné !
Nous avons pu transmettre les noms d’utilisateur entre parenthèses au terminal puis, une fois soigneusement formulés, le serveur LDAP les a interprétés. Bien que cette tactique ne nous ait pas permis de contourner l’authentification, nous avons pu échapper au mécanisme de protection par force brute d’Okta en fournissant une instruction AND TRUE à la fin du nom d’utilisateur.
Notre hypothèse est la suivante : le code de protection par force brute incrémente un compteur chaque fois qu’il ne trouve pas le nom d’utilisateur fourni dans la base de données. En ajoutant AND TRUE (et en le faisant interpréter par le code API), le compteur ne serait pas incrémenté.
Convaincus que la recherche de vulnérabilités devrait illustrer des attaques concrètes, nous avons conclu que cette attaque était réalisable, mais difficilement exploitable en raison des exigences actuelles de complexité des mots de passe. Nous voulions trouver quelque chose de plus efficace.
Création d’un agent secret
Pour des raisons de simplicité, nous allons nous concentrer sur l’agent LDAP, mais nous avons également effectué ces attaques sur d’autres agents de synchronisation, dont l’agent de synchronisation AD.
Deux fichiers sensibles sont présents sur la machine où l’agent de synchronisation Okta est installé. L’un d’eux est le fichier de configuration de l’agent, qui contient un jeton SSWS chiffré à longue durée de vie. L’autre est le fichier journal d’installation, qui contient le nom d’utilisateur et le mot de passe de l’entité privilégiée utilisée par l’agent pour s’authentifier auprès du répertoire local (ces données d’identification se trouvent également dans le fichier de configuration).
Exemple de fichier de configuration de l’agent LDAP
La configuration de l’agent Active Directory est chiffrée à l’aide de la DPAPI (API de protection des données) de Microsoft. L’agent LDAP est quant à lui chiffré à l’aide d’une méthode propriétaire. Dans les deux cas, le déchiffrement du jeton SSWS est facile à exécuter, car nous pouvons voir le code source décompilé de l’agent.
En explorant l’API utilisée par le service cloud d’Okta et l’agent de synchronisation sur site, nous avons constaté qu’il est possible d’utiliser le jeton SSWS déchiffré que nous avons trouvé pour enregistrer un agent de synchronisation malveillant. Ce dernier peut rechercher de nouvelles tentatives de connexion à Okta. Si l’authentification déléguée est activée, lorsqu’un utilisateur tente de se connecter, le service cloud d’Okta envoie la demande de connexion à l’agent malveillant pour approbation.
Les paramètres par défaut des agents AD et LDAP, qui requièrent des demandes de liaison LDAP avec des mots de passe en texte brut pour authentifier l’utilisateur avec le répertoire local, ont permis à notre agent de détourner les données d’identification en texte brut de tous les utilisateurs qui ont tenté de se connecter.
Pas d’authentification déléguée, pas de problème ?
Si l’authentification déléguée n’est pas activée, la synchronisation des mots de passe l’est généralement. Cette fonction synchronise les mots de passe entre Okta et LDAP/Active Directory afin que les employés ne soient pas obligés de mettre à jour leurs mots de passe deux fois.
Le jeton SSWS mentionné précédemment peut également être utilisé pour repérer les changements de mot de passe. Lorsqu’un changement de mot de passe est demandé, Okta fournit l’identifiant de l’utilisateur, son adresse e-mail et son nouveau mot de passe en texte brut. Ces informations sensibles sont chiffrées à l’aide d’une clé qui se trouve également dans la configuration de l’agent.
Le SSWS peut être utilisé indéfiniment sans nuire à la fonctionnalité de l’agent initial. Cela signifie que le même jeton peut être utilisé pour interroger les commandes Okta dans tous les répertoires LDAP et Active Directory intégrés.
Si le provisionnement juste-à-temps (JIP) est activé dans l’intégration du répertoire (cette fonctionnalité implique l’authentification déléguée), toutes les demandes d’authentification dans Okta seront transmises à tous les agents LDAP, aussi bien pour les utilisateurs Okta existants que non existants. Nous avons pu utiliser le jeton SSWS d’un agent LDAP pour accorder l’accès à tous les utilisateurs LDAP et Active Directory. Nous avons également pu l’utiliser pour authentifier les utilisateurs non existants et les enregistrer en tant qu’administrateurs de domaine, en espérant que les administrateurs de domaine Active Directory disposent automatiquement des autorisations privilégiées dans Okta.
Avec cette méthode, il est également possible de contourner la MFA, car il s’agit de la première connexion d’un nouvel utilisateur sans que cette fonctionnalité soit activée. Cette attaque laissera une trace dans les journaux d’Okta, car la plateforme enregistrera les droits d’accès accordés à un nouvel utilisateur.
Lorsque le provisionnement juste à temps est activé, les demandes d’authentification sont uniquement déléguées aux utilisateurs d’Okta. Ces derniers existent dans Okta mais pas dans un répertoire LDAP ou Active Directory. Le super administrateur Okta fait généralement partie de ce type d’utilisateurs. Si nous répondons à la demande, avec notre jeton SSWS compromis, nous pourrions potentiellement accéder au compte de super administrateur Okta.
Les nouveaux agents que nous avons enregistrés sont apparus dans le tableau de bord d’administration d’Okta, ainsi que dans les journaux. Vous pouvez ainsi détecter si un agent secret a été enregistré dans votre environnement.
Une agent malveillant peut s’exécuter de n’importe où, mais les cybercriminels les plus avertis masqueront leur vol de mot de passe en lançant l’attaque depuis l’environnement déjà compromis de la victime. C’est ce que nous avons illustré ci-dessous.
.png?width=333&height=622&name=Blog_VTLOkta_Diagram_MaliciousSyncAgent-DelegatedAuth_V1%20(1).png)
Recommandations pour les équipes chargées de la sécurité du cloud
Il peut être difficile de former les utilisateurs finaux à identifier les attaques de phishing lorsque ces menaces proviennent d’un service légitime. Il va sans dire que la MFA, même si elle n’est pas parfaite, vous offre une grande résilience contre le hameçonnage et les attaques basées sur l’identité. Okta fournit également de nombreuses fonctionnalités pour vous aider à atténuer vos risques :
- activez les alertes d’activités suspectes pour permettre aux utilisateurs finaux de signaler les activités non reconnues à partir des notifications par e-mail de l’activité du compte (par exemple, « Venez-vous d’essayer de réinitialiser votre mot de passe depuis la Roumanie ? »)
- configurez Okta ThreatInsight pour détecter les adresses IP malveillantes qui ciblent les identifiants
- utilisez Okta HealthInsight pour bénéficier de notifications pour les actions clés telles que les inscriptions aux facteurs MFA, les réinitialisations de facteurs, etc
Active Directory est connu pour sa surface d’attaque étendue. Par conséquent, son processus de surveillance doit figurer parmi les éléments clés de votre infrastructure de sécurité afin que vous puissiez identifier les faiblesses (par exemple, les comptes administrateur avec SPN), les erreurs de configuration et détecter les anomalies qui pourraient résulter d’attaques courantes comme Kerberoasting ou de nouvelles attaques comme Secret Agent.
Chaque service cloud comporte des actions essentielles que les équipes de sécurité doivent impérativement connaître. Dans Okta, il convient de savoir si un nouveau super administrateur a été créé ou, comme nous l’avons vu ici, si un nouvel agent de synchronisation a été enregistré afin que vous puissiez valider sa légitimité.
Pour d’autres applications telles que GitHub, Salesforce ou AWS, ces actions clés seront différentes. L’utilisation d’une solution de sécurité SaaS telle que DatAdvantage Cloud, dotée de systèmes/modèles de détection prêts à l’emploi et d’informations sur les erreurs de configuration adaptés à chaque service SaaS, peut vous aider à gérer votre posture en matière de sécurité sur l’ensemble des services cloud et vous alerter en cas d’anomalie.
