Teilweiser Ausfall einiger Google-OAuth-Funktionen

• Bei Diensten, die dem email claim von Google OAuth vertrauen, um Login-Berechtigungen zu bestimmen, können ausgeschiedene Mitarbeitende auch nach ihrer Entfernung aus der Google-Organisation des Unternehmens weiterhin Zugriff auf Apps wie Slack oder Zoom behalten.
• Google-Konten lassen sich auch mit Nicht-Gmail-Adressen erstellen. Durch Aliasse und Plus-Adress-Weiterleitung bei Unternehmens-E-Mails kann ein Google-Konto, das nicht zur Organisation gehört, einen E-Mail-Claim mit der Unternehmensdomain senden.
• Dieses Nicht-Gmail-Konto erscheint weder in der Admin-Oberfläche noch in der Nutzerliste der Google-Organisation des Unternehmens, doch viele Dienste erlauben den Login allein anhand der Domain am Ende der E-Mail-Adresse.
• Organisationen können das Risiko mindern, indem sie Google-Logins deaktivieren und SAML strikt erzwingen. Einige Dienste oder interne Apps bieten diese Option jedoch möglicherweise nicht an oder unterstützen SAML nicht.
• Google wurde am 4. August informiert, am 5. Oktober wurde eine Prämie von $1337 ausgezahlt, und am 16. Dezember erfolgte nach 134 Tagen die Veröffentlichung. Bis zum Veröffentlichungszeitpunkt hatte Google jedoch keine abschwächende Änderung ausgerollt.

---

Offenlegung der Schwachstelle und Zeitplan

• Aufgrund einer Schwachstelle in Google OAuth können Mitarbeitende, die aus einem Unternehmen offgeboardet und aus der Google-Organisation entfernt wurden, ihren Zugriff auf Anwendungen wie Slack oder Zoom unbegrenzt behalten.
• Bis zum Zeitpunkt der Veröffentlichung hatte Google keine Änderung ausgerollt, die dieses Risiko mindert.
• Der Zeitplan ist wie folgt:
  • 4. August: Meldung an Google und Hinweis darauf, dass Hunderte von Anwendungen betroffen sein könnten.
  • 7. August: Das Issue wurde triagiert.
  • 5. Oktober: Google zahlte $1337 für das Issue.
  • 25. November: Nichtöffentliche Sammelmeldung an Dutzende betroffene Anwendungen, darunter Zoom und Slack.
  • 16. Dezember: Veröffentlichung 134 Tage nach der Benachrichtigung von Google.

Risiko, den email claim als Identifier zu verwenden

• Der Login von Truffle Securitys Forager war zuvor von einer Microsoft-OAuth-Schwachstelle von Descope betroffen.
• Damals wurde festgestellt, dass ein Email claim gesendet werden kann, der nicht direkt von Microsoft erstellt oder verifiziert wurde, und dass der email claim im Allgemeinen kein vertrauenswürdiger Identifier ist.
• Auch die OIDC-Dokumentation von Google warnt davor, Email als primären Identifier zu verwenden.
• Der Claim email_verified wurde ebenfalls als ungewöhnlicher Punkt behandelt, es konnte jedoch keine Methode gefunden werden, aus einer nicht verifizierten E-Mail einen email claim zu erzeugen.
• Es wurden jedoch ausreichend Fälle bestätigt, in denen der email claim selbst missbraucht werden kann.

Nicht-Gmail-Google-Konten und doppelte email claims

• Ein Google-Konto kann auch mit einer bestehenden E-Mail-Adresse erstellt werden, die keine Gmail-Adresse ist.
  • Beispielsweise lässt sich ein Google-Konto mit einer Yahoo-E-Mail-Adresse erstellen.
  • Dieses Konto kann mit der eingerichteten Nicht-Gmail-Adresse den entsprechenden email claim senden.
• Ein Grund, warum die Google-Dokumentation davon abrät, E-Mail als primären Identifier zu verwenden, ist, dass zwei unterschiedliche Google-Konten denselben email claim senden können.
  • Nachdem die Nicht-Gmail-Adresse in den Einstellungen geändert wurde,
  • kann mit der E-Mail-Adresse vor der Änderung ein neues Konto erstellt werden, wodurch derselbe email claim möglich wird.

