Panne partielle sur certaines fonctionnalités de Google OAuth

• Dans les services qui se fient à la claim email de Google OAuth pour déterminer les droits de connexion, un ancien employé peut conserver l’accès à des applications comme Slack ou Zoom même après avoir été retiré de l’organisation Google de l’entreprise
• Il est possible de créer un compte Google avec une adresse e-mail autre que Gmail, et en exploitant les alias d’adresse et le routage d’adresses plus des e-mails d’entreprise, un compte Google hors de l’organisation peut envoyer une claim email au nom du domaine de l’entreprise
• Ce compte non-Gmail n’apparaît ni dans l’interface d’administration ni dans la liste des utilisateurs de l’organisation Google de l’entreprise, mais de nombreux services autorisent la connexion en ne vérifiant que le domaine à la fin de l’adresse e-mail
• Les organisations peuvent atténuer le risque en désactivant la connexion Google et en appliquant strictement SAML, mais certains services ou applications internes ne proposent pas cette option ou ne prennent pas en charge SAML
• Le problème a été signalé à Google le 4 août, une récompense de $1337 a été versée le 5 octobre, puis la divulgation a eu lieu le 16 décembre, 134 jours plus tard, sans qu’un correctif d’atténuation de Google n’ait été déployé à cette date

---

Divulgation de la vulnérabilité et calendrier

• Une vulnérabilité de Google OAuth permet à des employés retirés de l’entreprise et de l’organisation Google de conserver indéfiniment l’accès à des applications comme Slack ou Zoom
• Au moment de la divulgation, Google n’avait pas déployé de modification pour atténuer ce risque
• Le calendrier est le suivant
  • 4 août : signalement à Google, avec indication que des centaines d’applications pourraient être affectées
  • 7 août : l’incident est trié
  • 5 octobre : Google verse $1337 pour ce problème
  • 25 novembre : signalement groupé et privé à des dizaines d’applications affectées, dont Zoom et Slack
  • 16 décembre : divulgation publique 134 jours après la notification à Google

Les risques à utiliser la claim email comme identifiant

• La connexion Forager de Truffle Security avait déjà été affectée par la vulnérabilité Microsoft OAuth de Descope
• À l’époque, il avait été confirmé que Microsoft pouvait envoyer une claim Email qu’il ne créait ni ne vérifiait directement, et qu’une claim email n’était généralement pas un identifiant fiable
• La documentation OIDC de Google met elle aussi en garde contre l’usage de l’e-mail comme identifiant principal
• La claim email_verified a également été examinée comme point particulier, mais aucune méthode n’a été trouvée pour générer une claim email à partir d’une adresse non vérifiée
• En revanche, les abus de la claim email elle-même ont été largement constatés

Comptes Google non-Gmail et claims email en double

• Il est possible de créer un compte Google avec une adresse e-mail existante, même si ce n’est pas une adresse Gmail
  • Par exemple, on peut créer un compte Google avec une adresse Yahoo
  • Ce compte peut alors envoyer une claim email correspondant à cette adresse non-Gmail configurée
• L’une des raisons pour lesquelles Google déconseille d’utiliser l’e-mail comme identifiant principal est que deux comptes Google différents peuvent envoyer la même claim email
  • Après avoir modifié l’adresse non-Gmail dans les paramètres
  • Il devient possible de créer un nouveau compte avec l’ancienne adresse et d’obtenir la même claim email

Des comptes qui restent hors de l’organisation Google de l’entreprise

• La faille principale vient du fait qu’il est possible de créer, pour une adresse de l’organisation Google de l’entreprise, un compte Google externe à l’organisation en exploitant les alias e-mail et le routage d’adresses plus
• Une adresse plus d’un e-mail d’entreprise peut être redirigée vers la boîte de réception de l’utilisateur d’origine
• Ce mécanisme permet de créer un compte Google non-Gmail basé sur une adresse plus associée à l’e-mail de l’organisation, et ce compte ne peut pas être supprimé de l’organisation ni faire l’objet d’un offboarding
• De nombreux services analysent ensuite cette adresse e-mail et décident de l’autorisation de connexion uniquement à partir du domaine final
  • Ce compte peut servir à s’inscrire sur Zoom
  • Ce compte peut servir à s’inscrire sur Slack
