Autorisations d'API dangereuses affectant le tenant
High
Langue :
Description
Microsoft expose des API par l'intermédiaire d'applications dans Entra ID pour permettre à des applications tierces d'effectuer des actions au sein de Microsoft Entra ID, de Microsoft 365 (O365), du cloud Azure, etc. Des « autorisations d'API » protègent l'accès à ces API, et seuls les principaux de service qui en ont besoin peuvent les obtenir. L'approbation des autorisations s'appelle « attribution de rôle d'application » ou « octroi d'autorisation ».
Certaines autorisations sur certaines API Microsoft (voir ci-dessous) peuvent représenter une grave menace pour l'ensemble du tenant Microsoft Entra ID, car un principal de service qui dispose de ces autorisations devient très puissant, tout en étant plus discret qu'un utilisateur disposant d'un rôle d'administrateur puissant tel que l'Administrateur général. En exploitant ces autorisations, un attaquant peut contourner l'authentification multifacteur (MFA) et résister aux réinitialisations de mot de passe des utilisateurs.
Lorsqu'elles sont légitimes, les autorisations augmentent la surface d'attaque pour le tenant. Lorsqu'elles ne le sont pas, il peut s'agir d'une tentative malveillante d'élévation de privilèges ou d'une méthode de persistance.
Il existe deux types d'autorisations d'API dans Microsoft Entra ID, comme décrit dans la documentation Microsoft Présentation des autorisations et du consentement :
- Autorisations d’application : le consentement est donné par les administrateurs et les autorisations s'appliquent à l'ensemble du tenant (locataire).
- Autorisations déléguées : le consentement est donné par les utilisateurs ou les administrateurs au nom de l'ensemble de l'organisation. Notez que ces autorisations limitent la possibilité pour une application d'effectuer des actions, sur la base des privilèges de l'utilisateur connecté (autrement dit, ses possibilités se limitent à l'intersection de l'autorisation et du niveau de privilège de l'utilisateur). Par conséquent, la dangerosité de ces autorisations déléguées dépend des autorisations réelles de l'utilisateur de l'application, comme décrit dans la section Développement d'une stratégie de délégation des autorisations. Exemple : si un utilisateur standard délègue l'autorisation « Group.ReadWrite.All », l'application peut modifier uniquement les groupes que l'utilisateur peut modifier et non pas tous les groupes.
Cet indicateur d'exposition examine les deux types d'autorisations. Il ne porte que sur les principaux de service, car les autorisations d'API ne peuvent s'appliquer qu'aux principaux de service, et non pas aux utilisateurs.
Cet indicateur d'exposition porte également sur les autorisations qui permettent d'accéder à l'API Microsoft Graph et à l'API Azure AD Graph obsolète. En particulier, les autorisations dangereuses suivantes peuvent présenter un risque de sécurité :
RoleManagement.ReadWrite.Directory: permet aux attaquants d'acquérir le rôle d'Administrateur général.AppRoleAssignment.ReadWrite.All: : permet aux attaquants de s'accorder l'autorisationRoleManagement.ReadWrite.Directory(voir ci-dessus).
Les applications légitimes disposant de ces autorisations dangereuses demandent des autorisations qui peuvent être trop larges. Ce peut également être le signe d'une attaque par hameçonnage appelée « octroi d'autorisation illicite », au cours de laquelle un attaquant réussit à obtenir le consentement d'un administrateur.
Solution
Commencez par déterminer si le principal de service signalé avec l'autorisation est légitime. Notez qu'il est techniquement possible d'usurper le nom d'affichage dans une attaque par hameçonnage. Si le principal de service semble appartenir à un éditeur de logiciels connu, demandez-lui de confirmer que l'ID d'application signalée lui appartient. Si le principal de service est illégitime et qu'il usurpe le nom d'une application connue, vous devez effectuer une analyse forensique.
- Si le principal de service est légitime, identifiez son propriétaire et son rôle, afin de déterminer s'il a réellement besoin de ces autorisations dangereuses. S'il s'agit d'une application interne, selon ses fonctionnalités, réduisez les autorisations en appliquant la bonne pratique du principe du moindre privilège, comme décrit dans la section relative au consentement et aux autorisations de la documentation de l'API Microsoft Graph, qui décrit spécifiquement les autorisations minimales requises pour chaque API. S'il s'agit d'une application tierce, demandez à l'éditeur d'abaisser les autorisations requises ou, au moins, d'expliquer pourquoi elles sont nécessaires.
- Par défaut, tous les utilisateurs peuvent déléguer des autorisations à n'importe quelle application, ce qui les laisse prendre des décisions de sécurité sensibles. Microsoft Entra ID fournit des options que vous pouvez activer pour configurer le consentement utilisateur. Lorsque vous activez des restrictions, les administrateurs Microsoft Entra ayant certains rôles doivent gérer le consentement accordé aux applications et évaluer les demandes de consentement. Voir aussi comment examiner les demandes de consentement de l'administrateur.
- Les autorisations des applications nécessitent toujours le consentement de l'administrateur. Formez ces administrateurs à l'identification des applications suspectes et des autorisations sensibles, en ciblant particulièrement les autorisations d'application au niveau du tenant, ainsi que les autorisations déléguées par des utilisateurs privilégiés ou sensibles. Cette démarche doit s'inscrire dans le cadre d'un effort plus large de gouvernance des applications.
- Retirez une autorisation si vous pensez qu'elle n'est pas légitime. Tenable recommande de sauvegarder d'abord les preuves si vous prévoyez d'effectuer une analyse forensique plus approfondie. Le portail Microsoft Entra ID dispose d'une fonction dédiée permettant de passer en revue les autorisations accordées aux applications d'entreprise.
Microsoft a également publié deux guides pour vous aider à effectuer un examen d’octroi de consentement d’application et à détecter et corriger les octrois de consentement illicites.