Konten, die außerhalb der Google-Organisation des Unternehmens verbleiben

• Die zentrale Lücke besteht darin, dass sich für E-Mails der Google-Organisation eines Unternehmens mithilfe von E-Mail-Aliassen und Plus-Adress-Weiterleitung Google-Konten außerhalb der Organisation erstellen lassen.
• Plus-Adressen einer Unternehmens-E-Mail können an den Posteingang des ursprünglichen Nutzers weitergeleitet werden.
• Über diesen Ablauf kann ein Plus-Adress-basiertes Nicht-Gmail-Google-Konto mit einer E-Mail der Google-Organisation des Unternehmens erstellt werden. Dieses Konto lässt sich von der Organisation nicht löschen oder offboarden.
• Viele Dienste parsen diese E-Mail und entscheiden anhand der Domain am Ende, ob ein Login erlaubt ist.
  • Mit diesem Konto kann man sich bei Zoom registrieren.
  • Mit diesem Konto kann man sich bei Slack registrieren.
• Da solche Nicht-Gmail-Google-Konten keine tatsächlichen Mitglieder der Google-Organisation sind, erscheinen sie nicht in den Admin-Einstellungen oder in der Google-Nutzerliste.

Gegenmaßnahmen für Organisationen, Service Provider und Google

• Organisationen können das Risiko mindern, indem sie Google-Logins deaktivieren und SAML strikt erzwingen.
  • Bei den meisten Service Providern funktioniert dieser Ansatz.
  • Einige Dienste bieten diese Option nicht an.
  • Interne Entwicklungsanwendungen können betroffen sein, unterstützen aber möglicherweise kein SAML.
• Service Provider können den HD claim von Google OAuth verwenden.
  • Der HD claim sendet die Domain der Google-Organisation, mit der das Konto verbunden ist.
  • Bei Konten, die keine Mitglieder einer Google-Organisation sind, ist kein HD claim enthalten.
  • Die meisten getesteten Service Provider nutzten statt HD den email claim.
• Beim HD claim bleiben wichtige Einschränkungen bestehen.
  • HD ist kein eindeutiger Identifier, sondern lediglich eine Domain.
  • Wenn eine Google-Organisation gelöscht und die Domain aufgegeben wird, kann eine andere Person diese Domain übernehmen und eine neue Google-Organisation erstellen.
  • Ein Beispiel wäre, wenn Unternehmen A von Unternehmen B übernommen wird, B die Dienste von A einstellt und die frühere Domain nicht verlängert.
  • Kauft jemand im Internet die Domain von Unternehmen A, kann diese Person sich in bestehende Service-Konten von Unternehmen A einloggen.
• Service Provider können JIT-Kontoerstellung nicht als Standardfunktion zulassen und stattdessen auf nur per Einladung oder LDAP-Gruppen basierte Konto-Provisionierung umstellen.
• Google könnte breit gegensteuern, indem Google-Konten verboten werden, die mit Domains bestehender Google-Organisationen erstellt werden.
  • Google verbietet intern Konten mit google.com.
  • Denselben Schutz könnte Google auf andere Organisationen ausweiten.
• Weitere Gegenmaßnahmen auf Google-Seite wären ein Verbot der Registrierung von Google-Konten mit Plus-Adressen, ein Verbot der Registrierung mit Google-E-Mail-Aliassen sowie bessere Admin-Einstellungen, mit denen Organisationen die entsprechenden Optionen konfigurieren können.

Zusätzliche Auswirkungen: Support-E-Mails und Magic-Link-Flows

• Auch ohne anfängliche Zugriffsrechte kann es technisch möglich sein, auf Zoom oder Slack einer Organisation zuzugreifen.
• Dieser Ablauf nutzt Schwachstellenforschung anderer Forscher zu magic link sign-in flows.
• Einige Support- und Ticketsysteme wie Zendesk können Support-Tickets per E-Mail erstellen.
  • Mit der E-Mail-Adresse des Support-Tickets kann ein Google-Konto erstellt werden.
  • Durch Einsehen des Ticketinhalts könnte die Kontoerstellung abgeschlossen werden.
  • Anschließend kann mit dieser Support-E-Mail-Adresse ein OAuth-Login versucht werden.