• Comme ces comptes Google non-Gmail ne sont pas de véritables membres de l’organisation Google, ils n’apparaissent ni dans les paramètres d’administration ni dans la liste des utilisateurs Google

Mesures d’atténuation côté organisation, fournisseur de service et Google

• Une organisation peut atténuer le risque en désactivant la connexion Google et en imposant strictement SAML
  • Cette approche fonctionne chez la plupart des fournisseurs de services
  • Certains services ne proposent pas cette option
  • Des applications développées en interne peuvent être affectées sans pour autant prendre en charge SAML
• Les fournisseurs de services peuvent utiliser la claim HD de Google OAuth
  • La claim HD indique le domaine de l’organisation Google à laquelle le compte est rattaché
  • Les comptes qui ne sont pas membres d’une organisation Google n’incluent pas de claim HD
  • La plupart des fournisseurs de services testés utilisaient la claim email plutôt que HD
• La claim HD conserve toutefois des limites importantes
  • HD n’est pas un identifiant unique, mais seulement un domaine
  • Si une organisation Google est supprimée et que son domaine est abandonné, quelqu’un d’autre peut récupérer ce domaine et créer une nouvelle organisation Google
  • Un exemple serait l’entreprise A rachetée par l’entreprise B, qui arrête les services de A sans renouveler l’ancien domaine
  • Si quelqu’un sur Internet achète le domaine de l’entreprise A, il peut se connecter aux anciens comptes de service de l’entreprise A
• Les fournisseurs de services peuvent aussi cesser d’autoriser la création de comptes JIT comme fonctionnalité générale et passer à un provisionnement sur invitation uniquement ou basé sur des groupes LDAP
• Google pourrait atténuer largement le problème en interdisant les comptes Google créés avec des domaines déjà utilisés par une organisation Google existante
  • Google interdit déjà en interne les comptes google.com
  • Il pourrait étendre la même protection aux autres organisations
• Parmi les autres mesures possibles côté Google : interdire l’inscription de comptes Google avec des adresses plus, interdire l’inscription avec des alias d’e-mail Google, ou fournir de meilleurs réglages d’administration permettant aux organisations de configurer ces protections

Impact supplémentaire : e-mails de support et flux par magic link

• Même sans accès initial, il peut être techniquement possible d’accéder aux espaces Zoom ou Slack d’une organisation
• Ce scénario s’appuie sur des recherches menées par d’autres chercheurs sur des vulnérabilités dans les flux de connexion par magic link
• Certains systèmes de support ou de tickets, comme Zendesk, permettent de créer des tickets par e-mail
  • Il est possible de créer un compte Google avec l’adresse e-mail du ticket de support
  • Il peut être possible de consulter le contenu du ticket pour finaliser la création du compte
  • Ensuite, il devient possible de tenter une connexion OAuth avec cette adresse de support
• Conserver une fonction email to support sur le domaine principal n’est pas sûr, et il est possible de configurer l’adresse de support Zendesk comme adresse e-mail secondaire

Objectif de la divulgation et problèmes restants

• Le fait que d’anciens employés conservent l’accès à des plateformes comme Slack ou Zoom vient d’une faille dans le fonctionnement de Google OAuth
• Google dispose d’une large capacité d’action pour atténuer ce problème
• L’objectif de cette divulgation est d’obtenir de vrais changements, au-delà de simples ajustements mineurs de la documentation
• Google a traité rapidement le triage de l’incident, mais contrairement à sa pratique d’amélioration en 90 jours, le problème a été rendu public au 134e jour

[GN⁺]

Commentaires sur Hacker News

