La connexion Google OAuth ne protège pas contre le rachat du domaine d’une startup disparue

• Une faille de sécurité dans Google OAuth introduit une vulnérabilité grave dans le processus d’authentification « Sign in with Google »
  • Après avoir acheté le domaine d’une startup disparue, il est possible de recréer les comptes e-mail de ce domaine et de se connecter à des services SaaS
  • Accès possible à des services contenant des données sensibles :
    • Slack, ChatGPT, Notion, Zoom, des systèmes RH (avec numéros de sécurité sociale)
  • Google a d’abord refusé de corriger le problème, en le qualifiant de « comportement attendu »
• Cause profonde du problème : Google OAuth ne détecte pas les changements de propriétaire d’un domaine
  • Lorsqu’un domaine change de mains, le nouveau propriétaire peut se connecter aux anciens comptes employés avec les mêmes attributs (claims)
• Principales informations d’identité utilisées :
  • hd (domaine hébergé) : contient les informations du domaine (ex. : example.com)
  • email : contient l’adresse e-mail de l’utilisateur (ex. : [e-mail])
• Si le fournisseur de service s’appuie sur ces deux informations, un changement de propriété du domaine peut autoriser l’accès au même compte
• Ampleur du problème
  • 6 millions d’Américains travaillent dans des startups
  • 90 % des startups échouent
  • 50 % des startups en échec utilisent Google Workspaces
• Environ 100 000 domaines de startups disparues peuvent être achetés
• En moyenne, 10 employés et 10 services SaaS par domaine → possibilité que plus de 10 millions de comptes contiennent des données sensibles

Proposition de solution et réponse de Google

• Solutions proposées à Google :
  1. ID utilisateur unique : ajouter un identifiant utilisateur unique qui ne change pas avec le temps
  2. ID Workspace unique : ajouter un identifiant Workspace unique lié au domaine
• Réponse initiale de Google :
  • Signalement en septembre 2024 → clôturé comme « non corrigeable »
  • Après une présentation à la conférence Shmoocon en décembre 2024, Google a réexaminé le problème
  • Versement d’une prime de bug bounty de 1 337 $ et lancement des travaux de correction
• À ce stade, il est impossible de résoudre fondamentalement le problème sans correctif de Google
• Certains services renvoient même la liste complète des utilisateurs quand le domaine correspond, ce qui aggrave encore la vulnérabilité
• Même en utilisant un mot de passe au lieu de la connexion Google, une réinitialisation reste possible
  • Les startups imposent souvent SSO et 2FA au lieu d’une authentification par mot de passe
  • Les fournisseurs de service devraient exiger une vérification supplémentaire lors de la réinitialisation du mot de passe (code SMS, vérification de carte bancaire)

Conclusion : un problème fondamental de sécurité dans Google OAuth

• Une faille dans l’implémentation OAuth de Google permet la prise de contrôle de comptes lors d’un changement de propriétaire du domaine
• Google a commencé à travailler sur un correctif, mais aucune solution de fond n’est encore finalisée
• À ce jour, les données et les comptes de millions d’Américains restent exposés au risque

[sixmen]

J’ai l’impression qu’il s’agit plutôt d’une erreur côté utilisateur : utiliser une adresse e-mail incluant un domaine comme moyen d’authentification, puis abandonner ce domaine sans correctement désactiver les SaaS associés. Mais faut-il tout de même considérer cela comme une faille de sécurité ?

[kargnas]

Dans le service que je développe, j’ai bloqué ce problème en amont, mais malgré cela, je suis d’accord avec cet avis.
Si c’est vraiment un problème, alors il faut considérer que la connexion et l’inscription classiques par e-mail posent exactement le même souci. Dans tous les cas, l’e-mail est utilisé comme identifiant unique, et la vérification de propriété lors de la récupération du mot de passe se fait elle aussi par e-mail.

En poussant le raisonnement à l’extrême, si un domaine très connu comme gmail.com ou hotmail.com était piraté et que les droits de configuration DNS du domaine tombaient entre les mains d’un hacker, il serait alors tout à fait évident que les comptes de tous les SaaS du monde deviendraient vulnérables.

[GN⁺]

Avis Hacker News

• La situation où DankStartup cesse son activité, qu’un tiers rachète le domaine et puisse alors accéder aux comptes existants semble relever d’une responsabilité partagée entre DankStartup, Microsoft et OpenAI

  • Il n’est pas approprié de présenter cela comme une vulnérabilité d’OAuth

• Dans l’implémentation OpenID de Google, la bonne méthode consiste à s’authentifier à l’aide de la revendication sub

  • Il faut prévoir un flux pour le cas où la revendication sub changerait
  • Le « proposé identifiant utilisateur unique immuable » ne diffère pas réellement de la revendication sub

• C’est un problème fondamental des approches qui dépendent du DNS : après l’expiration d’un domaine, son nouveau propriétaire peut hériter des droits de l’ancien

  • C’est un problème qui peut survenir dans les systèmes d’authentification reposant sur une adresse e-mail ou sur le DNS

• Google OAuth ne présente pas de vulnérabilité ici : si vous rachetez un domaine, vous devenez propriétaire de toutes les adresses e-mail de ce domaine

  • Le même résultat pourrait se produire même sans utiliser Google OAuth

• Partage d’une expérience passée avec le cas thehunt.com, où le rachat du domaine permettait d’accéder à tous les services

  • Proposition d’idée de startup consistant à surveiller l’état des domaines pour prévenir les menaces de sécurité

• Le problème vient des services qui n’utilisent pas le champ sub ; il faut utiliser le champ sub pour identifier l’utilisateur

  • Il serait possible de gagner de l’argent en soumettant des rapports de vulnérabilité aux services qui n’utilisent pas le champ sub

• Proposition que l’OpenID Connect de Google implémente deux identifiants immuables

  • La revendication sub et un identifiant unique de workspace lié au domaine

• Il est rare que la revendication sub change dans Google OAuth, et il s’agit probablement d’un problème d’implémentation du service

• Partage d’un cas d’accès à des e-mails après le rachat d’un domaine

  • Le problème a été résolu grâce à une relation interne avec Google

• L’affirmation selon laquelle il y aurait « des millions de comptes » repose sur l’hypothèse que les startups en échec ne désactivent pas leurs comptes SaaS