• Es ist unsicher, die Funktion email to support auf der Hauptdomain beizubehalten; eine mögliche Maßnahme ist, die Zendesk-Support-E-Mail als alternative E-Mail-Adresse zu konfigurieren.

Zweck der Veröffentlichung und verbleibende Probleme

• Dass ehemalige Mitarbeitende auf Plattformen wie Slack oder Zoom Zugriff behalten, geht auf eine Lücke im Google-OAuth-System zurück.
• Google verfügt über die Möglichkeit, umfassende Korrekturen vorzunehmen, die dieses Problem mindern können.
• Ziel der Veröffentlichung ist es, über eine geringfügige Dokumentationsänderung hinaus tatsächliche Änderungen anzustoßen.
• Google triagierte das Issue zwar schnell, doch entgegen der eigenen 90-Tage-Praxis für Verbesserungen wurde das Problem erst am 134. Tag veröffentlicht.

[GN⁺]

Meinungen auf Hacker News

• Ich arbeite in diesem Bereich und habe in den letzten 3–4 Jahren bei mehreren Login-Providern und SaaS-Unternehmen mehr als 20 Varianten dieser Schwachstelle behandelt. Der Blogbeitrag ist richtig, aber ich denke, das Kernproblem ist inzwischen zu weit fortgeschritten, um es noch zu beheben. Delegierte Authentifizierung im gesamten Internet ist ein komplettes Durcheinander, und da ich viel mit Ingenieuren von Google und Microsoft gesprochen habe, bin ich sicher, dass sie diese Problemklasse bereits kennen. Würde man das heutige Verhalten ändern, würden jedoch zu viele bestehende Dienste und jahrzehntealte Enterprise-Login-Implementierungen kaputtgehen
  Die „Lösung“ zum jetzigen Zeitpunkt ist simpel. Wenn eine Website „Sign in with XYZ“ nutzt, sollte sie der vom Provider gelieferten E-Mail-Adresse nicht vertrauen. Man sollte nicht allein anhand der E-Mail-Domain besondere Rechte vergeben, sondern immer eine eigene Bestätigungs-E-Mail senden, bevor man etwas in der Datenbank als verifiziert markiert. Die großen OAuth-Provider haben auch ihre Dokumentation aktualisiert, um das klarzustellen, und der Artikel selbst weist darauf hin. Deshalb ist es eher überraschend, dass überhaupt eine Prämie gezahlt wurde

  • Es fühlt sich wie das Ergebnis davon an, dass Organisationen nicht wirklich verstehen, wie komplex dieser Bereich in der Praxis ist. Wenn man sieht, wie OAuth2 + OIDC in verschiedenen Unternehmen eingeführt wurde, wurde es nie aus einer Security-first-Perspektive verkauft, sondern immer als Feature wie „Login mit x“. Selbst wenn man versucht, Abläufe mit PKCE sicherer zu machen, wird es wegen chaotischer Plattformumsetzungen bei Cookie-Sharing, Redirect-Handling usw. zu einem Whac-a-Mole-Spiel. Die Grundlagen von 3-legged OAuth2 sind solide, und es gibt viele Vorläufer wie CAS, aber die OpenID Foundation sollte für die Art und Weise, wie sie OIDC vermarktet und verkauft hat, deutlich kritisiert werden
  • Scheitert der Ansatz „Nicht allein anhand der E-Mail-Domain besondere Rechte vergeben, sondern immer eine eigene Bestätigungs-E-Mail senden, bevor man etwas in der Datenbank als verifiziert markiert“ nicht, wenn ein Nutzer bei Google ein Konto mit Plus-Adresse registriert und sich dann vor dem Rauswurf mit diesem Google-Konto beim Dienst angemeldet hat? Es sei denn, man sendet bei jedem Login eine Bestätigungs-E-Mail
  • In diesem konkreten Fall kann der Angreifer die Bestätigungs-E-Mail tatsächlich empfangen; daher ist mir nicht klar, welchen Sinn dieser Bestätigungsschritt haben soll
  • „Immer eine eigene Bestätigungs-E-Mail senden, bevor man etwas in der Datenbank als verifiziert markiert“ macht das Login mit x-Feature aus Nutzersicht nutzlos
  • Hätte Google nicht Registrierungen über Domains von Google-Apps-Kunden verhindern können? Das klingt nicht so, als würde es konkret etwas kaputtmachen

