Autorisations déléguées dangereuses affectant les données

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) et de services tels que SharePoint Online and Exchange Online. Des « autorisations d'API » protègent l'accès à ces API, qui doivent être disponibles uniquement pour les principaux de service qui en font la demande. L'approbation des autorisations s'appelle « attribution de rôle d'application » ou « octroi d'autorisation ».

Plusieurs autorisations sur certaines API Microsoft peuvent représenter une menace pour les données sensibles à l'environnement, car un principal de service qui dispose de ces autorisations peut accéder à des informations potentiellement sensibles, tout en étant plus discret qu'un utilisateur disposant d'un rôle d'administrateur puissant tel que l'Administrateur général.

Lorsqu'elles sont légitimes, ces autorisations augmentent le risque de compromission des données. Lorsqu'elles ne le sont pas, elles peuvent indiquer une tentative malveillante d'accès et de vol de données sensibles, telles que des e-mails et des projets.

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 : voir l'indicateur d'exposition connexe « Autorisations d'application dangereuses affectant les données ».
• Autorisations déléguées : cet indicateur d'exposition examine ce second type, voir l'indicateur d'exposition connexe « Autorisations déléguées dangereuses affectant le tenant » pour les menaces pour l'ensemble du tenant Microsoft Entra. 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, le niveau de danger que représentent 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. Microsoft les décrit comme suit :

Les autorisations déléguées sont utilisées par les applications qui disposent d'un utilisateur connecté et qui peuvent faire appliquer des consentements par l'administrateur ou l'utilisateur.

Cet indicateur d'exposition (IoE) ne porte que sur les principaux de service, car les autorisations d'API s'appliquent uniquement aux principaux de service, et non pas aux utilisateurs.

Cet IoE identifie une liste d'autorisations sensibles, dont la plupart sont explicites. Cependant, les autorisations suivantes nécessitent des informations supplémentaires :

• Group.Read.All (exposée par l'API Microsoft Graph et Office 365 Exchange Online) : cette autorisation est extrêmement risquée, car elle permet de lire même le contenu des groupes M365 « calendrier, conversations, fichiers et autre contenu de groupe ». Tenez compte des implications pour les groupes M365 utilisés par Microsoft Teams.

Les applications légitimes disposant de ces autorisations sensibles demandent un accès qui peut être trop large. Ce peut également être le signe d'une attaque par hameçonnage appelée « octroi d'autorisation illicite », au cours de laquelle un attaquant obtient le consentement d'un administrateur.

Par défaut, cet IoE ignore les principaux de service désactivés, car les attaquants ne peuvent pas les utiliser immédiatement.

Références externes :

• Cloudbrothers - Azure Attack Paths (Cloudbrothers - Chemins d'attaque Azure)
• Microsoft - Exchange Web Server API abuse (Microsoft - Abus de l'API Exchange Web Server)
• Threat actors misuse OAuth applications to automate financially driven attacks (Les attaquants font un usage abusif des applications OAuth pour automatiser des attaques motivées par un gain financier)

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 s'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 sensibles.
    • S'il s'agit d'une application interne, évaluez ses fonctionnalités et réduisez les autorisations en suivant le principe du moindre privilège, comme indiqué dans la section Consentement et autorisation de la documentation de l'API Microsoft Graph. Ces conseils précisent les autorisations minimales requises pour chaque API.
    • S'il s'agit d'une application tierce, confirmez que l'accès aux données est approprié pour cette application (même périmètre). Si ce n'est pas le cas, demandez au fournisseur de documenter la raison pour laquelle ces autorisations sont nécessaires et si elles peuvent être supprimées de manière sécurisée.
  • En guise de mesure de défense en profondeur, si vous disposez des licences Workload Identities Premium requises, envisagez d'utiliser l'Accès conditionnel pour les identités de charge de travail. Cela vous permet de limiter les principaux de service à haut risque à des emplacements approuvés connus et de limiter l'accès en fonction des connexions risquées.

• Par défaut, tous les utilisateurs peuvent déléguer des autorisations à n'importe quelle application, ce qui leur permet de prendre des décisions de sécurité sensibles. Reportez-vous à l'indicateur d'exposition « Consentement non restreint des utilisateurs pour les applications » correspondant. 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.

• Formez les administrateurs à l'identification des applications suspectes et des autorisations sensibles, notamment les autorisations déléguées d'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. Veuillez suivre les conseils de Microsoft et passer en revue les autorisations accordées aux applications d'entreprise. Malheureusement, cette fonctionnalité n'est plus disponible sur le portail d'administration Microsoft Entra :

Vous ne pouvez pas annuler les autorisations depuis l'onglet « Consentement utilisateur » via le portail d'administration Microsoft Entra. Toutefois, vous pouvez retirer ces autorisations via des appels à l'API Microsoft Graph ou des cmdlets PowerShell. Pour plus de détails, reportez-vous aux sections concernant PowerShell et Microsoft Graph de cet article.

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.

Veillez à supprimer l'autorisation sensible à partir du principal de service (disponible dans le menu « Applications d'entreprise » du portail) et non pas de l'application (disponible dans le menu « Inscriptions d'applications »). Sa suppression depuis l'application entraîne la suppression de la demande d'autorisation et n'affecte pas l'attribution réelle des autorisations.

Enfin, activez les journaux d'activité de l'API Graph pour collecter des informations détaillées sur les événements de l'API Graph, afin d'aider votre SOC ou votre SIEM à identifier les activités suspectes ou à mener des investigations forensiques en cas d'attaque. Vous devez également surveiller les connexions des principaux de service et configurer des alertes pour détecter tout comportement suspect, en particulier pour les principaux de service sensibles mis en évidence ici.

Nom: Autorisations déléguées dangereuses affectant les données

Nom de code: DANGEROUS-DELEGATED-PERMISSIONS-AFFECTING-DATA

Sévérité: Medium

Type: Microsoft Entra ID Indicator of Exposure