Autorisations d'application 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.

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 :cet indicateur d'exposition examine le premier type, voir l'indicateur d'exposition connexe « Autorisations d'application dangereuses affectant le tenant » pour les menaces pour l'ensemble du tenant Microsoft Entra. Le consentement est donné par les administrateurs et les autorisations s'appliquent à l'ensemble du tenant. Microsoft les décrit comme suit :

Les autorisations d'application sont utilisées par des applications qui s'exécutent sans la présence d'un utilisateur connecté. Par exemple, les applications exécutées en arrière-plan ou en tant que démons. Les autorisations d'application ne peuvent être accordées que par un administrateur.

• Autorisations déléguées : l'indicateur d'exposition connexe « Autorisations déléguées dangereuses affectant les données ».

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.

• Les autorisations d'application nécessitent toujours le consentement de l'administrateur. Formez ces administrateurs à l'identification des applications suspectes et des autorisations sensibles, y compris à l'identification des autorisations d'application liées aux données. 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.

Veillez à supprimer l'autorisation dangereuse à 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 à haut risque mis en évidence ici.

Nom: Autorisations d'application dangereuses affectant les données

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

Sévérité: Medium

Type: Microsoft Entra ID Indicator of Exposure