• In diesem Zusammenhang sollten mehr Service-Provider aufhören, E-Mail als primären Identifier zu verwenden, wie es die Google-Dokumentation empfiehlt. Als wir in Google Apps Benutzernamen geändert haben, habe ich viel Zeit damit verbracht, Probleme bei Slack, Datadog, GoLinks usw. zu beheben

  • Was sollten Provider stattdessen verwenden? Ich dachte immer, E-Mail sei der stabilste globale Identifier für einen Nutzer, aber diese Annahme scheint falsch zu sein
  • Da kann ich schwer zustimmen. Solche Richtlinien schieben die Verantwortung nur auf die Anwendungsentwickler ab, und die meisten werden entweder gar nichts tun oder es jeweils anders implementieren
    Der richtige Weg hier wäre, eine API bereitzustellen, die zu den Anforderungen der nutzenden Anwendung passt und zusätzliche Verantwortung minimiert. In diesem Fall hätte Google meiner Meinung nach email_verified auf false setzen sollen, damit die Anwendung oder ein nachgelagerter IdP erkennen kann, dass eine zusätzliche Verifizierung nötig ist

• Wenn user@domain bereits von Googles Mailservern verarbeitet wird und deshalb Plus-Routing-Regeln angewendet werden, verstehe ich nicht, warum man mit einer E-Mail wie user+suffix@domain ein neues Google-Konto erstellen kann. Selbst ohne Missbrauch scheint das geradezu dafür gemacht, verwirrende Mail-Konfigurationen zu erzeugen

  • Domains können ihre Mailserver frei umziehen. Google behandelt [e-mail] auf eine bestimmte Weise, andere Server möglicherweise nicht. Am Ende sind es zwei verschiedene eindeutige E-Mail-Adressen und sollten im gesamten Internet auch so behandelt werden
  • Diese Alias-Funktion scheint über sich hinausgewachsen zu sein. Besonders in Googles Größenordnung
  • Es ist schlimmer als user+suffix@domain. Immerhin ist +XYZ in den E-Mail-RFCs festgelegt. Google geht weiter und hat entschieden, dass auch Punkte im Namen als reguläre E-Mail gelten. Zum Beispiel ist [e-mail] dasselbe wie [e-mail], und alle Mails werden an Letzteres geroutet
  • Das liegt daran, dass Googles Authentifizierungssystem sehr alte Legacy ist. Ein „Google-Konto“ ist einfach ein String

