El inicio de sesión con Google OAuth no puede protegerse si alguien compra el dominio de una startup que fracasó

• Una falla de seguridad en Google OAuth expone una vulnerabilidad grave en el proceso de autenticación de "Sign in with Google"
  • Tras comprar el dominio de una startup que fracasó, es posible reconstruir cuentas de correo de ese dominio e iniciar sesión en servicios SaaS
  • Se puede acceder a servicios con datos sensibles:
    • Slack, ChatGPT, Notion, Zoom, sistemas de RR. HH. (incluyendo números de seguro social)
  • Google rechazó corregirlo en el informe inicial, afirmando que era un "comportamiento esperado"
• La causa de fondo del problema: Google OAuth no detecta cambios en la propiedad del dominio
  • Cuando cambia el dominio, el nuevo propietario puede iniciar sesión en cuentas de ex empleados con los mismos claims
• Información de claims usada por defecto:
  • hd (dominio alojado): incluye la información del dominio (ej.: example.com)
  • email: incluye la dirección de correo del usuario (ej.: [e-mail])
• Si el proveedor del servicio depende de estos dos datos, permite acceso a la misma cuenta cuando cambia la propiedad del dominio
• Alcance del problema
  • 6 millones de personas en EE. UU. trabajan en startups
  • El 90% de las startups fracasa
  • El 50% de las startups que fracasan usa Google Workspaces
• Hay cerca de 100,000 dominios de startups fallidas disponibles para comprar
• En promedio, cada dominio tiene 10 empleados y uso de 10 servicios SaaS → más de 10 millones de cuentas podrían contener datos sensibles

Propuesta de solución y respuesta de Google

• Soluciones propuestas a Google:
  1. ID único de usuario: agregar un identificador único de usuario que no cambie con el tiempo
  2. ID único de Workspace: agregar un identificador único de Workspace vinculado al dominio
• Respuesta inicial de Google:
  • Reportado en septiembre de 2024 → cerrado como "no se puede corregir"
  • Después de una presentación en la conferencia Shmoocon en diciembre de 2024, Google volvió a revisar el problema
  • Pagó una recompensa por bugs de $1,337 e inició el trabajo de corrección
• Por ahora, sin una corrección de Google, no es posible resolver el problema de raíz
• Algunos servicios devuelven la lista completa de usuarios cuando el dominio coincide, lo que agrava aún más la vulnerabilidad
• Incluso si se usara contraseña en lugar de inicio de sesión con Google, también podría restablecerse
  • Las startups aplican SSO y 2FA obligatorios en vez de autenticación por contraseña
  • Los proveedores de servicios deben exigir verificación adicional al restablecer contraseñas (código SMS, verificación de tarjeta de crédito)

Conclusión: un problema fundamental de seguridad en Google OAuth

• Una falla en la implementación de OAuth de Google permite la toma de cuentas cuando cambia la propiedad del dominio
• Google ya inició el trabajo de corrección, pero aún no hay una solución fundamental completada
• Por ahora, los datos y las cuentas de millones de estadounidenses siguen en riesgo

[sixmen]

Me da la impresión de que esto es más bien un error del lado del usuario: usó un correo con un dominio como método de autenticación, luego abandonó ese dominio y no dio de baja correctamente los SaaS relacionados. ¿Aun así habría que considerarlo una vulnerabilidad de seguridad?

[kargnas]

En el servicio que estoy creando ya habíamos bloqueado este problema de antemano, pero aun así coincido con esta opinión.
Si esto es un problema, entonces habría que considerar problemáticos también el inicio de sesión y el registro normales mediante correo electrónico. Todos usan el correo como identificador único y la verificación para recuperar la contraseña también confirma la propiedad por correo.

Llevándolo al extremo, si asumimos que un dominio conocido como gmail.com o hotmail.com es hackeado y el control de la configuración DNS del dominio pasa a manos de un atacante, entonces es totalmente natural que las cuentas de todos los SaaS del mundo queden en riesgo.

[GN⁺]

Comentarios en Hacker News

• Parece ser un tema de responsabilidad de DankStartup, Microsoft y OpenAI si DankStartup cerró, otra persona compró el dominio y pudo acceder a cuentas existentes

  • No es apropiado describirlo como una vulnerabilidad de OAuth

• En la implementación de OpenID de Google, la forma correcta es autenticar usando el claim sub

  • Se necesita un flujo para el caso en que el claim sub cambie
  • El "ID de usuario único e inmutable" propuesto no es distinto del claim sub

• Es un problema fundamental de los enfoques que dependen de DNS: después de que expire un dominio, el nuevo propietario puede heredar los permisos del anterior

  • Es un problema que puede ocurrir en sistemas de autenticación que dependen de direcciones de correo o de DNS

• No hay una vulnerabilidad en Google OAuth; si compras un dominio, pasas a ser dueño de todas las direcciones de correo de ese dominio

  • El mismo resultado podría ocurrir incluso sin usar Google OAuth

• Comparten una experiencia pasada con thehunt.com, donde tras adquirir el dominio pudieron acceder a todos los servicios

  • Proponen una idea de startup para monitorear el estado de los dominios y prevenir amenazas de seguridad

• Es un problema de los servicios que no usan el campo sub; para identificar usuarios se debe usar el campo sub

  • Se podría ganar dinero enviando reportes de vulnerabilidad a servicios que no usan el campo sub

• Proponen que el OpenID Connect de Google implemente dos identificadores inmutables

  • El claim sub y un ID único de Workspace vinculado al dominio

• En Google OAuth es raro que el claim sub cambie, así que probablemente sea un problema de la implementación del servicio

• Comparten un caso de acceso a correo electrónico tras adquirir un dominio

  • El problema se resolvió mediante una conexión interna con Google

• La afirmación de "millones de cuentas" se basa en asumir que las startups fallidas no desactivan sus cuentas SaaS