Se produjo una falla parcial en algunas funciones de Google OAuth

• En los servicios que confían en el email claim de Google OAuth para determinar permisos de inicio de sesión, un exempleado puede mantener acceso a apps como Slack y Zoom incluso después de haber sido eliminado de la organización de Google de la empresa
• También es posible crear una cuenta de Google con un correo que no sea de Gmail, y usando alias del correo corporativo o reenvío con direcciones plus se puede hacer que una cuenta de Google fuera de la organización envíe un email claim con el dominio de correo de la empresa
• Esta cuenta no-Gmail no aparece en la consola de administración ni en la lista de usuarios de la organización de Google de la empresa, pero muchos servicios permiten iniciar sesión mirando solo el dominio al final del correo
• Las organizaciones pueden mitigarlo desactivando el inicio de sesión con Google y aplicando SAML de forma estricta, pero algunos servicios o apps internas podrían no ofrecer esta opción o no ser compatibles con SAML
• El problema fue reportado a Google el 4 de agosto, se pagó una recompensa de $1337 el 5 de octubre, y se hizo público el 16 de diciembre tras 134 días, pero hasta el momento de la publicación Google no había desplegado cambios de mitigación

---

Divulgación de la vulnerabilidad y cronología

• Una vulnerabilidad en Google OAuth permite que empleados dados de baja y eliminados de la organización de Google de una empresa conserven acceso indefinido a aplicaciones como Slack y Zoom
• Hasta el momento de la publicación, Google no había desplegado cambios para mitigar este riesgo
• La cronología es la siguiente
  • 4 de agosto: se reportó a Google y se indicó que cientos de aplicaciones podrían verse afectadas
  • 7 de agosto: el problema fue triageado
  • 5 de octubre: Google pagó $1337 por el hallazgo
  • 25 de noviembre: se hizo una notificación privada masiva a decenas de aplicaciones afectadas, incluidas Zoom y Slack
  • 16 de diciembre: publicación 134 días después de la notificación a Google

El riesgo de usar el email claim como identificador

• El inicio de sesión de Forager de Truffle Security ya se había visto afectado antes por la vulnerabilidad de Microsoft OAuth de Descope
• En ese caso se confirmó que Microsoft podía enviar un Email claim que no generaba ni validaba directamente, y que el email claim no suele ser un identificador confiable
• La documentación OIDC de Google también advierte que no se debe usar Email como identificador principal
• El claim email_verified también se consideró un punto peculiar, pero no se encontró una forma de generar un email claim a partir de un correo no verificado
• Aun así, sí se confirmó suficientemente que el email claim por sí mismo puede ser explotado

Cuentas de Google no-Gmail y email claims duplicados

• Es posible crear una cuenta de Google usando una dirección de correo existente aunque no sea de Gmail
  • Por ejemplo, se puede crear una cuenta de Google con una dirección de Yahoo
  • Esa cuenta puede enviar su propio email claim con ese correo no-Gmail configurado
• Una de las razones por las que la documentación de Google dice que no debe usarse el correo como identificador principal es que dos cuentas de Google distintas pueden enviar el mismo email claim
  • Se modifica el correo no-Gmail en la configuración
  • Luego se crea una nueva cuenta con la dirección anterior, y así se puede obtener el mismo email claim

Cuentas que permanecen fuera de la organización de Google de la empresa

• La falla clave es que se pueden crear cuentas de Google fuera de la organización usando alias de correo y reenvío con direcciones plus sobre correos de la organización de Google de la empresa
• Las direcciones plus del correo corporativo pueden reenviarse a la bandeja de entrada del usuario original
• Con este flujo se puede crear una cuenta de Google no-Gmail basada en una dirección plus usando el correo de la organización de Google de la empresa, y esa cuenta no puede ser eliminada ni dada de baja por la organización
• Muchos servicios analizan este correo y deciden si el acceso está permitido según el dominio al final
  • Con esta cuenta se puede registrar en Zoom
  • Con esta cuenta se puede registrar en Slack
• Como estas cuentas de Google no-Gmail no son miembros reales de la organización de Google, no aparecen en la configuración de administración ni en la lista de usuarios de Google de la empresa

Mitigaciones para organizaciones, proveedores de servicios y Google

• Las organizaciones pueden mitigarlo desactivando el inicio de sesión con Google y forzando SAML de manera estricta
  • Este enfoque funciona en la mayoría de los proveedores de servicios
  • Algunos servicios no ofrecen esta opción
  • Las aplicaciones desarrolladas internamente pueden verse afectadas y no soportar SAML
