Une faille dans Google Workspace permettait de détourner des comptes pour s’authentifier ailleurs

Une faille dans Google Workspace permettait de détourner des comptes pour s’authentifier ailleurs

Un léger désaccord

2

Une faille dans Google Workspace permettait de détourner des comptes pour s’authentifier ailleurs

Google a rencontré un problème de sécurité sur ses comptes Workspace, qui a eu le temps d’être exploité par des acteurs malveillants. Les pirates ont détourné un mécanisme pour accéder à d’autres informations, grâce à la connexion unique (SSO) du compte Google. La société est cependant accusée de mentir sur les dates et l'ampleur du problème.

Dans un message envoyé à KrebsOnSecurity, Google a confirmé qu’un problème de sécurité avait été découvert dans les comptes Workspace. Ces derniers sont pour rappel dédiés aux entreprises.

L’une des possibilités offertes est de pouvoir utiliser le nom de domaine de l’entreprise pour créer des adresses personnalisées, de type [email protected]. Une fonction courante. Cette adresse peut ensuite être utilisée dans tous les services Google, ainsi que sur les sites prenant en charge la connexion SSO (Single Sign-on) « Se connecter avec Google ».

Le problème découvert permettait à des pirates de contourner le système de vérification de l’adresse électronique, une étape obligatoire lors de l’inscription à Google Workspace.

Le problème et son exploitation

« Au cours des dernières semaines, nous avons identifié une campagne d'abus à petite échelle dans le cadre de laquelle des acteurs malveillants ont contourné l'étape de vérification de l'adresse e-mail dans notre flux de création de comptes pour les comptes Google Workspace vérifiés par e-mail (EV) à l'aide d'une demande spécialement conçue. Ces utilisateurs EV pouvaient ensuite être utilisés pour accéder à des applications tierces à l'aide de l'option "Se connecter avec Google" », a expliqué l’entreprise à KrebsOnSecurity.

De manière plus détaillée, l’exploitation commence avec la création d’un compte d’essai Workspace. Une possibilité mise en place par Google pour permettre de tester les fonctions supplémentaires dans des services comme Docs et Sheets. Ce processus de création de compte suppose la vérification de l’adresse email.

À ce stade, les pirates ont pu créer une requête spécifiquement conçue pour contourner cette vérification et la réorienter vers une autre adresse. « Les pirates utilisaient une adresse électronique pour essayer de se connecter et une adresse électronique complètement différente pour vérifier un jeton », a indiqué Google.

Armés d’une adresse email vérifiée (mais qui n’aurait jamais dû l’être), les pirates pouvaient ensuite se connecter à des services tiers via l’authentification SSO de Google, comme Dropbox. Ils pouvaient se faire passer pour les détenteurs du domaine personnalisé. Selon Google, ces détournements n’ont pas été utilisés pour dérober des données dans les services de Workspace.

Tout n’est pas rose

L'entreprise affirme que le problème a été détecté fin juin et a été corrigé dans les 72 heures. L’éditeur a ajouté que des mesures supplémentaires avaient été mises en place pour que ce cas de figure ne se reproduise plus. Aucune information n’a été donnée sur le type de requête utilisé par les pirates, mais on imagine que les travaux de Google ont porté sur ce point.

Seulement voilà, tout ne cadre pas avec la version donnée par Google. Dans les commentaires laissés sur Hacker News ou même dans le billet de KrebsOnSecurity, on lit rapidement des messages accusant Google de mentir.

« Ce que dit Google est tout simplement faux. Les attaques ont commencé au début du mois de juin. J'écris ici en tant que l'une des victimes de cette époque. Plus encore, j'ai un numéro de ticket buganizer datant du 7 juin avec les premières constatations. Le problème a été résolu environ un mois plus tard », indique, par exemple, Paul B.

« Le problème a commencé bien plus tôt que ça. Deux malfaiteurs distincts ont créé de faux comptes Google Workspace (et son prédécesseur Google Apps) pour mon domaine en 2012, puis en juillet 2023. La première fois, j'ai repris le compte en prouvant que j'étais propriétaire du domaine, puis j'ai fini par fermer le compte. La deuxième fois, j'ai décidé de ne pas fermer le compte après l'avoir repris, afin d'éviter une troisième fois », indique même David Keaton.

Nous avons contacté Google pour obtenir une réaction à ces accusations, sans réponse pour l’instant. Nous mettrons à jour cette actualité si la société revient vers nous.

Pas de lien avec le détournement Squarespace

Google a également précisé auprès de KrebsOnSecurity que le problème de sécurité n’avait pas de lien avec un précédent ayant touché Squarespace. Ce registraire avait racheté l’ensemble des actifs de Google Domains l’année dernière, dont les dix millions de domaines gérés par le service de Google.

Or, le 9 juillet, un certain nombre de domaines liés à des entreprises de cryptoactifs ont été détournés. Les pirates ont profité d’un vide laissé par la transition de la gestion des domaines à Squarespace, avant que l’ensemble des clients aient configuré leur compte chez le nouveau prestataire.

Le 18 juillet, Squarespace avait publié un billet annonçant que le problème avait été résolu. La société pointait une faiblesse dans le processus d’authentification OAuth. « Lors de cet incident, tous les comptes compromis utilisaient l'authentification OAuth d'une tierce partie. Ni Squarespace ni aucun fournisseur d'authentification tiers n'a modifié l'authentification dans le cadre de la migration des domaines Google vers Squarespace. Pour être clair, la migration des domaines n'a impliqué aucune modification de l'authentification multifactorielle avant, pendant ou après », a indiqué Squarespace.

Commentaires (2)


Autant le problème de début juin peut être le même (même cause) autant j'ai des doutes assez fort sur le problème de 2012 qui était probablement un problème avec une cause différente et probablement corrigé depuis. Quant à celui de juillet 2023, on n'a aucune info qui permette un avis.
Well, actually....

Déjà, il faut clairment faire attention avec ce que disent les utilisateurs (cf le problème de 2012, ça me paraitrait tout de même étonnant que la cause soit identique)

Et puis Google n'a pas forcément menti. La vulnérabilité peut avoir été effectivement utilisée dès début juin. Peut être même avant. Peut être même en 2012 d'ailleurs.
Mais ce n'est pas un mensonge de dire qu'elle a été identifiée par Google fin juin. C'est juste qu'avant, Google ne l'avait juste pas... bah identifiée quoi ^^'

Le ticket créé par l'utilisateur début juin a peut être aidé à l'identification, mais la date de création du ticket ne correspond pas forcément à la date d'identification de la vulnérabilité.
Modifié le 30/07/2024 à 19h44

Historique des modifications :

Posté le 30/07/2024 à 19h37


Well, actually....

Déjà, il faut clairment faire attention avec ce que disent les utilisateurs (cf le problème de 2012, ça me paraitrait tout de même étonnant que la cause soit identique)

Et puis Google n'a pas forcément menti. La vulnérabilité peut avoir été effectivement utilisée dès début juin. Peut être même avant. Peut être même en 2012 d'ailleurs.
Mais ce n'est pas un mensonge de dire qu'elle a été identifiée par Google fin juin. C'est juste qu'avant, Google ne l'avait juste pas... bah identifiée quoi ^^'

Fermer