Nos partenaires
En août 2022, l'équipe de Vectra a identifié une opportunité de post-exploitation permettant à des acteurs malveillants disposant d'un accès suffisant au système de fichiers local ou distant de voler des informations d'identification d'utilisateurs valides dans Microsoft Teams en raison de leur stockage en clair sur le disque. Il a été déterminé que cette gestion des informations d'identification en texte clair avait un impact sur tous les clients commerciaux et GCC Desktop Teams pour Windows, Mac et Linux.
Alors que la collecte d'informations d'identification à partir de la mémoire est une étape post-exploitation courante, nous pensons que l'abaissement de la barre nécessaire pour collecter des informations d'identification à un simple accès en lecture au système de fichiers élargit les possibilités pour un adversaire, simplifie sa tâche et est particulièrement intéressant lorsque les informations d'identification volées offrent la possibilité de conserver l'accès de l'utilisateur sans être encombré par des ralentisseurs d'authentification multifactorielle (MFA) qui seraient autrement gênants.
Avec ces jetons, les attaquants peuvent assumer l'identité du détenteur du jeton pour toutes les actions possibles via le client Microsoft Teams, y compris l'utilisation de ce jeton pour accéder aux fonctions de l'API Microsoft Graph à partir du système d'un attaquant. En outre, ces jetons sont également valables avec les comptes MFA, ce qui permet de contourner les contrôles MFA lors d'une utilisation continue.
Microsoft est au courant de ce problème, mais a indiqué qu'il ne répondait pas à ses critères d'intervention immédiate. En attendant que Microsoft mette à jour l'application de bureau Teams, nous pensons que les clients doivent être conscients des risques posés par le stockage de jetons en clair et atténuer ce risque en instrumentant la surveillance de l'accès inhabituel aux fichiers ou de la modification des listes de contrôle d'accès au système de fichiers.
La genèse de la chasse
L'enquête a débuté lorsqu'un client de Vectra s'est plaint de la façon dont Microsoft Teams gère les identités désactivées. Les utilisateurs finaux ne peuvent pas supprimer les comptes désactivés via l'interface utilisateur, car l'application Teams exige que le compte soit connecté pour le supprimer du client. Bien entendu, les utilisateurs ne peuvent pas le faire lorsque leur compte est désactivé. Pour résoudre ce problème, nous avons commencé à examiner les données de configuration locales à l'intérieur du client Teams et à démêler leur fonctionnement.
Electron - un négatif de sécurité
Microsoft Teams est une application basée sur Electron. Electron fonctionne en créant une application web qui s'exécute via un navigateur personnalisé. C'est très pratique et cela rend le développement rapide et facile. Cependant, l'exécution d'un navigateur web dans le contexte d'une application nécessite des données de navigateur traditionnelles telles que des cookies, des chaînes de session et des journaux.
C'est là que réside la racine du problème, car Electron ne prend pas en charge les contrôles standard des navigateurs, tels que le cryptage, et les emplacements de fichiers protégés par le système ne sont pas pris en charge par Electron dès le départ, mais doivent être gérés efficacement pour rester sécurisés. Par conséquent, le mode de fonctionnement d'Electron incite par défaut à créer des applications trop transparentes. Étant donné qu'Electron obscurcit les complexités de la création d'une application, on peut supposer que certains développeurs ne sont pas conscients des ramifications de leurs décisions de conception et il est courant d'entendre des chercheurs en sécurité des applications déplorer l'utilisation de ce cadre en raison d'oublis critiques en matière de sécurité.
Plonger dans la structure
Nous avons d'abord commencé à explorer les méthodes permettant de supprimer toute référence au(x) compte(s) connecté(s). Notre objectif était de supprimer les anciens comptes et de forcer les équipes à fonctionner comme s'ils n'existaient plus. De multiples tentatives de modification du fichier de configuration et des fichiers de première exécution n'ont rien donné. En guise d'essai, nous avons recherché le nom principal de l'utilisateur connu, et deux fichiers critiques ont été trouvés.
Le premier fichier important était un fichier ldb contenant des jetons d'accès en texte clair. Après examen, il a été déterminé que ces jetons d'accès étaient actifs et qu'il ne s'agissait pas d'une vidange accidentelle d'une erreur précédente. Ces jetons d'accès nous ont permis d'accéder aux API Outlook et Skype. Il est important de savoir que l'architecture Microsoft Teams est un conglomérat d'une grande variété de services M365 qui s'appuie sur Skype, SharePoint et Outlook pour fonctionner, ce qui explique la présence de ces jetons.
Le fichier suivant est une base de données de cookies du navigateur, comme les "cookies" que nous acceptons sur chaque site web (merci, RGPD). Les cookies stockent des données telles que des informations de session, des balises marketing, des informations de compte et, dans certains cas, des jetons d'accès. Heureusement, l'application Teams Desktop stocke également les jetons dans ce fichier.
La meilleure façon de lire la base de données des cookies est d'utiliser un client de base de données sqlite3. Avec ce client, nous pouvons extraire uniquement les valeurs dont nous avons besoin. La requête suivante renvoie le nom et la valeur du jeton.
Nous avons évalué chaque jeton par rapport au service de validation jwt de Microsoft, https://jwt.ms. Chaque jeton que nous avons trouvé était actif et fonctionnait sans nécessiter d'authentification supplémentaire. Nous avons commencé à réaliser que le problème initial lié à la réinstallation de Teams était beaucoup moins important que l'abus d'identité qui se profilait dans le client Teams de Microsoft.
Faisons quelque chose
L'équipe s'est mise au travail avec ces connaissances et a commencé à concevoir des outils qui tirent parti de ces informations d'identification non protégées. Après avoir envisagé plusieurs options, il a été déterminé qu'il serait approprié d'envoyer un message au compte du détenteur de l'accréditation par l'intermédiaire de Teams avec un jeton d'accès. Avec cet objectif en tête, nous avons lancé le client Teams dans le navigateur pour suivre les appels d'API lors de l'envoi de messages et nous avons trouvé ce joyau :
https://amer.ng.msg.teams.microsoft.com/v1/users/ME/conversations/48:notes/messages
Cette API endpoint nous permet d'envoyer des messages à nous-mêmes, et nous n'avons pas à nous préoccuper de l'énumération des comptes. Ensuite, nous avons eu besoin du jeton d'accès. Nous avons utilisé le moteur SQLite. SQLite ne nécessitant pas d'installation, l'outil télécharge SQLite dans un dossier local et l'exécute pour lire la base de données Cookies, où nous extrayons le jeton d'accès Skype nécessaire à l'envoi de messages.
Avec le jeton en main et notre destination en tête, la dernière étape consistait à rédiger un message. Le corps de la requête a pris du temps à fonctionner, mais nous avons finalement réussi. Nous avons configuré le message pour qu'il soit envoyé avec l'indicateur d'importance élevée et l'objet " You've Been PWND " (Vous avez été victime d'un abus de confiance). Le message lui-même est le jeton d'accès Skype.
L'outil envoie le message à ce stade, et nous pouvons valider que le jeton d'accès se trouve dans notre chat personnel.
Ce n'est pas si mal pour une matinée de travail.
Les implications des références non sécurisées
Microsoft stocke ces informations d'identification pour créer une expérience d'authentification unique transparente dans l'application de bureau. Cependant, la mise en œuvre de ces choix de sécurité abaisse la barre.
Toute personne qui installe et utilise le client Microsoft Teams dans cet état stocke les informations d'identification nécessaires pour effectuer toutes les actions possibles via l'interface utilisateur Teams, même lorsque Teams est fermé. Lorsque ces jetons sont volés, les attaquants peuvent modifier les fichiers SharePoint, le courrier et les calendriers Outlook, ainsi que les fichiers de discussion Teams. Les attaquants peuvent altérer les communications légitimes au sein d'une organisation en les détruisant de manière sélective, en les exfiltrant ou en lançant des attaques ciblées sur le site phishing .
The Big Scary -The Ultimate Phish
Ce qui nous effraie vraiment, c'est la prolifération des jetons d'utilisateur post-MFA dans un environnement - elle permet à des attaques ultérieures qui ne nécessitent pas d'autorisations spéciales supplémentaires ou de malware avancé de s'en tirer avec des dommages internes importants. Avec suffisamment de machines compromises, les attaquants peuvent orchestrer les communications au sein d'une organisation. En prenant le contrôle total des postes critiques - comme le chef de l'ingénierie, le PDG ou le directeur financier d'une entreprise - les attaquants peuvent convaincre les utilisateurs d'effectuer des tâches préjudiciables à l'organisation. Comment pratiquez-vous les tests d'hameçonnage dans cette optique ?
Recommandations
Aux administrateurs
Équipes de base, gestion des configurations et contrôle des modifications des listes de contrôle d'accès (ACL)
Traiter les équipes comme une application critique et appliquer les ACL qui la protègent. La modification de ces ACL pour étendre l'accès aux fichiers en lecture en dehors de l'utilisateur prévu exposera effectivement les informations d'identification de cet utilisateur à l'une des actions malveillantes soulignées ci-dessus.
Une fois que Microsoft a mis à jour les applications Electron Teams, il est toujours essentiel de passer à un modèle à forte restriction pour empêcher l'installation d'applications Teams non autorisées, de bots, de connecteurs, etc.
Suivi de l'accès aux fichiers
Créez une règle de surveillance du système pour identifier les processus qui accèdent à ces fichiers sensibles. Il existe deux recommandations spécifiques concernant les fichiers/dossiers :
- Windows] %AppData%\Microsoft\Teams\Cookies
- Windows] %AppData%\NMicrosoft\NTeams\NStockage local\Nleveldb
- [macOS] ~/Bibliothèque/Application Support/Microsoft/Teams/Cookies
- [macOS] ~/Bibliothèque/Application Support/Microsoft/Teams/Local Storage/leveldb
- Linux] ~/.config/Microsoft/Microsoft Teams/Cookies
- Linux] ~/.config/Microsoft/Microsoft Teams/Stockage local/leveldb
Si un processus autre que Teams.exe accède à ces fichiers, cela indique que les données stockées sont consultées en dehors du contexte de l'application Teams.
Considérer l'application Web comme une alternative
Si le baselining et la surveillance ne sont pas pratiques, envisagez d'utiliser le client Teams basé sur le web dans Microsoft Edge, qui dispose de plusieurs contrôles au niveau du système d'exploitation pour protéger les fuites de jetons. Heureusement, l'application web Teams est robuste et prend en charge la plupart des fonctions activées par le client de bureau, ce qui réduit au minimum les impacts sur la productivité de l'organisation.
Pour les utilisateurs de Linux, il s'agit de la voie recommandée car Microsoft a annoncé la fin de vie de Teams pour Linux en décembre 2022.
Aux développeurs
Si vous devez utiliser Electron pour votre application, assurez-vous de stocker les jetons OAuth de manière sécurisée. L'une des méthodes de stockage des secrets consiste à utiliser le paquet KeyTar, qui exploite les mécanismes de sécurité du système d'exploitation local pour la gestion des secrets.
Comment stocker en toute sécurité des informations sensibles dans Electron avec node-keytar | par Cameron Nokes | Cameron Nokes | Medium
À Microsoft
Si vous devez stocker les jetons, faites-le de manière cryptée et relevez la barre d'un simple accès en lecture au système de fichiers en exigeant un accès permanent à la mémoire. Et s'il vous plaît, permettez-nous de supprimer les comptes désactivés de l'application Teams sans avoir à procéder à une désinstallation/réinstallation complète.
Aux équipes de sécurité
Pour arrêter un attaquant qui exploiterait ce type d'exploit, les équipes devraient investir dans des solutions de détection des menaces et de réponse qui peuvent voir les types d'actions avant et après l'exploitation de l'exploit. La plateforme de détection et de réponse aux menaces de Vectra détecterait les tactiques de commandement et de contrôle attendues avant cet exploit et toute reconnaissance du réseau, tout mouvement latéral ou toute exfiltration qui se produirait après l'exploit. Sur cloud, Vectra alerterait sur les activités de l'attaquant utilisant les informations d'identification compromises dans Azure AD, y compris les privilèges dans Azure AD, les attaques à grande échelle contre les fournisseurs de services connectés cloud comme AWS, et les attaques contre d'autres applications Microsoft 365, y compris Exchange, SharePoint et Power Automate.
Détection et réponse aux menaces pour Azure AD
Pour en savoir plus sur la manière dont Vectra peut détecter et arrêter les menaces, veuillez consulter le site : https://www.vectra.ai/products/platform