• Los proveedores de servicios pueden usar el HD claim de Google OAuth
  • El HD claim envía el dominio de la organización de Google a la que está vinculada la cuenta
  • Las cuentas que no pertenecen a una organización de Google no incluyen HD claim
  • La mayoría de los proveedores de servicios analizados usaban el email claim en lugar de HD
• El HD claim todavía tiene limitaciones importantes
  • HD no es un identificador único, sino solo un dominio
  • Si una organización de Google se elimina y el dominio queda abandonado, otra persona puede obtener ese dominio y crear una nueva organización de Google
  • Un ejemplo sería que la empresa A sea adquirida por la empresa B, que B cierre los servicios de A y no renueve el dominio anterior
  • Si alguien en internet compra el dominio de la empresa A, podría iniciar sesión en cuentas de servicios antiguas de la empresa A
• Los proveedores de servicios pueden dejar de permitir la creación JIT de cuentas como función general y pasar a aprovisionamiento solo por invitación o basado en grupos LDAP
• Google podría mitigar ampliamente el problema prohibiendo cuentas de Google creadas con dominios que ya pertenezcan a organizaciones de Google existentes
  • Google ya prohíbe por su cuenta las cuentas google.com
  • Esa misma protección podría ampliarse a otras organizaciones
• Otras mitigaciones del lado de Google incluyen prohibir el registro de cuentas de Google con direcciones plus, prohibir el registro con alias de correo de Google y ofrecer mejores opciones de administración para que las organizaciones configuren estos controles

Impacto adicional: correos de soporte y flujos con magic link

• Incluso sin acceso inicial, técnicamente podría ser posible entrar a los espacios de Zoom o Slack de una organización
• Este flujo aprovecha investigaciones previas de otros investigadores sobre vulnerabilidades en magic link sign-in flows
• Algunos sistemas de soporte o tickets, como Zendesk, permiten crear tickets por correo
  • Se puede crear una cuenta de Google con la dirección de correo del ticket de soporte
  • Es posible completar la creación de la cuenta revisando el contenido del ticket
  • Después se puede intentar iniciar sesión por OAuth con esa dirección de soporte
• No es seguro mantener la función de email to support en el dominio principal, y una opción es configurar el correo de soporte de Zendesk como dirección de correo alternativa

Objetivo de la divulgación y problemas pendientes

• El problema de que ex empleados mantengan acceso en plataformas como Slack y Zoom proviene de una falla en el sistema Google OAuth
• Google tiene capacidad para aplicar correcciones amplias que mitiguen este problema
• El objetivo de la divulgación es impulsar cambios reales más allá de pequeñas modificaciones en la documentación
• Google hizo el triage del problema con rapidez, pero a diferencia de su propia práctica de mejora en 90 días, el problema se publicó hasta el día 134

[GN⁺]

Opiniones de Hacker News

• Trabajo en esta área y, durante los últimos 3 o 4 años, he tratado más de 20 variantes de esta vulnerabilidad en varios proveedores de inicio de sesión y empresas SaaS. El artículo del blog es correcto, pero creo que el problema central ya llegó demasiado lejos como para arreglarlo. La autenticación delegada en todo internet es un desastre total, y como he hablado mucho con ingenieros de Google y Microsoft, estoy seguro de que ya conocen esta familia de problemas. Solo que cambiar el comportamiento actual rompería demasiados servicios existentes e implementaciones de login corporativo de hace décadas.
  La “solución” en este momento es simple. Si un sitio usa “Sign in with XYZ”, no debe confiar en la dirección de correo que le envía el proveedor. No otorguen privilegios especiales solo por el dominio del correo y siempre envíen un correo de verificación propio antes de marcar algo como verificado en la base de datos. Los principales proveedores de OAuth también actualizaron su documentación para dejar esto claro, y el propio artículo lo señala. Por eso, de hecho me sorprende que hayan pagado una recompensa.

  • Se siente como el resultado de que las organizaciones no entienden bien lo compleja que es realmente esta área. Al ver cómo se adopta OAuth2 + OIDC en varias empresas, siempre se vendió como una funcionalidad, tipo “iniciar sesión con x”, no desde una perspectiva de seguridad primero. Incluso cuando se intenta hacer más seguro el flujo con cosas como PKCE, cada plataforma se comporta de forma desastrosa con el intercambio de cookies o el manejo de redirecciones, y termina siendo un juego de golpear topos. Los fundamentos del OAuth2 de tres partes son sólidos y hay muchos precedentes como CAS, pero la OpenID Foundation merece muchas críticas por la forma en que comercializó y vendió OIDC.
  • ¿No falla el enfoque de “no otorguen privilegios especiales solo por el dominio del correo y siempre envíen un correo de verificación propio antes de marcar algo como verificado en la base de datos” si el usuario registró una cuenta en Google con una dirección con plus addressing y luego inició sesión en el servicio con esa cuenta de Google antes de que lo expulsaran? A menos que mandes un correo de verificación en cada inicio de sesión.
  • En este caso específico, el atacante sí puede recibir el correo de verificación, así que no entiendo qué sentido tendría ese proceso de verificación.
  • “Siempre envíen un correo de verificación propio antes de marcar algo como verificado en la base de datos” vuelve inútil, desde el punto de vista del usuario, la función de iniciar sesión con x.
  • ¿Google no podía impedir los registros usando el dominio de un cliente de Google Apps? Eso no parece que fuera a romper nada en particular.

