Il est bien connu depuis des années que les réseaux locaux Windows Active Directory sont vulnérables aux soi-disant relais NTLM (New Technology Lan Manager) et aux attaques de type pass-the-hash qui peuvent permettre aux attaquants de se déplacer latéralement au sein des réseaux et d’accéder à davantage de machines. et ressources.
Étant donné que certaines de ces attaques exploitent des compromis de conception dans les protocoles utilisés dans le réseau Windows, elles ne peuvent tout simplement pas être corrigées avec un logiciel mis à jour. Pour se protéger, les organisations doivent appliquer une défense plus profonde et prendre des mesures qui impliquent des configurations plus strictes et davantage de contrôles.
Avec l’adoption de réseaux hybrides, où des parties du réseau sont sur site et d’autres dans le cloud, les entreprises doivent s’appuyer sur des services tels qu’Azure Active Directory (Azure AD) pour permettre à différentes machines de s’authentifier les unes auprès des autres. Cependant, Azure AD est assez différent d’un AD sur site car il utilise différents protocoles et est livré avec de nouvelles fonctionnalités qui étendent les capacités réseau des organisations. Mais selon plusieurs présentations lors de la conférence sur la sécurité Black Hat USA de l’année dernière, cela ouvre également de nouvelles ouvertures pour les attaquants.
Från pass-the-hash jusqu’à pass-the-certificate
Pass-the-hash est une attaque où les pirates extraient des versions hachées des informations d’identification stockées localement à partir de machines compromises et les utilisent pour s’authentifier auprès d’autres machines. Le relais NTLM est une méthode dans laquelle vous relayez les demandes d’authentification entre un client et un serveur et transférez les messages entre les deux parties afin que l’attaquant soit authentifié à la place du client. Ces méthodes d’attaque sont souvent utilisées par des groupes de pirates sophistiqués dans des attaques ciblées.
Cependant, les attaques traditionnelles de type pass-the-hash et relais ne fonctionneront pas contre Azure AD, car Azure AD n’utilise pas NTLM ou Kerberos (les protocoles par défaut utilisés lors de l’authentification sur les réseaux Windows), mais Azure AD utilise OAuth, SAML, OpenID et un nouveau protocole appelé NegoEx qui à son tour est une extension du protocole standardisé Generic Security Services Application Program Interface (GSSAPI) sur lequel Kerberos est basé.
Selon le chercheur de Microsoft Mor Rubin, NagoEx sera activé sur tous les appareils joints à Azure AD et constitue le mécanisme par lequel différents appareils joints à Azure AD s’authentifient les uns les autres. La poignée de main d’authentification dans NegoEx repose sur un certificat client unique à chaque utilisateur et émis par Azure AD avec une validité d’une heure.
Lors de la conférence Black Hat, Rubin a démontré comment une attaque relais peut être effectuée contre une poignée de main NegoEx de la même manière qu’elle peut être effectuée contre NTLM. Il a ensuite montré comment un attaquant peut obtenir le certificat peer-to-peer du client, puis utiliser ce certificat pour s’authentifier auprès d’autres machines. En d’autres termes, ces attaques sont équivalentes aux attaques NTLM, relais et pass-the-hash, mais dans le contexte des appareils joints à Azure AD, quelles que soient les différences dans les protocoles utilisés.
Rubin suggère aux entreprises de vérifier les journaux de leurs machines Azure AD pour les demandes d’authentification de clients dont les noms et les adresses IP ne correspondent pas, ou pour les demandes d’authentification via des certificats délivrés à des utilisateurs non associés à la machine effectuant la demande. La présentation de Rubin était l’aboutissement de la recherche qu’il avait commencée l’année dernière et était également une première pour l’outil Négoexrelaisxqui est un outil relais pour NegoEx sous licence open source.
Tirer parti des identités externes dans Azure AD
Dans une autre présentation lors de la conférence Black Hat, axée sur des attaques Azure AD spécifiques non présentes dans les installations AD sur site, le chercheur néerlandais Dirk-Jan Mollema d’Outsider Security a démontré comment il trouvé un moyen d’exploiter la fonctionnalité avec des identités externes pour créer une porte dérobée vers les comptes Azure AD.
Les identités externes sont une fonctionnalité d’Azure AD que les organisations peuvent utiliser pour accorder aux utilisateurs externes l’accès à certaines ressources. Ces utilisateurs peuvent appartenir à une autre partie d’Azure AD ou ils peuvent être authentifiés par un fournisseur externe et identifiés uniquement par une adresse e-mail. Cette fonctionnalité est populaire parmi les organisations qui travaillent avec des consultants externes, mais également pour fournir un accès aux fournisseurs de services informatiques qui gèrent les abonnements.
Les utilisateurs externes peuvent être invités par une personne disposant de droits d’administrateur via l’interface Azure AD, ce qui génère un lien d’invitation qui est envoyé par e-mail à l’utilisateur externe. Le problème, selon Mollema, est que les invitations peuvent également être générées et acceptées par programmation via l’API d’Azure AD appelée AAD Graph.
Il est également apparu que peu de vérifications étaient effectuées lors de l’interaction avec cette fonction via l’API. Premièrement, tout utilisateur au sein d’un service Azure AD peut interroger l’API et voir quelles invitations n’ont pas été échangées jusqu’à présent, deuxièmement, toute invitation peut être échangée via l’API sans aucune validation et peut être liée à un compte externe différent de celui prévu. Troisièmement, les administrateurs n’avaient aucun moyen de déterminer si une invitation avait été détournée via l’interface.
L’attaque a également pu contourner la liste des domaines autorisés pour les collaborations externes dans le département Azure AD, car l’invitation pouvait être générée pour une adresse e-mail au sein d’un domaine, mais ensuite détournée et liée à un compte qui ne figurait pas sur la liste. En prime, il peut y avoir des règles automatiques qui donnent automatiquement à un compte qui utilise une invitation un niveau de privilège plus élevé, entraînant une escalade des privilèges.
Mollema a ensuite poussé l’attaque un peu plus loin. En analysant l’apparence des identités externes dans Microsoft Graph – une API pour les développeurs – au lieu d’AAD Graph, Mollema s’est rendu compte que certaines des propriétés associées à une identité pouvaient être modifiées via MS Graph, avec les privilèges appropriés. L’un de ces attributs est une propriété de l’éditeur qui définit le fournisseur d’identité, et l’un des choix était simplement « e-mail ». Ceci est utilisé pour les utilisateurs externes qui ne sont identifiés que par leur adresse e-mail et qui n’ont pas encore de compte Microsoft ou Azure AD.
Ensuite, Mollema a examiné qui pouvait modifier ces attributs et a découvert qu’en plus des administrateurs, les applications auxquelles les utilisateurs se connectent et disposent des privilèges appropriés pouvaient également modifier les identités, et les utilisateurs pouvaient également modifier leurs propres identités via MS Graph. Cela a ouvert la porte à des attaques intéressantes, telles que la mise en place de portes dérobées dans des comptes existants si un attaquant y accède temporairement en volant un jeton d’accès ou en prenant temporairement le contrôle d’un ordinateur sur lequel l’utilisateur a une session active.
De plus, si le compte se trouve être l’administrateur de l’utilisateur, les attaquants peuvent créer des portes dérobées pour tous les comptes en leur ajoutant des identités externes et en les liant aux adresses e-mail que les attaquants contrôlent. Ils peuvent également le faire pour les administrateurs globaux car ils ont le droit de modifier leurs identités via MS Graph.
L’inconvénient de modifier une identité de cette manière est qu’elle change uniquement la méthode d’authentification principale du nom d’utilisateur et du mot de passe à l’authentification via une adresse e-mail externe. Si le compte est également sécurisé avec une authentification multifacteur, l’attaquant ne peut toujours pas se connecter.
Mais Mollema a également trouvé un moyen de contourner cela. Tout d’abord, il a utilisé le compte victime temporairement compromis pour générer une invitation pour le compte externe de l’attaquant. L’attaquant a ensuite accepté l’invitation, ce qui a entraîné la création d’un compte invité pour l’attaquant dans le service de la victime. L’attaquant s’est ensuite connecté avec le compte invité et a configuré l’authentification multifacteur pour ce compte.
L’attaquant a ensuite supprimé le compte invité en utilisant le compte de la victime. Étant donné que cela supprime le compte invité associé au compte externe de l’attaquant, cela n’efface pas le jeton multifacteur du compte, mais reste dans une mémoire tampon. Ainsi, le compte externe de l’attaquant continue d’avoir un jeton actif dans la partition Azure AD de la victime même si le compte invité associé a disparu. L’attaquant peut alors créer une porte dérobée vers le compte de la victime et ajouter son compte en tant qu’identité, puis l’attaquant n’aura plus besoin de s’authentifier à l’aide de l’authentification multifacteur. Ceci complète la protection multifactorielle de la victime.
Comment atténuer les vulnérabilités d’authentification cloud dans Azure AD et autres
Microsoft a déjà créé des mises à jour contre les vulnérabilités découvertes par Mollema, de sorte que les attaques qu’il a décrites ne fonctionnent plus. Mais ses découvertes montrent à quel point l’authentification peut être complexe dans les nouveaux environnements cloud. L’introduction de nouvelles fonctionnalités, telles que l’autorisation de mots de passe à usage unique par e-mail en tant que fournisseur d’identité ou d’identités externes, peut toujours entraîner des erreurs logiques pouvant ouvrir des raccourcis.
Mollema conseille aux organisations de supprimer régulièrement tous les comptes d’invités avec des invitations non échangées, de verrouiller le droit de créer des invitations d’invités et pour les paramètres des droits des invités, de limiter les départements Azure AD qui peuvent collaborer en externe, de mettre en œuvre une authentification multifacteur pour toutes les applications et d’examiner les journaux d’accès. pour des signes d’utilisation potentielle des comptes invités.
