Conditional Access est l’une des fonctionnalités de sécurité les plus puissantes de Microsoft et le moteur central de leur architecture Zero Trust. D’après nous cela devrait être la base de toute stratégie Zero Trust des organisations basées sur le cloud. Toutefois, si vous ne comprenez pas comment fonctionne l’accès conditionnel, cela pourrait vous apporter un faux sentiment de sécurité. Dans cet article de blog, nous allons vous montrer pourquoi il est important de comprendre le processus d’évaluation de la politique d’accès conditionnel et comment trouver et exploiter les failles dans la conception d’une stratégie.
À propos de l’accès conditionnel
L’accès conditionnel est une fonctionnalité de Azure AD Premium et il est désactivé par défaut. Il existe une fonctionnalité appelée valeurs par défaut de sécurité qui entre en jeu si aucune stratégie n’est configurée, mais qu’elle n’entre pas dans le champ d’application de cet article. Les valeurs par défaut de sécurité sont elles aussi toujours désactivées lorsque vous avez une ou plusieurs stratégies d’accès conditionnel en place.
Dans l’accès conditionnel, tout est autorisé par défaut. Et même si vous créez une, deux ou trois stratégies, tout ce que vous ne bloquez pas explicitement est autorisé.
Dans presque tous les tenants que nous voyons, il y a des trous dans la conception de l’accès conditionnel parce que les administrateurs se concentrent trop sur les cas d’utilisation qu’ils veulent autoriser, pas sur ce qui devrait être bloqué. Les stratégies d’accès conditionnel sont souvent conçues à l’envers, ce qui rend le tenant vulnérable aux attaques.
Mots de passe et accès conditionnel
Il est important de comprendre que les stratégies d’accès conditionnel dans Azure AD sont évaluées après l’approbation du premier facteur, à savoir le mot de passe utilisateur. Je ne vais pas passer en revue les techniques de vol de mot de passe dans cet article, et tout ce que j’explique ici se produit une fois que le mot de passe a été vérifié avec succès par Azure AD (ou l’AD sur site avec PTA ou ADFS). C’est après le premier facteur que les stratégies d’accès conditionnel sont évaluées, et que l’utilisateur se voit accorder ou refuser l’accès en fonction des exigences des stratégies ciblées.
Fonctionnement de plusieurs stratégies d’accès conditionnel
Dans l’accès conditionnel, toutes les stratégies sont évaluées à chaque connexion. Cela s’applique également lorsque les conditions de chaque stratégie sont remplies. La somme de toutes les exigences de toutes les stratégies correspondantes correspond à ce que l’utilisateur et l’appareil doivent remplir pour obtenir l’accès. Par exemple, une stratégie de correspondance peut nécessiter l’authentification multifacteur et une autre peut exiger que l’appareil soit conforme à Intune. Étant donné que les deux politiques correspondent, les deux exigences doivent être remplies.
La seule priorité parmi les stratégies est que les stratégies de blocage gagnent toujours. Cela signifie que si une ou plusieurs stratégies de blocage correspondent lors d’une connexion, la tentative d’authentification est bloquée, même si d’autres stratégies accordent l’accès en même temps.
Quelques points faibles courants
Bien sûr, la meilleure façon s’attaquer l’accès conditionnel est de ne jamais le déclencher du tout, de l’éviter. Il existe des points faibles communs dans presque toutes les organisations qui peuvent être abusés.
Abus de groupe d’exclusion
Il est recommandé de toujours exclure un groupe de sécurité de toutes les stratégies d’accès conditionnel. Ce groupe devrait contenir deux “Break Glass Account” que vous pouvez utiliser en cas d’urgence. Ce groupe ne devrait pas inclure d’autres comptes, mais en réalité, c’est presque toujours le cas. Les administrateurs deviennent bâclés et s’ajoutent eux-mêmes, des comptes de service ou des utilisateurs plaignants à ce groupe. En volant le mot de passe de l’un de ces comptes, nous pouvons ignorer l’accès conditionnel.
Stratégies de blocage manquantes
Les administrateurs ont tendance à créer des stratégies pour appliquer l’authentification multifacteur pour certaines ou toutes les applications d’un client. Mais ils incluent souvent des conditions dans ces politiques, comme les plates-formes autorisées ou les emplacements autorisés. Ce qu’ils ne comprennent pas, c’est que si nous ne bloquons pas les scénarios indésirables avec une stratégie de blocage correspondante, un attaquant peut simplement usurper l’emplacement ou la plate-forme pour contourner la stratégie et se connecter directement. C’est en grande partie ce que le reste de ce guide présentera.
Voici le message d’erreur général qu’un utilisateur reçoit lorsqu’un accès est refusé par une stratégie de blocage. Notez que le message d’erreur de blocage peut différer selon les conditions de la stratégie de blocage. Il s’agit d’aider l’utilisateur à comprendre ce qui s’est mal passé (voir chaque condition plus bas).
Utilisez la section Plus d’informations pour voir s’il existe des indices sur la condition qui a déclenché le blocage, comme l’emplacement de l’adresse IP, l’état de gestion de l’appareil ou l’application ciblée.
Abus de condition
Les conditions sont utilisées pour déterminer si une politique doit s’appliquer ou non. Si toutes les conditions sont remplies lors de la connexion, les contrôles d’accès de cette stratégie sont appliqués, comme exiger l’authentification multifacteur ou exiger un périphérique conforme. Nous donnons ci-dessous quelques exemples de la façon dont chaque type de condition peut être trompé.
Risque utilisateur / Risque de connexion
Le risque utilisateur et le risque de connexion font partie d’Azure AD Identity Protection (Azure AD Premium P2). Cela signifie que la plupart des clients Microsoft 365 ne l’ont pas activé et que ce ne sera pas un problème pour un attaquant. Mais s’il est activé, l’attaquant doit essayer de se comporter comme l’utilisateur propriétaire du compte volé utilisé dans l’attaque. Azure AD Identity Protection détecte les connexions provenant de nouveaux pays, les adresses IP anonymes, les informations d’identification divulguées marquées en noir, etc. Un attaquant devrait faire des recherches sur l’utilisateur, puis utiliser des VPN et d’autres techniques pour que la connexion apparaisse aussi légitime que possible.
Voici ce que vous voyez si une stratégie de blocage est déclenchée par cette condition :
Plates-formes d’appareils
La plate-forme de l’appareil est facile à usurper. Il est basé sur la chaîne de l’agent utilisateur des applications clientes . Si une stratégie inclut la condition de plate-forme qui nécessite Windows, iOS ou Android, vous pouvez simplement remplacer votre chaîne d’agent utilisateur par n’importe quoi d’autre, comme un appareil Mac, un appareil Linux ou une station spatiale. Il s’agit simplement d’une chaîne de texte et l’accès conditionnel l’interprète pour rechercher le système d’exploitation. Il est recommandé d’avoir une politique de blocage bloquant toutes les plates-formes non souhaitées.
Voici comment vous pouvez modifier votre chaîne d’agent utilisateur avec les outils de développement dans Microsoft Edge :
Voici ce que vous voyez si une stratégie de blocage est déclenchée par cette condition :
Lieux
La condition d’emplacement est basée sur l’adresse IP. C’est ce qu’on appelle les emplacements nommés dans Azure AD et peuvent être définis sur certaines plages d’adresses IP ou sur certains pays. S’il existe une politique bloquant certains pays, un attaquant peut facilement contourner cela avec un service VPN se terminant dans le même pays que l’organisation. S’il existe une politique n’autorisant que des adresses IP particulières comme l’adresse IP publique de l’entreprise, cela devient un peu plus délicat. Si l’attaquant a déjà un pied sur le réseau interne, cela lui permettrait de contourner cela. Étant donné que la plupart des attaques de nos jours proviennent de l’On-Premise, c’est très probable.
Voici ce que vous voyez si une stratégie de blocage est déclenchée par cette condition :
Applications clientes
Les applications clientes signifient des protocoles. Quel protocole le client utilise-t-il lors de l’authentification auprès d’Azure AD. De nombreuses organisations commencent à bloquer les protocoles hérités tels que POP3, IMAPet SMTP en bloquant Other et ActiveSync avec Conditional Access. Mais il y a presque toujours des faiblesses comme les comptes exclus, les “Break Glass Account”, les rôles d’administrateur exclus, etc. Testez différents protocoles pour voir si la tentative est bloquée. Cela peut vous aider à comprendre ce qui est autorisé dans la conception de la stratégie.
L’authentification moderne peut être bloquée à partir d’appareils non gérés et, dans ce cas, vous pouvez essayer d’accéder à un appareil d’entreprise (si le site a été compromis) ou vous pouvez essayer un outil comme AAD Internals qui inclut la possibilité d’ajouter un faux appareil compatible Azure AD et, si nécessaire, d’accorder au client cible. Vous pourriez avoir de la chance de tirer une telle attaque de.
L’accès au navigateur n’est presque jamais bloqué par qui que ce soit, de sorte que les portails du navigateur seraient probablement votre chemin.
Voici ce que vous voyez si une stratégie de blocage est déclenchée par cette condition :
État de l’appareil
La condition d’état de l’appareil n’est pas applicable car elle exclut et n’inclut jamais que les périphériques.
Abus de contrôle d’accès
Si vous avez de la chance, vous avez pu contourner toutes les conditions implémentées ci-dessus. Dans ce cas, vous êtes déjà connecté et n’aurez pas besoin de lire plus loin. Mais s’il y a des politiques tenaces sur le chemin, votre prochaine étape serait d’abuser des contrôles d’accès. C’est plus difficile et nécessite un peu plus de travail.
Lorsque toutes les conditions d’une stratégie correspondent, les exigences sous Contrôles d’accès dans cette stratégie doivent être remplies, sinon la tentative d’authentification est bloquée. Une stratégie peut avoir une ou plusieurs exigences, et la stratégie peut être définie pour exiger que l’une d’entre elles ou toutes soient remplies. Comme nous l’avons mentionné précédemment, plusieurs stratégies peuvent également correspondre en même temps et nécessitent des contrôles différents. Dans ce cas, toutes les différentes exigences des stratégies doivent être remplies.
Exiger une authentification multifacteur
C’est de loin le contrôle d’accès le plus couramment utilisé. Il exige que l’utilisateur vérifie son identité auprès de l’authentification multifacteur. Il existe de nombreuses attaques MFA connues telles que le vol de jetons MFA, l’abus de télécommunications (transfert OTP SMS) et différentes techniques de phishing pour inciter l’utilisateur à approuver MFA. Un attaquant devrait réussir dans l’une de ces techniques d’attaque pour y accéder. Notez que le contrôle d’accès MFA se déclenche toujours lorsqu’il est activé, même si l’un des autres contrôles d’accès s’applique également mais échoue. Ces messages d’échec sont affichés après la vérification MFA. Il s’agit de protéger le tenant contre les attaques de fuzzing d’accès conditionnel.
Vous savez que vous êtes ciblé par ce contrôle d’accès lorsque vous voyez ceci :
Exiger un appareil hybride joint à Azure AD
Cette condition nécessite un tenant hybride avec des périphériques synked sur site. Lorsque vous voyez ce message, vous savez que le client est un hybride. Pour contourner cette exigence, vous pouvez lancer l’attaque sur site. Un appareil sur site est probablement déjà joint à Azure AD hybride. Notez que ce message d’erreur de contrôle d’accès s’affiche toujours avant le message d’erreur de conformité Intune si les deux sont activés.
Vous savez que vous êtes ciblé par ce contrôle d’accès lorsque vous voyez ceci :
Exiger que l’appareil soit marqué comme conforme
S’il est obligatoire que l’appareil soit conforme aux stratégies Intune, il existe deux façons de procéder. Vous pouvez utiliser un appareil d’entreprise compromis inscrit auprès d’Intune et exécuter l’attaque à partir de là, ou vous pouvez essayer d’enregistrer un faux appareil avec un outil comme AAD Internals pour y accéder. Notez que si ce message d’erreur s’affiche lorsque vous essayez de vous connecter à partir d’un appareil non géré, aucune stratégie ne nécessite la jonction Azure AD hybride.
Vous savez que vous êtes ciblé par ce contrôle d’accès lorsque vous voyez ceci :
Exiger une application cliente approuvée
Ce contrôle d’accès est uniquement pour iOS et Android et ne fonctionnera pas avec d’autres plates-formes. Il s’assure que l’utilisateur se connecte avec une application Microsoft approuvée à partir de l’App Store. Contournez cela en utilisant Windows ou Linux.
Exiger une stratégie de protection des applications
Cela nécessite la protection des applications Intune. Cela ne peut être appliqué qu’à Android et iOS afin qu’un attaquant puisse simplement utiliser Windows ou Linux à la place.