• En relación con esto, más proveedores de servicios deberían dejar de usar el correo electrónico como identificador principal, tal como recomienda la documentación de Google. Cuando cambiamos nombres de usuario en Google Apps, pasé mucho tiempo resolviendo problemas en Slack, Datadog, GoLinks y otros.

  • ¿Qué deberían usar los proveedores? Siempre pensé que el correo era el identificador global más estable de un usuario, pero parece que esa suposición está equivocada.
  • Me cuesta estar de acuerdo. Este tipo de guía solo traslada la responsabilidad a los desarrolladores de aplicaciones, y es probable que la mayoría no haga nada o lo implemente cada uno a su manera.
    La dirección correcta aquí es ofrecer una API que se ajuste a las necesidades de la aplicación que la va a usar y minimice responsabilidades adicionales. En este caso, creo que Google debería haber configurado email_verified como false para que la aplicación o el IdP subordinado supiera que se necesitaba una verificación adicional.

• Si user@domain ya se procesa en los servidores de correo de Google y por eso se aplican las reglas de ruteo con plus addressing, no entiendo por qué se puede crear una nueva cuenta de Google con un correo como user+suffix@domain. Incluso si no fuera abuso, parece perfecto para crear configuraciones de correo confusas.

  • Los dominios pueden mover libremente sus servidores de correo. Google procesa [e-mail] de una forma específica, pero otros servidores quizás no. Al final, ambas son direcciones de correo únicas distintas, y así deberían tratarse en todo internet.
  • Esta función de alias parece haberse vuelto demasiado compleja para lo que es. Especialmente a la escala de Google.
  • Es peor que user+suffix@domain. Al menos +XYZ está especificado en los RFC de correo electrónico. Google va más allá y decidió que los puntos dentro del nombre también se consideran un correo normalizado. Por ejemplo, [e-mail] es lo mismo que [e-mail], y todo el correo se enruta a este último.
  • Es porque el sistema de autenticación de Google es un legado muy antiguo. Una “cuenta de Google” es simplemente una cadena de texto.

• Sobre la parte de “me sorprendió saber que Microsoft envía claims de correo electrónico que Microsoft no creó ni verificó, y que, en general, los claims de email no se consideran confiables”, aunque quizá esa haya sido la intención original, creo que es muy útil que OIDC pueda ser más flexible. Por ejemplo, opero un proveedor de login gratuito[0], que verifica la identidad con un proveedor de identidad (IdP) de cuarta parte mediante OIDC ascendente o email directo, y crea una barrera de privacidad entre la app y ese IdP. Es decir, evita que Google pueda rastrear todas las apps en las que inicia sesión el usuario
  Que puedas llevar tu propio email a Google significa que puedes obtener la seguridad y la experiencia de usuario de Google OIDC junto con la privacidad de email+contraseña, pero con la gran salvedad de que ahora tienes que confiar en LastLogin en lugar de Google. También estamos trabajando en un protocolo para reducir esa dependencia. Estoy totalmente en desacuerdo con la parte de “la documentación de Google en realidad advertía que no se usara el email como identificador”. El email es la única identidad federada real que la gente usa de verdad. Hasta que una alternativa mejor esté ampliamente desplegada, creo que debemos tratar las direcciones de email como identidad
  [0]: https://lastlogin.io

  • No estoy de acuerdo con “debemos tratar las direcciones de email como identidad”. Hay dos razones
    Fuera de Occidente, los celulares son más comunes que las computadoras y la UI suele ser más fácil, así que es más probable que el número de teléfono sea la identidad. Además, hacer eso equivale a entregarle por completo la identidad al proveedor de email. Organizaciones sin rostro como Google pueden bloquear el acceso, y de hecho lo hacen, sin aviso ni proceso de apelación, por lo que podrías perderlo todo. Como contexto: lancé los productos de OAuth y OIDC de Okta, hice los cursos relacionados en LinkedIn y ahora lo estoy haciendo de nuevo en Pangea Cyber
  • “Debemos tratar las direcciones de email como identidad”, ¿eso asume que nadie comparte direcciones de email y que el email es muy seguro?
    Puedes esperar para siempre, o puedes empezar a construir una solución
  • Hay una diferencia importante entre un identificador de email dentro de tu propio sistema y el email como identificador de una cuenta de Google conectada. Estoy de acuerdo en que, dentro de un sistema que controlas, el email funciona más o menos como identidad, pero al conectarte con sistemas externos, como dice Google, es una forma pésima. Es temporal, puede estar vinculado a varias cuentas y, si existe un ID real que se puede usar, no hay motivo para no usarlo
  • Sería genial una comparación entre LastLogin y Dex. Como ambos están en Go, me da especial curiosidad. También me pregunto si evaluaron Dex
    Jugué un poco con Portier y con el antiguo Mozilla Persona, pero al final lidiar con el problema de normalización del email parecía una batalla perdida, o demasiado difícil. Casi acepté que probablemente me moriría antes de que se desarrollara una buena solución, y desvié mi atención a otra cosa

