Application OAuth suspecte dans Google Workspace : enquêter

En bref. Un consentement illicite est un hameçonnage qui demande une autorisation au lieu d'un mot de passe. L'utilisateur clique sur « Autoriser », et une application contrôlée par l'attaquant obtient pour sa boîte ou son Drive un jeton qui survit à la réinitialisation du mot de passe. Dans le journal des jetons OAuth, cherchez les événements authorize avec des scopes Gmail, Drive ou admin, des noms d'applications inconnus, des autorisations depuis une IP à risque, et des événements activity montrant l'application en train de lire le courrier en volume. Révoquez le jeton, bloquez l'ID client pour toute l'organisation, puis mesurez ce que l'application a lu.

La voie OAuth est séduisante parce qu'elle contourne l'essentiel de ce que surveillent les défenseurs. Aucun mot de passe n'est volé, la 2SV ne s'applique pas aux appels API, et l'accès dure. MITRE décrit le vol de ces jetons sous T1528 Steal Application Access Token, et la collecte de courrier à travers eux sous T1114.002 Remote Email Collection.

Ce qu'enregistre le journal des jetons OAuth

La page OAuth log events de Google et l'annexe des événements de jeton décrivent les événements :

Google indique un délai de quelques heures pour ce journal (tableau des délais). Si vous exportez une heure après le clic, l'autorisation n'y est peut-être pas encore.

Évaluer un événement authorize

Cinq questions, dans l'ordre :

1. Quels scopes ? La liste des scopes dit tout.

   Scope	Portée	Gravité dans l'analyseur
   https://mail.google.com/, gmail.readonly, gmail.modify, gmail.send, gmail.settings.*…	Lire, envoyer ou reconfigurer la boîte	Élevée
   drive, drive.readonly	Tous les fichiers accessibles à l'utilisateur	Moyenne
   admin.directory.*, cloud-platform	Actions au niveau de l'organisation	Élevée
   openid, userinfo.email, drive.file	Identité de connexion, fichiers créés par l'application elle-même	Non signalé

2. Quand et d'où ? Une autorisation quelques minutes après une connexion à risque, depuis la même IP d'hébergeur, c'est l'attaquant qui autorise sa propre application avec la session volée. Une autorisation depuis le réseau habituel de l'utilisateur après un e-mail d'hameçonnage, c'est un phishing par consentement.

3. Quel nom ? Les noms leurres imitent des utilitaires : « PDF Viewer », « Document Signer », « Secure Mail ». Le nom est choisi par le développeur de l'application et ne prouve rien.

4. Qui d'autre l'a autorisée ? Pivotez sur l'ID client. Un outil SaaS légitime a de nombreux utilisateurs dans la durée. Une application leurre apparaît en rafale, ou sur un seul compte.

5. Est-elle vérifiée et approuvée ? Consultez Security → Access and data control → API controls → Manage third-party app access (libellés de la console en anglais) pour le statut et la vérification de l'application.

Lire les événements activity

activity montre le jeton en action. Pour Gmail, vous voyez api_name = gmail et des méthodes comme gmail.users.messages.list, gmail.users.messages.get, gmail.users.settings.filters.create. Cette dernière signifie que l'application a créé un filtre Gmail, souvent le filtre de masquage d'une fraude BEC.

L'analyseur signale une application qui fait 20 appels à l'API Gmail ou plus en 60 minutes pour un même utilisateur : c'est le constat Application lisant Gmail en volume via l'API. C'est de la collecte, pas un client de messagerie qui synchronise de temps en temps. Les IP de ces événements sont l'infrastructure API de l'attaquant. Ajoutez-les à votre pivot sur les IP.

Réponse

1. Révoquer pour l'utilisateur : console → l'utilisateur → Security → Connected applications → supprimer l'application. Cela fait aussi partie de la procédure de Google pour les comptes compromis.
2. Bloquer pour tous : passez l'application en Blocked dans les contrôles d'API, par ID client. Sinon, le prochain utilisateur hameçonné la réautorisera.
3. Restreindre les applications non configurées : le contrôle d'accès des applications de Google permet d'empêcher les utilisateurs d'autoriser des applications que vous n'avez pas examinées, ou de les limiter aux scopes de simple connexion. Les utilisateurs peuvent alors demander un examen.
4. Mesurer les dégâts : à partir des événements activity, listez méthodes et périodes. Dans le journal Gmail, vérifiez ce qui a été transféré ou envoyé sur la même fenêtre. num_response_bytes donne un ordre de grandeur du volume.
5. Surveiller le côté admin : l'analyseur signale aussi les administrateurs qui assouplissent les contrôles d'applications (ADD_TO_TRUSTED_OAUTH2_APPS, UNBLOCK_ALL_THIRD_PARTY_API_ACCESS et assimilés) sous le constat Contrôles d'accès des applications assouplis.

Autorisation par utilisateur ou délégation au niveau du domaine

Tout ce qui précède concerne le consentement par utilisateur : un utilisateur, un jeton, limité à ce que cet utilisateur peut atteindre. La délégation au niveau du domaine est différente. Un super-administrateur permet à un client API d'usurper n'importe quel utilisateur pour les scopes listés, sans aucun consentement. C'est enregistré dans le journal Admin, pas dans celui des jetons. Elle a son propre article.

Faux positifs courants

• Les outils de sauvegarde, d'archivage, de signature électronique et de CRM demandent légitimement un accès Gmail ou Drive complet. Documentez-les et bloquez le reste.
• Les clients de messagerie qui utilisent OAuth détiennent aussi https://mail.google.com/.
• Les applications internes développées par vos équipes. Vérifiez le propriétaire du projet Google Cloud de l'ID client.

L'analyseur n'a pas encore de liste d'autorisation, donc les applications connues se déclencheront. Traitez ces constats comme une revue d'inventaire.

À suivre : les risques de la délégation au niveau du domaine. Retour au guide d'investigation, ou passez votre journal des jetons dans l'analyseur.

FAQ

Une réinitialisation du mot de passe révoque-t-elle l'accès d'une application tierce ?

N'y comptez pas. Une application autorisée par l'utilisateur continue de fonctionner tant que son jeton n'est pas révoqué. Révoquez-la pour l'utilisateur (console d'administration → utilisateur → Security → Connected applications) et bloquez-la pour l'organisation dans les contrôles d'API.

Quels scopes OAuth sont les plus dangereux dans Google Workspace ?

L'accès Gmail complet (https://mail.google.com/), gmail.readonly / gmail.modify / gmail.send et les scopes de paramètres Gmail, le Drive complet (drive, drive.readonly), et les scopes d'annuaire admin ou cloud-platform. Ils donnent à une application la même portée que l'utilisateur, voire davantage.