• Zu der Stelle „Ich war überrascht zu erfahren, dass Microsoft E-Mail-Claims sendet, die Microsoft weder erstellt noch verifiziert hat, und dass E-Mail-Claims im Allgemeinen nicht als vertrauenswürdig gelten“: Auch wenn das ursprünglich vielleicht so beabsichtigt war, finde ich es sehr nützlich, dass OIDC flexibler sein kann. Ich betreibe zum Beispiel einen kostenlosen Login-Anbieter[0], der Identitäten über übergeordnete OIDC-Anbieter oder direkt per E-Mail bei einem vierten Beteiligten, dem Identity Provider (IdP), verifiziert und dabei eine Privacy-Barriere zwischen App und IdP schafft. Mit anderen Worten: Google kann nicht nachverfolgen, bei welchen Apps sich der Nutzer überall anmeldet.
  Dass man seine eigene E-Mail-Adresse zu Google mitbringen kann, bedeutet, dass man die Sicherheit und User Experience von Google OIDC mit der Privatsphäre von E-Mail+Passwort bekommen kann – mit dem großen Vorbehalt, dass man nun LastLogin statt Google vertrauen muss. Wir arbeiten auch an einem Protokoll, das diese Abhängigkeit reduziert. Der Aussage „Die Google-Dokumentation hat tatsächlich davor gewarnt, E-Mail als Identifier zu verwenden“ widerspreche ich komplett. E-Mail ist die einzige echte föderierte Identität, die Menschen tatsächlich nutzen. Bis eine bessere Alternative breit ausgerollt ist, sollten wir meiner Ansicht nach E-Mail-Adressen als Identität behandeln.
  [0]: https://lastlogin.io

  • Ich widerspreche der Aussage, „E-Mail-Adressen als Identität behandeln“ zu sollen. Dafür gibt es zwei Gründe.
    Außerhalb der westlichen Welt sind Mobiltelefone verbreiteter als Computer, und die UI ist in der Regel auch einfacher; daher ist die Telefonnummer eher die Identität. Außerdem übergibt man damit die Identität vollständig an den E-Mail-Anbieter. Gesichtslose Organisationen wie Google können den Zugriff ohne Vorwarnung oder Einspruchsverfahren sperren – und tun das auch –, sodass man alles verlieren kann. Zum Hintergrund: Ich habe Oktas OAuth- und OIDC-Produkte auf den Markt gebracht, den entsprechenden LinkedIn-Kurs erstellt und mache das jetzt wieder bei Pangea Cyber.
  • „E-Mail-Adressen als Identität behandeln“ – unter der Annahme, dass niemand E-Mail-Adressen teilt und E-Mail extrem sicher ist?
    Man kann ewig warten, oder man kann anfangen, Lösungen zu bauen.
  • Es gibt einen wichtigen Unterschied zwischen einer E-Mail als Identifier innerhalb des eigenen Systems und einer E-Mail als Identifier eines verknüpften Google-Kontos. Ich stimme zu, dass E-Mail innerhalb eines Systems, das man kontrolliert, als Identität halbwegs funktioniert; beim Verknüpfen mit externen Systemen ist es aber, wie Google sagt, ein miserabler Ansatz. Sie ist temporär, kann an mehrere Konten gebunden sein, und wenn es eine echte verwendbare ID gibt, gibt es keinen Grund, sie nicht zu nutzen.
  • Es wäre wirklich toll, LastLogin mit Dex zu vergleichen. Da beide in Go geschrieben sind, interessiert mich das besonders. Mich würde auch interessieren, ob Dex evaluiert wurde.
    Mit Portier und dem früheren Mozilla Persona habe ich auch etwas herumgespielt, aber am Ende wirkte der Umgang mit E-Mail-Normalisierung wie ein verlorener oder viel zu schwieriger Kampf. Ich habe mich praktisch damit abgefunden, dass ich sterben werde, bevor eine gute Lösung den Weg bereitet, und meine Aufmerksamkeit auf anderes gelenkt.

• Ist das wirklich ein Google-OAuth-Problem, oder eher ein Versagen vieler Service Provider, die Claims im OAuth-Token nicht korrekt zu prüfen, bevor sie Zugriff gewähren? Es sieht nach Letzterem aus.

  • Das Problem scheint zu sein, dass diese Service Provider zwar Googles Alias-Regeln befolgen, aber ignorieren, dass E-Mail nicht als primärer Identifier verwendet werden sollte [1]. Interessant ist: Hätten sie sich besser an die Spezifikation gehalten, wäre es in Ordnung gewesen; und hätten sie sich umgekehrt weniger an die Spezifikation gehalten und Aliasse als unterschiedliche E-Mails behandelt, wäre es zumindest sicherer gewesen.
    [1] https://developers.google.com/identity/openid-connect/openid...
  • Meiner Ansicht nach verhält sich OAuth wie erwartet. user@domain und user+wildcard@domain sind weiterhin als E-Mail-Adressen verifiziert, die der Nutzer „besitzt“, und liefern daher eine gültige Authentifizierung und Identität für diese E-Mail-Adresse.
    Das Problem liegt auf der Seite der Google-Organisation-Websites. Ein Administrator kann die Zugangsdaten von Konten oder E-Mail-Adressen, die er nicht sehen kann, nicht widerrufen. Der entscheidende Punkt ist: „Diese Nicht-Gmail-Google-Konten sind tatsächlich keine Mitglieder der Google-Organisation und erscheinen daher nicht in den Admin-Einstellungen oder in der Google-Nutzerliste.“

• Wenn man diesem Ablauf folgt, kann man mit der E-Mail-Adresse für Support-Tickets ein Google-Konto erstellen, potenziell den Ticketinhalt einsehen, um die Kontoerstellung abzuschließen, und sich dann mit dieser Support-E-Mail-Adresse per OAuth bei mehreren Diensten anmelden. Das kann viele kleine Unternehmen betreffen.