• ¿Esto es realmente un problema de Google OAuth, o es una falla de muchos proveedores de servicios que no validan correctamente los claims del token OAuth antes de permitir el acceso? Parece más bien lo segundo

  • El problema parece ser que estos proveedores de servicios siguen las reglas de alias de Google, pero ignoran el hecho de que no deben usar el email como identificador principal [1]. Lo curioso es que, si hubieran seguido mejor la especificación, habrían estado bien; y, al contrario, si hubieran seguido menos la especificación y hubieran tratado los alias como emails distintos, al menos habría sido más seguro
    [1] https://developers.google.com/identity/openid-connect/openid...
  • Creo que OAuth está funcionando como se espera. user@domain y user+wildcard@domain siguen verificándose como direcciones de email que el usuario “posee”, por lo que proporcionan autenticación e identidad válidas para esa dirección de email
    El problema está del lado del sitio web de la organización de Google. Un administrador no puede revocar credenciales de cuentas o emails que no puede ver. La parte clave es: “estas cuentas de Google que no son de Gmail en realidad no son miembros de la organización de Google, por lo que no aparecen en la configuración del administrador ni en la lista de usuarios de Google”

• Si seguimos este flujo, se puede crear una cuenta de Google con la dirección de email de tickets de soporte, potencialmente revisar el contenido de los tickets para completar la creación de la cuenta y luego iniciar sesión con OAuth en varios servicios usando esa dirección de soporte. Esto puede afectar a muchas empresas pequeñas

• La mayor conclusión que saco de esto es que la autenticación web sigue siendo un desastre espantoso

  • Porque la gente no lee la documentación y simplemente asume que funciona como cree que funciona
  • Si preguntan por qué la gente cuerda y pragmática todavía usa y exige la autenticación simple con contraseña, es porque las contraseñas funcionan correctamente

• La especificación de OIDC dice que no se debe usar el email como identificador único. Como nombre de usuario de la aplicación se deben usar los campos iss y sub
  La razón es, en primer lugar, que es evidente que las direcciones de email de los usuarios pueden reutilizarse. Si un contratista trabaja tanto para Business A como para Business B, y ambas crean una cuenta de usuario para esa persona en el servicio de autenticación, desde el punto de vista de una plataforma SaaS no se puede mapear una sola dirección de email a un único cliente B2B. En segundo lugar, las direcciones de email cambian. Las empresas son adquiridas, cambian de nombre y se fusionan, y los nombres de las personas también cambian por matrimonio, divorcio o elección personal. Implementar SSO en una startup fue realmente difícil al principio. Es difícil hacerlo bien, y antes de usarlo hay que entender bien los conceptos generales, OIDC y OAuth2. Auth0 tiene un buen libro sobre esto. Si no entiendes esto, es muy probable que termines implementando autenticación con password grant por todas partes y vuelvas insegura la aplicación

  • A veces, al leer cosas así, se reduce un poco el síndrome del impostor acumulado. Uno termina pensando: “si te integras con un sistema de terceros para algo que representa a un actor abstracto, deberías tener un identificador confiable, estable y no tan dependiente de strings”. De hecho, la especificación es muy clara en este punto, y está por encima de las consideraciones básicas al crear cualquier sistema mínimamente robusto