• Je travaille dans ce domaine et, ces 3 ou 4 dernières années, j’ai dû traiter plus de 20 variantes de cette faille chez plusieurs fournisseurs de connexion et entreprises SaaS. Le billet de blog a raison, mais je pense que le problème central est allé trop loin pour être corrigé proprement à ce stade. L’authentification déléguée sur l’ensemble d’Internet est complètement bancale, et comme j’en ai beaucoup parlé avec des ingénieurs de Google et Microsoft, je suis certain qu’ils connaissent déjà cette famille de problèmes. Simplement, si on changeait le comportement maintenant, cela casserait trop de services existants et d’implémentations de connexion en entreprise vieilles de plusieurs décennies
  Le « correctif » aujourd’hui est simple. Si un site utilise « Sign in with XYZ », il ne faut pas faire confiance à l’adresse e-mail envoyée par le fournisseur. Il ne faut pas accorder de privilèges spéciaux uniquement sur la base du domaine de l’e-mail, et il faut toujours envoyer un e-mail de vérification interne avant de marquer l’utilisateur comme vérifié dans la base de données. Les principaux fournisseurs OAuth ont aussi mis à jour leur documentation pour le préciser, et l’article lui-même le souligne. Donc le fait même qu’une récompense ait été versée est presque surprenant

  • On a l’impression que c’est le résultat d’organisations qui ne comprennent pas vraiment à quel point ce domaine est complexe. Quand on voit comment OAuth2 + OIDC ont été introduits dans plusieurs entreprises, cela a toujours été vendu comme une fonctionnalité du type « se connecter avec x », et non dans une logique security-first. Même quand on essaie de sécuriser davantage les flux avec PKCE, chaque plateforme se comporte n’importe comment sur le partage des cookies, la gestion des redirections, etc., et ça devient un jeu de taupe. Les bases du OAuth2 à 3 acteurs sont solides, et il existe beaucoup de précédents comme CAS, mais l’OpenID Foundation mérite de vives critiques pour la façon dont elle a marketing et vendu OIDC
  • L’approche consistant à « ne pas accorder de privilèges spéciaux uniquement sur la base du domaine de l’e-mail, et toujours envoyer un e-mail de vérification interne avant de marquer l’utilisateur comme vérifié dans la base de données » n’échoue-t-elle pas si un utilisateur a créé son compte avec une adresse plus Google, puis s’est connecté au service avec ce compte Google avant d’être expulsé ? Sauf si on envoie un e-mail de vérification à chaque connexion
  • Dans ce cas précis, l’attaquant peut effectivement recevoir l’e-mail de vérification, donc je ne vois pas à quoi sert cette procédure de vérification
  • « Toujours envoyer un e-mail de vérification interne avant de marquer l’utilisateur comme vérifié dans la base de données » rend en pratique la fonctionnalité se connecter avec x inutile du point de vue de l’utilisateur
  • Google n’aurait-il pas pu empêcher les inscriptions utilisant le domaine des clients Google Apps ? Ça ne semble pas vraiment devoir casser quoi que ce soit

• À ce sujet, davantage de fournisseurs de services devraient cesser d’utiliser l’e-mail comme identifiant principal, comme le recommande la documentation Google. Quand j’ai changé de nom d’utilisateur sur Google Apps, j’ai passé beaucoup de temps à gérer les problèmes dans Slack, Datadog, GoLinks, etc.

  • Les fournisseurs devraient utiliser quoi, alors ? J’ai toujours pensé que l’e-mail était l’identifiant global le plus stable pour un utilisateur, mais cette hypothèse semble fausse
  • J’ai du mal à être d’accord. Ce type de recommandation ne fait que rejeter la responsabilité sur les développeurs d’applications, et la plupart ne feront rien ou l’implémenteront chacun à leur manière
    La bonne direction ici est de fournir une API adaptée aux besoins de l’application qui l’utilise, tout en minimisant les responsabilités supplémentaires. Dans ce cas, Google aurait dû définir email_verified à false pour signaler à l’application ou à l’IdP en aval qu’une vérification supplémentaire était nécessaire

• Si user@domain est déjà géré par les serveurs de messagerie Google et que les règles de routage plus y sont donc appliquées, je ne comprends pas pourquoi on peut créer un nouveau compte Google avec une adresse comme user+suffix@domain. Même sans intention malveillante, cela semble parfait pour créer des configurations de messagerie confuses

  • Un domaine peut librement déplacer son serveur mail. Google traite [e-mail] d’une certaine façon, mais un autre serveur peut faire autrement. Au final, ce sont deux adresses e-mail uniques différentes, et elles devraient être traitées comme telles sur l’ensemble d’Internet
  • Cette fonction d’alias semble être devenue beaucoup trop complexe par rapport à ce qu’elle apporte. C’est encore plus vrai à l’échelle de Google
  • C’est pire que user+suffix@domain. Au moins, +XYZ est documenté dans la RFC e-mail. Google va plus loin et a décidé que les points dans le nom devaient aussi être considérés comme des e-mails normaux. Par exemple, [e-mail] est identique à [e-mail], et tous les mails sont routés vers le second
  • C’est parce que le système d’authentification de Google est un legacy très ancien. Un « compte Google », c’est juste une chaîne de caractères

