Lorsqu’une entreprise ou un utilisateur configure Google Apps (aujourd’hui connu sous le nom de Google Workspace), un domaine personnalisé est souvent utilisé pour gérer les emails et les services associés. Si ce domaine expire ou est abandonné, il peut être racheté par une autre personne. Cependant, Google conserve certains enregistrements liés au domaine dans ses systèmes. Cela signifie que si un tiers malintentionné rachète le domaine, il peut potentiellement récupérer les accès à certains services ou même intercepter des communications sensibles.De nombreuses startups utilisent la suite de productivité de Google, connue sous le nom de Workspace, pour gérer le courrier électronique, les documents et d'autres aspects administratifs. De même, 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 rétroaction à 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, suggère dans un rapport que ce problème est plus grave que quiconque, en particulier Google, ne le reconnaît. 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 connectés à Google-auth qui sont à vendre à tout moment. Cela ne constituerait pas un problème en soi, sauf que, comme le montre Ayrey, l'achat d'un domaine avec un compte Google encore actif peut vous permettre de réactiver les comptes Google d'anciens employés.
Avec un accès administrateur à ces comptes, vous pouvez accéder à de nombreux services pour lesquels ils utilisaient OAuth de Google, comme Slack, ChatGPT, Zoom et les systèmes de ressources humaines. Ayrey écrit qu'il a acheté un ancien domaine de startup et qu'il a accédé à chacun d'entre eux par le biais de la connexion à un compte Google. Il s'est retrouvé avec des documents fiscaux, des détails d'entretiens d'embauche et des messages directs, entre autres documents sensibles.
J'ai parcouru l'ensemble des données de Crunchbase sur les startups et j'ai trouvé plus de 100 000 domaines actuellement disponibles à l'achat auprès de startups qui ont échoué.
Si chaque startup ayant échoué compte en moyenne 10 employés au cours de sa vie et utilise 10 services SaaS différents, nous parlons d'un accès aux données sensibles de plus de 10 millions de comptes.
Pour comprendre le problème, jetons un coup d'œil rapide à Oauth :
L'explication simplifiée 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 défaut.
Ces revendications sont généralement les suivantes
Le fournisseur de services (par exemple Slack) utiliserait l'une de ces revendications ou les deux pour déterminer si l'utilisateur peut se connecter.
L'allégation HD pourrait être utile pour dire « Tout le monde à exemple.com peut se connecter à l'espace de travail exemple.com »
Quant à l'allégation relative à l'adresse électronique, elle est utilisée pour connecter les utilisateurs à leur compte spécifique.
Voici le problème : Si un service (par exemple, Slack) repose uniquement sur ces deux revendications, les changements de propriété du domaine ne seront pas différents pour Slack. Lorsque quelqu'un achète le domaine d'une entreprise disparue, il hérite des mêmes revendications, ce qui lui permet d'accéder aux anciens comptes des employés.
Si chaque startup ayant échoué compte en moyenne 10 employés au cours de sa vie et utilise 10 services SaaS différents, nous parlons d'un accès aux données sensibles de plus de 10 millions de comptes.
Pour comprendre le problème, jetons un coup d'œil rapide à Oauth :
L'explication simplifiée 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 défaut.
Ces revendications sont généralement les suivantes
- hd (hosted domain) : Spécifie 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 déterminer si l'utilisateur peut se connecter.
L'allégation HD pourrait être utile pour dire « Tout le monde à exemple.com peut se connecter à l'espace de travail exemple.com »
Quant à l'allégation relative à l'adresse électronique, elle est utilisée pour connecter les utilisateurs à leur compte spécifique.
Voici le problème : Si un service (par exemple, Slack) repose uniquement sur ces deux revendications, les changements de propriété du domaine ne seront pas différents pour Slack. Lorsque quelqu'un achète le domaine d'une entreprise disparue, il hérite des mêmes revendications, ce qui lui permet d'accéder aux anciens comptes des employés.
- Accès aux données sensibles : Les nouveaux propriétaires du domaine peuvent utiliser la récupération de comptes pour accéder à des services Google associés au domaine.
- Usurpation d’identité : Avec un contrôle total sur le domaine, ils peuvent créer des adresses email similaires à celles utilisées auparavant par l’entreprise, facilitant ainsi des attaques de phishing ou la diffusion d’informations frauduleuses.
- Compromission de comptes tiers : Si des services externes utilisent l’email lié à l’ancien domaine pour des connexions ou des réinitialisations de mot de passe, les nouveaux propriétaires peuvent potentiellement compromettre ces comptes.
Les causes sous-jacentes
Ce problème découle principalement de la manière dont Google gère les domaines. Une fois configuré, un domaine est étroitement lié à son compte Google Apps, même après sa désactivation ou son abandon. En l’absence de nettoyage ou de dissociation proactive, les traces de l’ancien domaine restent exploitables.
Contacté pour un commentaire, un porte-parole de Google a fait une déclaration :
Nous apprécions l'aide apportée par Dylan Ayrey pour identifier les risques liés au fait que les clients oublient de supprimer les services SaaS tiers dans le cadre de l'arrêt de leurs activités. En tant que meilleure pratique, nous recommandons aux clients de fermer correctement les domaines en suivant ces instructions afin de rendre ce type de problème impossible. En outre, nous encourageons les applications tierces à suivre les meilleures pratiques en utilisant les identifiants de compte uniques (sub) pour atténuer ce risque.
Il est à noter que les méthodes d'Ayrey n'ont pas permis d'accéder aux données stockées dans chaque compte Google réactivé, mais sur des plateformes tierces. Bien que les cas de test et les données d'Ayrey concernent principalement les startups, tout domaine qui utilise des comptes Google Workspace pour s'authentifier auprès 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 vulnérable.
« Ne pas corriger (comportement prévu) »
Ayrey écrit qu'il a communiqué ses conclusions à Google le 30 septembre 2024. Google a répondu le 2 octobre qu'il avait « pris la décision de ne pas le suivre en tant que bogue d'abus » et a mis son statut à « Ne pas corriger (comportement prévu) », selon les captures d'écran d'Ayrey. Un porte-parole de Google a écrit que la réponse initiale de l'entreprise était basée sur « une protection forte et appropriée », le champ « sub », qui existait déjà (plus d'informations à ce sujet plus loin).
Dix jours après qu'Ayrey a fait accepter un exposé sur ce sujet à la conférence de hackers Shmoocon, Google a rouvert le dossier, lui a versé une récompense de 1 337 dollars et a déclaré à l'époque que « la probabilité d'exploitation est faible », mais qu'il s'agissait d'une « méthodologie liée à 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 modifiée » et qui devrait être utilisée comme clé pour l'identification de l'utilisateur. L'article d'Ayrey cite un ingénieur anonyme d'une grande entreprise technologique qui n'est pas d'accord, suggérant que la valeur « sub » varie dans « environ 0,04 % des connexions » utilisant Google OAuth. À certaines tailles d'audience, cela peut représenter des centaines de connexions chaque semaine. Face à ce problème, les grands services n'utilisent probablement pas « sub » pour la vérification de l'utilisateur unique, suggère Ayrey.
Un porte-parole de Google a déclaré 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 développeurs OAuth afin d'insister davantage sur l'utilisation de « sub » comme protection.
La solution proposée par Ayrey, qu'il a suggérée à 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 reçu de nouvelles de Google quant à d'éventuels correctifs ou à l'évolution de la situation.
Conclusion
La question des domaines abandonnés met en lumière un défi fondamental dans la gestion des identités numériques : même les plateformes les plus avancées peuvent laisser des failles exploitées par des acteurs malveillants. Les utilisateurs et les entreprises doivent rester vigilants et proactifs pour limiter les risques, tandis que les géants de la technologie, comme Google, doivent améliorer leurs processus pour sécuriser les données et protéger les utilisateurs.
Sources : Dylan Ayrey, Google (1, 2)
Et vous ?
Google devrait-il être tenu pour responsable de la gestion des anciens domaines abandonnés ? Quels mécanismes pourrait-il mettre en place pour mieux protéger les utilisateurs ? D’autres plateformes en ligne rencontrent-elles des problèmes similaires avec des ressources abandonnées ou réutilisées ? Les entreprises et particuliers sont-ils suffisamment informés des risques liés à l’abandon de leurs anciens domaines ? Comment renforcer cette sensibilisation ? Quels pourraient être les coûts 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, même après leur désaffectation ?