• Parece una miniatura. Eso llamado OAuth2 en realidad no existe. OAuth2 no es más que una forma para que las grandes empresas implementen sus propios sistemas de autenticación arbitrarios y propietarios. No es un sistema de autenticación, sino una caja de herramientas para crear sistemas de autenticación. Por eso OAuth2 iba a ser un estándar, pero en la práctica terminamos en un mundo donde cada gran empresa tiene implementaciones incompatibles entre sí. Claro que la gente va a desarrollar adaptándose a los casos de uso de las grandes empresas, pero entonces el “estándar” termina siendo algo como la forma en que lo hace Google
  Y cada quien tiene estos pequeños bugs. Hay que volver a OAuth1. Ese sí era un estándar real, no una caja de herramientas para crear un estándar

  • Esto parece menos un bug y más un efecto secundario desafortunado de la combinación de ciertos componentes. Es el resultado de juntar nombres de dominio cuya propiedad puede cambiar, traer tu propio correo, correos de respaldo y el origen del correo, la aceptación permisiva de alias con signo más, e implementadores de servicios que no leen la documentación. Es probable que los implementadores hayan copiado la solución de un video o de un ejemplo omitido por brevedad
    Si diseñaras un circuito con algunos componentes de PCB y tuvieras que poner resistencias y transistores según los requisitos de voltaje y corriente, ¿no habría que esperar que leyeras las hojas de datos? Si avanzas a ojo a partir de un ejemplo simple, en muchos casos el circuito quizá funcione, y con algunas pruebas de banco y sondeos puede que termine andando. Pero podría ser ineficiente, o algún componente podría hacer corto, bajando el tiempo medio entre fallas y dejando clientes descontentos. En el peor caso, la batería podría incendiarse y causar daños reales. Entonces, ¿que el dispositivo falle prematuramente es culpa del fabricante de los módulos de PCB, o responsabilidad del fabricante del dispositivo que debió leer las hojas de datos? No aplicaría expectativas tan estrictas a todo el software, pero si se trata de autenticación y autorización, creo que el dueño del servicio debe ser minucioso. El texto original también dice que, si se sigue la documentación, el problema no existe. Alphabet pagó una recompensa por bug, así que reconoció la debilidad; podría ofrecer a los administradores de empresas controles para permitir o bloquear alias con signo más o roles inexistentes, o restringir que correos relacionados con Apps se transfieran a claims fuera de la organización. Probablemente estén midiendo el impacto o priorizando medirlo, pero como es un problema de clientes que asumen que un claim de correo es más autoritativo y permanente de lo que realmente es, sospecho que la prioridad será baja. La definición de “bug” depende mucho de cómo se defina el “comportamiento esperado” y quién lo espera, pero al menos no parece apartarse del comportamiento previsto, ni ser inesperado para quienes entendieron bien la documentación
  • Mmm... supongamos que sí. ¿La compatibilidad entre proveedores tiene algo que ver con este artículo sobre la seguridad de Google OAuth2?

• ¿Qué me estoy perdiendo? Aparte del sistema de soporte/Zendesk mencionado en el artículo y el método del dominio antiguo abandonado, cuando creas una cuenta nueva de Google como [e-mail] te piden verificación. Entonces, ¿qué tan explotable es esto en la práctica?

  • La clave es hacerlo por adelantado cuando tienes acceso legítimo, y luego perder ese acceso
    Por ejemplo, supongamos que existe legítimamente una cuenta de Google [e-mail]. Puedes crear una nueva cuenta de Google con una dirección de correo verificada como [e-mail], y entonces al usar “Iniciar sesión con Google”, Google enviará el claim de correo [e-mail]. Después, si te despiden de mydomain.com, ya no podrás iniciar sesión en la cuenta vinculada al [e-mail] real porque el administrador la desactivó. Pero la nueva cuenta de Google [e-mail] no está vinculada a la organización, así que puedes seguir iniciando sesión. Aun así, a mi parecer esto solo se vuelve un problema cuando el proveedor hace autorización únicamente con el claim de correo. Usé OIDC hace tiempo, y no se debe parsear el texto del claim de dirección de correo para conceder acceso a recursos. Entiendo por qué al autor le pareció contraintuitivo, pero el artículo también dice que la documentación advierte no hacer eso. En el original dice: “la mayoría de los proveedores de servicios que probé no usaban HD y usaban el claim de correo”; bien, ¿pero para qué “lo usan”? ¿Este truco funciona en servicios reales en producción? Si es así, deberían nombrarlos para que reciban críticas. Incluso si asumes erróneamente que este valor es único e inmutable, eso por sí solo no necesariamente otorga ningún acceso