• Meine wichtigste Erkenntnis daraus ist, dass Web-Authentifizierung immer noch ein furchtbares Durcheinander ist.

  • Weil Menschen die Dokumentation nicht lesen und einfach annehmen, dass es so funktioniert, wie sie es sich vorstellen.
  • Wenn man fragt, warum vernünftige und pragmatische Leute immer noch einfache Passwort-Authentifizierung verwenden und verlangen: weil Passwörter funktionieren.

• Die OIDC-Spezifikation sagt, dass E-Mail nicht als eindeutiger Identifier verwendet werden darf. Als Benutzername der Anwendung sollten die Felder iss und sub verwendet werden.
  Der Grund ist zunächst offensichtlich: E-Mail-Adressen von Nutzern können wiederverwendet werden. Wenn ein Contractor sowohl für Unternehmen A als auch für Unternehmen B arbeitet und beide in einem Authentifizierungsdienst ein Benutzerkonto für diese Person anlegen, kann eine SaaS-Plattform eine einzelne E-Mail-Adresse nicht einem einzigen B2B-Kunden zuordnen. Zweitens ändern sich E-Mail-Adressen. Unternehmen werden übernommen, umbenannt und fusioniert; auch Personennamen ändern sich durch Heirat, Scheidung oder persönliche Entscheidung. SSO in einem Startup zu implementieren, war anfangs wirklich schwierig. Es ist schwer, es richtig zu machen, und man muss die allgemeinen Konzepte sowie OIDC und OAuth2 gut verstehen, bevor man es verwendet. Auth0 hat ein gutes Buch dazu. Wenn man das nicht versteht, implementiert man wahrscheinlich überall Password-Grant-Authentifizierung und macht die Anwendung unsicher.

  • Wenn ich solche Texte lese, wird das aufgestaute Impostor-Syndrom manchmal etwas kleiner. Man denkt sich: „Wenn man ein Drittsystem für etwas integriert, das einen abstrakten Akteur repräsentiert, sollte es einen stabilen, nicht bloß stringartigen, vertrauenswürdigen Identifier geben.“ Tatsächlich ist die Spezifikation in diesem Punkt sehr klar, und es geht kaum über die grundlegenden Überlegungen hinaus, die man beim Bau eines halbwegs robusten Systems anstellen sollte.