• Concernant le passage « J’ai été surpris d’apprendre que Microsoft envoie des revendications d’e-mail que Microsoft n’a ni créées ni vérifiées, et que, de manière générale, les revendications d’e-mail ne sont pas considérées comme fiables », même si ce n’était peut-être pas l’intention d’origine, je trouve très utile qu’OIDC puisse être plus flexible. Par exemple, j’exploite un fournisseur de connexion gratuit[0], qui vérifie l’identité en tant que fournisseur d’identité (IdP) de quatrième partie via un OIDC amont ou directement par e-mail, et crée un pare-feu de confidentialité entre l’application et cet IdP. Autrement dit, cela empêche Google de suivre toutes les applications auxquelles l’utilisateur se connecte
  Pouvoir récupérer son propre e-mail dans Google signifie qu’on peut bénéficier de la sécurité et de l’expérience utilisateur de Google OIDC tout en conservant la confidentialité de l’e-mail + mot de passe, mais avec l’énorme réserve qu’il faut désormais faire confiance à LastLogin plutôt qu’à Google. Des protocoles visant à réduire cette dépendance sont également en cours de développement. Je suis totalement en désaccord avec le passage « la documentation de Google avertissait en réalité de ne pas utiliser l’e-mail comme identifiant ». L’e-mail est la seule véritable identité fédérée que les gens utilisent réellement. Tant qu’une meilleure alternative ne sera pas largement déployée, je pense qu’il faut traiter les adresses e-mail comme une identité
  [0]: https://lastlogin.io

  • Je ne suis pas d’accord avec « il faut traiter les adresses e-mail comme une identité ». Pour deux raisons
    En dehors du monde occidental, les téléphones portables sont plus répandus que les ordinateurs et l’UI y est généralement plus simple, donc le numéro de téléphone a plus de chances de servir d’identité. En outre, cela revient à confier entièrement l’identité au fournisseur d’e-mail. Une organisation impersonnelle comme Google peut bloquer l’accès sans préavis ni procédure de recours, et c’est effectivement ce qui se produit, ce qui peut faire tout perdre. Pour donner un peu de contexte, j’ai lancé les produits OAuth et OIDC d’Okta, créé les cours associés sur LinkedIn, et je recommence aujourd’hui chez Pangea Cyber
  • « Il faut traiter les adresses e-mail comme une identité » ? En supposant que personne ne partage jamais son adresse e-mail et que l’e-mail est extrêmement sûr
    On peut attendre éternellement, ou bien commencer à construire une solution
  • Il y a une différence importante entre un identifiant e-mail au sein de son propre système et l’e-mail en tant qu’identifiant d’un compte Google lié. Je suis d’accord pour dire que, dans un système que l’on contrôle, l’e-mail fonctionne à peu près comme identité, mais dès qu’on le relie à un système externe, c’est, comme le dit Google, une très mauvaise approche. C’est éphémère, cela peut être lié à plusieurs comptes, et il n’y a aucune raison de l’utiliser quand un véritable ID exploitable existe déjà
  • J’aimerais vraiment voir une comparaison entre LastLogin et Dex. Comme les deux sont en Go, ça m’intéresse particulièrement. Je serais aussi curieux de savoir si Dex a été évalué
    J’ai aussi un peu joué avec Portier et l’ancien Mozilla Persona, mais au final, gérer les problèmes de normalisation des e-mails m’a semblé être soit un combat perdu d’avance, soit un combat beaucoup trop difficile. J’ai presque accepté l’idée que je mourrai avant qu’une bonne solution ne soit trouvée, et j’ai reporté mon attention ailleurs

