Qu’est-ce qu’une attaque par consentement illicite dans Office 365 ?

Qu’est-ce qu’une attaque par consentement illicite ?

Une attaque par consentement illicite dans Office 365 consiste à inciter une personne à donner des droits étendus sur les données auxquelles elle peut accéder ou sur la configuration de ses applications Office 365 à une application tierce externe à son organisation.

La plupart du temps, l’utilisateur reçoit un mail de phishing l’incitant à suivre des liens qui semblent légitimes dans le contexte d’Office 365 et au travers desquels il finit par octroyer, sans réellement comprendre ce qu’il fait, des droits à l’application tierce malicieuse.

Une fois les droits octroyés, l’application malicieuse dispose d’un accès au niveau du périmètre de sécurité de l’utilisateur sans avoir besoin de connaitre son nom d’utilisateur et son mot de passe.

Cela veut dire que ce type d’attaque ne nécessite pas le vol des identifiants de connexion de l’utilisateur et la mise en place d’une authentification multi-facteur ne protège pas contre elle.

Scénario classique d’une attaque par consentement illicite

Voici un scénario typique tiré d’une expérience réelle :

• Un utilisateur reçoit un mail de phishing lui indiquant qu’un document est partagé avec lui. Le lien semble correct et finit par « .web.core.windows.net ».
• L’utilisateur suit le lien, puis il lui est demandé d’accorder des droits à une application avec un nom qui semble correspondre au contexte Office 365 comme « SharePoint Docs »
• C’est généralement la première fois que l’utilisateur utilise cette méthode de partage et comme on lui demande souvent d’accorder son consentement pour accéder et utiliser des ressources en ligne (l’effet GDPR), il ne se méfie pas et trouve ça normal. Il ne regarde pas en détail les permissions qu’il accorde et ne serait de toute façon pas en mesure de les comprendre car trop techniques pour lui.
• Finalement après accord des permissions, le document ne semble plus disponible. L’utilisateur conclut que la manipulation n’a pas fonctionné ou que le document a été retiré et incrimine éventuellement le système.
• L’application a pendant ce temps obtenu les permissions de modifier la configuration de la boîte mail du collaborateur. Le détail du “grant” ressemble à ceci :

{
"Name": "ConsentAction.Permissions",
"NewValue": "[] => [[Id: AAAAAAAAAAAAAAAAAAAAACixwiL_JOBBqHOre3PNTOWljA2RvrSiSrbwsMJWDGBP,
ClientId: 00000000-0000-0000-0000-000000000000, PrincipalId: XXXX-XXXX-XXXX-XXXX-XXXX, ResourceId:
XXXX-XXXX-XXXX-XXXX-XXXX, ConsentType: Principal, Scope:  offline_access Contacts.Read User.Read
Mail.Read Notes.Read.All MailboxSettings.ReadWrite Files.ReadWrite.All openid profile]]; ",
"OldValue": ""
},

• L’application peut alors créer une règle de renvoi de mail qui ressemble à ceci :

If the message:

the message includes specific words in the subject or body ‘fund’ or ‘Wire’ or ‘transfer’ or ‘iban’ or ‘capital call’ or ‘cash’ or ‘agreement’ or ‘purchase’ or ‘shares’ or ‘dividend’ or ‘Contribution’ or ‘bic’ or ‘swift’ or ‘Payment’ or ‘wiring info’ or ‘Bank’or…

Take the following actions:

forward the message to ‘User’ as an attachment

• La règle est cachée sous un label qui peut faire penser à l’utilisateur qu’il s’agit d’une règle technique créée par son organisation telle qu’une « Anti Spam Rule »
• Tous les messages de l’utilisateur qui correspondent à un critère de la règle sont alors renvoyés à un destinataire externe.
• Au bout de 12h Microsoft détecte l’activité suspecte liée à l’application malicieuse, supprime les droits accordés et désactive l’application tierce. Mais la règle de renvoi de mail est toujours en place tant qu’aucune action n’est prise. Les administrateurs du tenant reçoivent un message de Microsoft de cette nature :

Le scénario ci-dessus représente une attaque par consentement illicite réussie et qui restera réussie tant que l’on n’aura pas repéré la personne qui a été impactée et supprimé la règle de renvoi de mail.

Heureusement, Microsoft nous propose tout un ensemble de mesures pour détecter, corriger et éviter ce type de problème.

Comment détecter ces attaques ?

Microsoft propose des outils pour chercher les activités de consentement des utilisateurs. Un des premiers outils que référence Microsoft est d’utiliser les logs d’audit sous https://protection.office.com section « Search > Audit log search ».

Voilà à quoi cela ressemble : Comme malheureusement au jour de l’écriture de cet article, le type d’activité « Consent to application » n’est pas disponible dans les options de recherche à droite de l’écran, il est assez courant de rater les évènements par cette méthode.