• Klingt wie ein kleines Vorschaubild. So etwas wie OAuth2 gibt es eigentlich nicht. OAuth2 ist nur eine Methode, mit der Großkonzerne ihre eigenen willkürlichen, proprietären Authentifizierungssysteme implementieren. Es ist kein Authentifizierungssystem, sondern ein Werkzeugkasten zum Bau eines Authentifizierungssystems. Deshalb sollte OAuth2 ein Standard werden, tatsächlich sind wir aber in einer Welt gelandet, in der jeder Großkonzern zueinander inkompatible Implementierungen hat. Natürlich entwickeln die Leute passend zu den Use Cases der Großkonzerne, aber dann wird der „Standard“ am Ende so etwas wie die Art, wie Google es macht.
  Und jeder hat dann solche kleinen Bugs. Wir sollten zu OAuth1 zurück. Das war ein echter Standard und kein Werkzeugkasten zum Erstellen eines Standards.

  • Das ist weniger ein Bug als vielmehr eine unglückliche Nebenwirkung aus dem Zusammenspiel bestimmter Komponenten: Domainnamen, deren Eigentümer wechseln können, Bring-your-own-E-Mail, Backup-E-Mails und E-Mail-Herkunft, die großzügige Zulassung von Plus-Aliasen sowie Service-Implementierer, die die Dokumentation nicht lesen. Die Implementierer haben die Lösung vermutlich aus einem Video oder aus Beispielen kopiert, die der Kürze halber etwas weggelassen haben.
    Wenn man mit ein paar PCB-Bauteilen eine Schaltung entwirft und Widerstände und Transistoren passend zu Spannungs- und Stromanforderungen einsetzen muss, sollte man dann nicht erwarten, dass das Datenblatt gelesen wird? Wenn man aus einem einfachen Beispiel grob schätzt und einfach durchzieht, funktioniert die Schaltung in vielen Fällen vielleicht, und mit ein wenig Bench-Testing und Probing bekommt man sie vielleicht zum Laufen. Sie kann aber ineffizient sein, oder Bauteile können kurzschließen, was die mittlere Ausfallzeit senkt und Kunden unglücklich macht. Im schlimmsten Fall entzündet sich der Akku und es entsteht echter Schaden. Ist es dann die Schuld des PCB-Modulherstellers, dass das Gerät vorzeitig ausfällt, oder die Verantwortung des Geräteherstellers, der das Datenblatt hätte lesen müssen? An sämtliche Software würde ich keine so strengen Erwartungen stellen, aber wenn es um Authentifizierung und Autorisierung geht, sollten Service-Betreiber meiner Meinung nach gründlich sein. Der Originaltext sagt ebenfalls, dass das Problem nicht existiert, wenn man die Dokumentation befolgt. Alphabet hat ein Bug Bounty gezahlt und die Schwachstelle damit anerkannt; also könnte man Unternehmensadministratoren Controls geben, um Plus-Aliase oder nicht existierende Rollen per Allow-/Deny-List zu verwalten, oder verhindern, dass mit Apps verbundene E-Mails als Claims außerhalb der Organisation übertragen werden. Vermutlich messen sie gerade die Auswirkungen oder priorisieren, ob sie diese messen sollen; da es sich aber um ein Client-Problem handelt, bei dem E-Mail-Claims als autoritativer und dauerhafter angenommen werden, als sie tatsächlich sind, dürfte die Priorität niedrig sein. Die Definition von „Bug“ hängt stark davon ab, wie „erwartetes Verhalten“ definiert wird und wer es erwartet. Aber zumindest weicht es nicht vom beabsichtigten Verhalten ab und ist für Leute, die die Dokumentation richtig verstanden haben, auch nicht unerwartet.
  • Hm ... nehmen wir das so an. Hat die Kompatibilität zwischen Providern etwas mit diesem Artikel über Google-OAuth2-Sicherheit zu tun?

• Übersehe ich etwas? Abgesehen vom im Artikel erwähnten Support-System/Zendesk und der Methode mit verwaisten alten Domains wird beim Erstellen eines neuen Google-Kontos als [e-mail] eine Verifizierung verlangt. Wie groß ist die reale Ausnutzbarkeit also?

  • Der Kernpunkt ist, dass man es im Voraus tut, während man legitimen Zugriff hat, und diesen Zugriff später verliert.
    Nehmen wir zum Beispiel an, es gibt legitimerweise ein Google-Konto [e-mail]. Man kann ein neues Google-Konto mit einer verifizierten E-Mail-Adresse wie [e-mail] erstellen, und bei „Mit Google anmelden“ sendet Google dann den E-Mail-Claim [e-mail]. Wenn man später bei mydomain.com entlassen wird, kann man sich mit dem Konto, das mit dem eigentlichen [e-mail] verbunden ist, nicht mehr anmelden, weil der Administrator es deaktiviert hat. Das neue Google-Konto [e-mail] ist jedoch nicht mit der Organisation verbunden und kann weiterhin verwendet werden. Meiner Ansicht nach wird das allerdings nur dann zum Problem, wenn der Provider Autorisierung ausschließlich anhand des E-Mail-Claims vornimmt. Ich habe früher OIDC verwendet; man sollte den Text des E-Mail-Adress-Claims nicht parsen, um Zugriff auf Ressourcen zu gewähren. Ich verstehe, warum der Autor das kontraintuitiv fand, aber im Artikel steht auch, dass die Dokumentation davor warnt, genau das zu tun. Im Original heißt es: „Die meisten Service Provider, die ich getestet habe, nutzten nicht HD, sondern den E-Mail-Claim“ – gut, aber wofür genau „nutzen“ sie ihn? Funktioniert dieser Trick bei realen Diensten tatsächlich? Wenn ja, sollten sie namentlich genannt werden, damit sie Kritik einstecken. Selbst wenn dieser Wert fälschlich als eindeutig und unveränderlich angenommen wird, entsteht daraus allein nicht zwangsläufig irgendeine Zugriffsberechtigung.