Lorsquune entreprise ou un utilisateur configure Google Apps (aujourdhui connu sous le nom de Google Workspace), un domaine personnalis est souvent utilis pour grer les emails et les services associs. Si ce domaine expire ou est abandonn, il peut tre rachet par une autre personne. Cependant, Google conserve certains enregistrements lis au domaine dans ses systmes. Cela signifie que si un tiers malintentionn rachte le domaine, il peut potentiellement rcuprer les accs certains services ou mme intercepter des communications sensibles.
De nombreuses startups utilisent la suite de productivit de Google, connue sous le nom de Workspace, pour grer le courrier lectronique, les documents et d’autres aspects administratifs. De mme, de nombreuses applications web vocation commerciale utilisent OAuth de Google, le flux d’authentification qui propose de Se connecter avec Google . Il s’agit d’une boucle de rtroaction faible friction, jusqu’ ce que la startup choue, que le domaine soit mis en vente et que quelqu’un oublie de fermer toutes les applications Google.
Dylan Ayrey, de Truffle Security Co, suggre dans un rapport que ce problme est plus grave que quiconque, en particulier Google, ne le reconnat. De nombreuses startups commettent l’erreur grave de ne pas fermer correctement leurs comptes, tant sur Google que sur d’autres applications web, avant de laisser leurs domaines expirer.
Compte tenu du nombre de personnes travaillant dans des startups technologiques (6 millions), du taux d’chec de ces startups (90 %), de leur utilisation des espaces de travail Google (50 %, selon les chiffres d’Ayrey) et de la vitesse laquelle les startups ont tendance s’effondrer, il y a beaucoup de domaines connects Google-auth qui sont vendre tout moment. Cela ne constituerait pas un problme en soi, sauf que, comme le montre Ayrey, l’achat d’un domaine avec un compte Google encore actif peut vous permettre de ractiver les comptes Google d’anciens employs.
Avec un accs administrateur ces comptes, vous pouvez accder de nombreux services pour lesquels ils utilisaient OAuth de Google, comme Slack, ChatGPT, Zoom et les systmes de ressources humaines. Ayrey crit qu’il a achet un ancien domaine de startup et qu’il a accd chacun d’entre eux par le biais de la connexion un compte Google. Il s’est retrouv avec des documents fiscaux, des dtails d’entretiens d’embauche et des messages directs, entre autres documents sensibles.
J’ai parcouru l’ensemble des donnes de Crunchbase sur les startups et j’ai trouv plus de 100 000 domaines actuellement disponibles l’achat auprs de startups qui ont chou.
Si chaque startup ayant chou compte en moyenne 10 employs au cours de sa vie et utilise 10 services SaaS diffrents, nous parlons d’un accs aux donnes sensibles de plus de 10 millions de comptes.
Pour comprendre le problme, jetons un coup d’il rapide Oauth :
L’explication simplifie de Dylan Ayrey sur le fonctionnement de Google (ou de la plupart des autres) OAuth lors de la connexion un service tiers comme Slack.
Lorsque vous utilisez le bouton Se connecter avec Google , Google envoie au service (par exemple, Slack) un ensemble d’informations sur l’utilisateur.
Exemple d’un ensemble de revendications par dfaut.
Ces revendications sont gnralement les suivantes
- hd (hosted domain) : Spcifie le domaine, par exemple, example.com.
- email : L’adresse lectronique de l’utilisateur, par exemple user@example.com.
Le fournisseur de services (par exemple Slack) utiliserait l’une de ces revendications ou les deux pour dterminer si l’utilisateur peut se connecter.
L’allgation HD pourrait tre utile pour dire Tout le monde exemple.com peut se connecter l’espace de travail exemple.com
Quant l’allgation relative l’adresse lectronique, elle est utilise pour connecter les utilisateurs leur compte spcifique.
Voici le problme : Si un service (par exemple, Slack) repose uniquement sur ces deux revendications, les changements de proprit du domaine ne seront pas diffrents pour Slack. Lorsque quelqu’un achte le domaine d’une entreprise disparue, il hrite des mmes revendications, ce qui lui permet d’accder aux anciens comptes des employs.
Les risques potentiels
- Accs aux donnes sensibles : Les nouveaux propritaires du domaine peuvent utiliser la rcupration de comptes pour accder des services Google associs au domaine.
- Usurpation didentit : Avec un contrle total sur le domaine, ils peuvent crer des adresses email similaires celles utilises auparavant par lentreprise, facilitant ainsi des attaques de phishing ou la diffusion dinformations frauduleuses.
- Compromission de comptes tiers : Si des services externes utilisent lemail li lancien domaine pour des connexions ou des rinitialisations de mot de passe, les nouveaux propritaires peuvent potentiellement compromettre ces comptes.
Les causes sous-jacentes
Ce problme dcoule principalement de la manire dont Google gre les domaines. Une fois configur, un domaine est troitement li son compte Google Apps, mme aprs sa dsactivation ou son abandon. En labsence de nettoyage ou de dissociation proactive, les traces de lancien domaine restent exploitables.
Contact pour un commentaire, un porte-parole de Google a fait une dclaration :
Nous apprcions l’aide apporte par Dylan Ayrey pour identifier les risques lis au fait que les clients oublient de supprimer les services SaaS tiers dans le cadre de l’arrt de leurs activits. En tant que meilleure pratique, nous recommandons aux clients de fermer correctement les domaines en suivant ces instructions afin de rendre ce type de problme impossible. En outre, nous encourageons les applications tierces suivre les meilleures pratiques en utilisant les identifiants de compte uniques (sub) pour attnuer ce risque.
Les instructions de Google prcisent que l’annulation d’un espace de travail Google ne supprime pas les comptes d’utilisateurs , qui demeurent jusqu’ ce que le compte Google d’une organisation soit supprim.
Il est noter que les mthodes d’Ayrey n’ont pas permis d’accder aux donnes stockes dans chaque compte Google ractiv, mais sur des plateformes tierces. Bien que les cas de test et les donnes d’Ayrey concernent principalement les startups, tout domaine qui utilise des comptes Google Workspace pour s’authentifier auprs de services tiers et qui n’a pas supprim son compte Google pour supprimer son lien de domaine avant de vendre le domaine pourrait tre vulnrable.
Ne pas corriger (comportement prvu)
Ayrey crit qu’il a communiqu ses conclusions Google le 30 septembre 2024. Google a rpondu le 2 octobre qu’il avait pris la dcision de ne pas le suivre en tant que bogue d’abus et a mis son statut Ne pas corriger (comportement prvu) , selon les captures d’cran d’Ayrey. Un porte-parole de Google a crit que la rponse initiale de l’entreprise tait base sur une protection forte et approprie , le champ sub , qui existait dj (plus d’informations ce sujet plus loin).
Dix jours aprs qu’Ayrey a fait accepter un expos sur ce sujet la confrence de hackers Shmoocon, Google a rouvert le dossier, lui a vers une rcompense de 1 337 dollars et a dclar l’poque que la probabilit d’exploitation est faible , mais qu’il s’agissait d’une mthodologie lie l’abus avec un impact lev .
Dans les instructions de fermeture de domaine et la documentation de l’API de Google, Google indique un identifiant d’utilisateur unique, sub , comme une valeur qui n’est jamais modifie et qui devrait tre utilise comme cl pour l’identification de l’utilisateur. L’article d’Ayrey cite un ingnieur anonyme d’une grande entreprise technologique qui n’est pas d’accord, suggrant que la valeur sub varie dans environ 0,04 % des connexions utilisant Google OAuth. certaines tailles d’audience, cela peut reprsenter des centaines de connexions chaque semaine. Face ce problme, les grands services n’utilisent probablement pas sub pour la vrification de l’utilisateur unique, suggre Ayrey.
Un porte-parole de Google a dclar que l’entreprise examinerait volontiers tout document ce sujet , mais qu’elle n’avait vu aucune preuve l’appui de l’affirmation selon laquelle le champ sub n’est pas un identifiant immuable et unique . Google a galement mis jour sa documentation pour les dveloppeurs OAuth afin d’insister davantage sur l’utilisation de sub comme protection.
La solution propose par Ayrey, qu’il a suggre Google, consiste inclure deux nouveaux identifiants immuables dans ses revendications OpenID Connect : un identifiant li l’utilisateur qui ne change jamais et un identifiant li au domaine. ce jour, Ayrey n’a pas encore reu de nouvelles de Google quant d’ventuels correctifs ou l’volution de la situation.
Conclusion
La question des domaines abandonns met en lumire un dfi fondamental dans la gestion des identits numriques : mme les plateformes les plus avances peuvent laisser des failles exploites par des acteurs malveillants. Les utilisateurs et les entreprises doivent rester vigilants et proactifs pour limiter les risques, tandis que les gants de la technologie, comme Google, doivent amliorer leurs processus pour scuriser les donnes et protger les utilisateurs.
Sources : Dylan Ayrey, Google (1, 2)
Et vous ?
Google devrait-il tre tenu pour responsable de la gestion des anciens domaines abandonns ? Quels mcanismes pourrait-il mettre en place pour mieux protger les utilisateurs ?
Dautres plateformes en ligne rencontrent-elles des problmes similaires avec des ressources abandonnes ou rutilises ?
Les entreprises et particuliers sont-ils suffisamment informs des risques lis labandon de leurs anciens domaines ? Comment renforcer cette sensibilisation ?
Quels pourraient tre les cots directs et indirects pour les entreprises victimes de ce type de compromission ?
Les entreprises devraient-elles tre tenues de maintenir leurs domaines actifs pour viter toute exploitation malveillante, mme aprs leur dsaffectation ?