• Est-ce vraiment un problème de Google OAuth, ou bien l’échec de nombreux fournisseurs de services à vérifier correctement les claims des jetons OAuth avant d’autoriser l’accès ? Cela ressemble plutôt à la seconde hypothèse

  • On dirait que le problème vient du fait que ces fournisseurs de services suivent les règles d’alias de Google tout en ignorant le fait qu’il ne faut pas utiliser l’e-mail comme identifiant principal [1]. Ce qui est amusant, c’est qu’ils auraient été en sécurité s’ils avaient mieux respecté la spécification, et qu’à l’inverse, s’ils l’avaient moins respectée en traitant les alias comme des e-mails distincts, cela aurait au moins été plus sûr
    [1] https://developers.google.com/identity/openid-connect/openid...
  • À mon avis, OAuth fonctionne comme prévu. user@domain et user+wildcard@domain sont toujours vérifiés comme des adresses e-mail que l’utilisateur « possède », et fournissent donc une authentification et une identité valides pour cette adresse e-mail
    Le problème se situe du côté du site Google Workspace de l’organisation. Les administrateurs ne peuvent pas révoquer les identifiants de comptes ou d’e-mails qu’ils ne peuvent pas voir. Le point essentiel est dans la phrase « ces comptes Google non-Gmail ne sont en réalité pas membres de l’organisation Google, et n’apparaissent donc ni dans les paramètres d’administration ni dans la liste des utilisateurs Google »

• Si l’on suit ce flux, on peut créer un compte Google avec l’adresse e-mail des tickets de support, consulter potentiellement le contenu de ces tickets pour finaliser la création du compte, puis utiliser cette adresse e-mail de support pour se connecter en OAuth à plusieurs services. Cela pourrait affecter beaucoup de petites entreprises

• La principale conclusion que j’en tire ici, c’est que l’authentification web reste un chaos épouvantable

  • Parce que les gens ne lisent pas la documentation et supposent simplement que cela fonctionne comme ils l’imaginent
  • Si l’on se demande pourquoi des gens sains d’esprit et pragmatiques utilisent et exigent encore une simple authentification par mot de passe, c’est parce que les mots de passe, eux, fonctionnent correctement

• La spécification OIDC dit qu’il ne faut pas utiliser l’e-mail comme identifiant unique. Pour le nom d’utilisateur de l’application, il faut utiliser les champs iss et sub
  La raison est d’abord évidente : une adresse e-mail peut être réutilisée. Si un prestataire travaille à la fois pour Business A et Business B, et que les deux ont créé son compte utilisateur dans leur service d’authentification, une plateforme SaaS ne peut pas associer une seule adresse e-mail à un unique client B2B. Ensuite, les adresses e-mail changent. Les entreprises sont rachetées, changent de nom, fusionnent, et les noms des personnes changent aussi à cause d’un mariage, d’un divorce ou d’un choix personnel. Implémenter le SSO dans une startup a été vraiment difficile au début. C’est difficile à faire correctement, et il faut bien comprendre les concepts généraux ainsi qu’OIDC et OAuth2 avant de l’utiliser. Auth0 a un bon livre sur le sujet. Si l’on ne comprend pas cela, on risque fort d’implémenter ici et là une authentification password grant et de rendre son application non sécurisée

  • Lire ce genre de billet atténue parfois un peu le syndrome de l’imposteur qui s’accumule. On se dit : « si l’on s’intègre à un système tiers pour quelque chose qui représente un acteur abstrait, il faut forcément un identifiant fiable, stable et non dépendant d’une simple chaîne de caractères ». En réalité, la spécification est très claire sur ce point, et cela va au-delà même des considérations de base nécessaires à la construction d’un système un tant soit peu robuste