Il faut cependant noter que si on ne connait pas la période d’attaque avec précision il est compliqué de retrouver les entrées avec l’interface proposée. En effet, pour que le filtre « consent to application » fonctionne il faut que l’évènement ait été chargé dans la page. Il faut donc penser à bien faire défiler tous les résultats de la liste avant d’applique le filtre.

La capture d’écran ci-dessus montre bien la séquence des évènements avec la mise à jour des règles Outlook.

Une approche plus industrielle est de passer par un script PowerShell qui recherche ce type d’évènement dans les audits logs. Microsoft propose la commande « Search-UnifiedAuditLog » pour effectuer cette opération. Nous ne détaillerons pas ici le script PowerShell permettant d’effectuer cette opération mais si vous voulez sérieusement tracer ce type d’évènements et les injecter dans votre système de SIEM par exemple, cette approche s’impose.

Une autre approche est de faire un inventaire régulier des applications et de leurs permissions dans l’écosystème Office 365.

Pour se faire, l’approche la plus industrielle est d’utiliser un script PowerShell qui liste l’ensemble des applications et leurs permissions et de rechercher tous les droits d’accès aux données de l’utilisateur, les droits de modification des données ou les droits d’accès à la configuration des applications. Microsoft propose un script Get-AzureADPSPermissions.ps1, disponible sur leur « GitHub » permettant de réaliser cette opération.

Si vous avez le niveau de licence suffisant il est également possible d’utiliser « Microsoft Cloud App Security » pour mettre en place une stratégie de détection des anomalies d’application OAuth. Une documentation détaillée est disponible chez Microsoft pour la mise en place de la détection et de la levée d’alerte : https://docs.microsoft.com/en-us/cloud-app-security/app-permission-policy

Il est cependant fort probable que cette dernière option ne soit pas disponible sous votre instance de « Microsoft Cloud App Security ». Votre seule option est de passer par des scripts PowerShell et de gérer vous-même votre détection et levée d’alerte.

Tout ceci n’est pas des plus simple ni des plus direct. En plus des méthodes de détection détaillées ci-dessus il est également fortement recommandé de mettre en place des alertes sur toutes les activités liées à la mise en place de règles de renvoi de mail au niveau domaine ou au niveau utilisateur et de travailler sur la mise en place du DLP (Data Loss Prevention) pour être averti en cas d’exploitation des chemins de fuite de données vers l’extérieur depuis les outils et application Microsoft Office 365.

Comment arrêter et corriger les impacts de ces attaques ?

Comme nous l’avons vu précédemment il faut être en capacité de détecter l’octroi de droits abusifs à des applications tierces et d’être en capacité de repérer les actions qu’elles ont entreprises pour y remédier.

La première chose à faire est de supprimer les permissions, voire de supprimer le lien entre l’application et les utilisateurs.

Pour supprimer l’application il faut se connecter au portail Azure Active Directory, et pour chaque utilisateur concerné :

• Accéder au panneau de contrôle de l’utilisateur
• Selectionner « application »
• Selectionner l’application illicite
• Cliquer sur « remove »

Si beaucoup d’utilisateurs sont concernés, cette opération et fastidieuse et peut prendre pas mal de temps.

Encore une fois une approche script PowerShell est préférable et nécessite l’usage de la commande PowerShell « Remove-AzureADOAuth2PermissionGrant ».

En fonction des actions qui ont été réalisées avec les droits de l’utilisateur impacté, il convient également de supprimer toutes les règles de renvoi, de transfert ou de partage d’information qui auraient pu être mise en place. L’inspection de logs d’audit s’avère cruciale pour repérer toutes les activités qui auraient été faites au travers de l’application malicieuse.

Comment s’en protéger ?

La seule méthode efficace est de désactiver la capacité pour les utilisateurs d’accorder des droits à une application tierce.

Soit au travers du panneau d’administration Office 365 dans «Services & add-ins »  (https://go.microsoft.com/fwlink/p/?linkid=2053743) :

Soit en passant par la console « Azure Active Directory » dans la section « Enterprise applications » | « User settings »

Si vous devez laisser la capacité à vos utilisateurs d’accorder des droits à des applications tierces, il est alors fortement recommandé de pouvoir être alerté par « Microsoft Cloud App Security » tel que décrit ici : https://docs.microsoft.com/en-us/cloud-app-security/app-permission-policy et de mettre en place un processus d’analyse et de traitement des alertes remontées pour éviter toute activité indésirable au niveau de vos applications et de vos données.

Références :

• https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants
• https://docs.microsoft.com/en-us/cloud-app-security/manage-app-permissions
• https://docs.microsoft.com/en-us/microsoft-365/admin/misc/integrated-apps?view=o365-worldwide
• https://gist.github.com/psignoret/41793f8c6211d2df5051d77ca3728c09

Share

Grâce à nos
Auteur

Laurent B.