• On dirait une version miniature. OAuth2, en réalité, n’existe pas vraiment. OAuth2 n’est qu’un moyen pour les grandes entreprises d’implémenter leurs propres systèmes d’authentification arbitraires et propriétaires. Ce n’est pas un système d’authentification, mais une boîte à outils pour en fabriquer un. OAuth2 était donc censé devenir un standard, mais en pratique on s’est retrouvé dans un monde où chaque grand acteur a sa propre implémentation incompatible avec les autres. Bien sûr, les gens développeront en fonction des cas d’usage des grandes entreprises, mais dans ce cas le « standard » finit simplement par être la manière de faire de Google
  Et chacun traîne ensuite ce genre de petits bugs. Il faut revenir à OAuth1. Lui, c’était un vrai standard, pas une boîte à outils pour créer des standards

  • C’est moins un bug qu’un effet de bord malheureux né de la combinaison de composants précis. Des noms de domaine dont la propriété peut changer, la récupération de son propre e-mail, l’e-mail de secours et la provenance de l’e-mail, la tolérance généreuse envers les alias avec plus, et des implémenteurs de services qui ne lisent pas la documentation : voilà le résultat. Les implémenteurs ont probablement copié une solution depuis une vidéo ou un exemple simplifié où des détails avaient été omis par souci de concision
    Si vous deviez concevoir un circuit avec quelques composants PCB et ajouter résistances et transistors pour respecter les exigences de tension et de courant, on s’attendrait à ce que vous lisiez la datasheet, non ? Si vous improvisez à partir d’un exemple sommaire, le circuit fonctionnera peut-être dans bien des cas, et avec un peu de tests sur banc et de sondes il pourra peut-être tourner. Mais il peut aussi être inefficace, ou bien des composants peuvent se mettre en court-circuit, réduire le temps moyen avant panne et mécontenter les clients. Dans le pire des cas, la batterie peut s’enflammer et causer de vrais dégâts. Dans ce cas, est-ce la faute du fabricant du module PCB si l’appareil tombe en panne prématurément, ou celle du fabricant de l’appareil qui aurait dû lire la datasheet ? Je n’ai pas des attentes aussi strictes pour tout le logiciel, mais si l’on touche à l’authentification et à l’autorisation, le propriétaire du service doit être rigoureux. Le texte original dit aussi que si l’on suit la documentation, le problème n’existe pas. Alphabet a bien reconnu la faiblesse en versant une prime de bug bounty, donc l’entreprise pourrait fournir aux administrateurs des contrôles pour gérer via listes d’autorisation/refus les alias avec plus ou les rôles inexistants, ou encore limiter le transfert des e-mails liés à Apps vers des revendications extérieures à l’organisation. Ils sont probablement en train d’en mesurer l’impact, ou de déterminer la priorité de cette mesure, mais comme il s’agit surtout d’un problème côté client qui suppose que les revendications d’e-mail sont plus autoritaires et permanentes qu’elles ne le sont réellement, la priorité sera sans doute faible. La définition de « bug » dépend beaucoup de la manière dont on définit le « comportement attendu » et de qui l’attend, mais à mes yeux il ne s’agit au minimum pas d’un écart au comportement voulu, ni de quelque chose d’inattendu pour ceux qui ont correctement compris la documentation
  • Mouais... admettons. Mais en quoi l’interopérabilité entre fournisseurs a-t-elle un rapport avec cet article sur la sécurité de Google OAuth2 ?

• Qu’est-ce que je rate ? À part le système de support/Zendesk mentionné dans l’article et la méthode des anciens domaines abandonnés, si l’on crée un nouveau compte Google avec [e-mail], une vérification est demandée. Quelle est donc, en pratique, l’exploitabilité réelle ?

  • Le point clé, c’est de faire cela à l’avance quand on a un accès légitime, puis de perdre ensuite cet accès
    Prenons un compte Google [e-mail] détenu légitimement. Vous pouvez créer un nouveau compte Google avec une adresse e-mail vérifiée via un alias comme [e-mail], et lors d’une connexion via « Se connecter avec Google », Google enverra alors une revendication d’e-mail [e-mail]. Plus tard, si vous êtes licencié de mydomain.com, vous ne pourrez plus vous connecter avec le compte relié au véritable [e-mail], parce qu’un administrateur l’aura désactivé. En revanche, le nouveau compte Google [e-mail], lui, n’est pas lié à l’organisation et pourra donc continuer à se connecter. Mais à mon sens, cela ne pose problème que si le fournisseur effectue l’autorisation uniquement sur la base de la revendication d’e-mail. J’ai déjà utilisé OIDC, et il ne faut pas accorder l’accès à des ressources en analysant le texte de la revendication d’adresse e-mail. Je comprends pourquoi l’auteur a trouvé cela contre-intuitif, mais l’article précise aussi que la documentation avertit explicitement de ne pas faire cela. Le texte original dit : « La plupart des fournisseurs de services que j’ai testés n’utilisaient pas HD et se servaient de la revendication d’e-mail », très bien, mais pour en faire quoi exactement ? Est-ce que cette astuce fonctionne réellement sur des services du monde réel ? Si oui, il faudrait les nommer publiquement pour qu’ils soient critiqués. Même en supposant à tort que cette valeur est unique et immuable, cela ne donne pas automatiquement, à elle seule, un droit d’accès particulier