Millones de cuentas vulnerables por fallo en OAuth de Google

Una debilidad en la funcionalidad de «Iniciar sesión con Google» en el sistema OAuth podría permitir a atacantes explotar dominios abandonados por startups extintas para acceder a datos confidenciales. Esta falla afecta a cuentas de antiguos empleados vinculadas a diversas plataformas de software como servicio (SaaS).

 

 

¿Qué es OAuth? 

OAuth (Open Authorization) es un protocolo que permite a un usuario conceder a una aplicación externa acceso a sus datos sin compartir la contraseña de su cuenta. Permite a los usuarios autenticarse y autorizar a aplicaciones externas a acceder a sus datos y recursos almacenados en un servidor determinado, como la información de su cuenta, fotos y documentos, sin revelar sus credenciales de acceso. OAuth también se utiliza para los inicios de sesión con un solo clic, lo que permite a los usuarios identificarse ante un servicio web sin tener que introducir cada vez su nombre de usuario y contraseña.

 

¿Por qué se utiliza OAuth?

Antes de OAuth, cada servicio basado en la web tenía credenciales independientes para una cuenta de usuario. Los servicios no podían compartir datos a menos que ofrecieran una API en la que se pudieran transferir datos entre ambos. Incluso con una API, la transferencia de contraseñas entre servicios es una vulnerabilidad de seguridad, ya que expone los datos privados de varios servicios si se vulnera uno solo.

OAuth permite a los usuarios dar acceso a sus cuentas a aplicaciones externas para una amplia gama de funciones. Algunos ejemplos son el uso de los datos del calendario para facilitar la programación, el almacenamiento de los ajustes de la aplicación en la nube o incluso el análisis de sus listas de reproducción de música para obtener nuevas recomendaciones. Las contraseñas ya no son necesarias para la autorización, y los usuarios pueden revocar el acceso en cualquier momento. Los desarrolladores externos de aplicaciones almacenan un token de acceso para recuperar los datos autorizados, que debe almacenarse de forma segura, pero no expone las credenciales del usuario.

 

¿Cómo funciona OAuth?

En una transacción OAuth satisfactoria intervienen tres entidades:

• El usuario (la persona u organización que autoriza el acceso a sus datos)
• El proveedor de servicios de OAuth (es la aplicación o servicio que almacena los datos y credenciales del usuario)
• El consumidor (la aplicación que solicita el acceso a los datos del usuario)

OAuth utiliza un flujo de trabajo definido para garantizar la seguridad de los datos del usuario y simplificar las solicitudes para el consumidor. En primer lugar, la aplicación que solicita el acceso (consumidor) pide un token de acceso OAuth al proveedor del servicio. Si aún no ha iniciado sesión en el proveedor de servicios, se pide a los usuarios que lo hagan. A continuación, el proveedor de servicios enumera los tipos de datos a los que la aplicación del consumidor pretende acceder y pide al usuario que apruebe o deniegue el acceso. Si el usuario está de acuerdo, el proveedor de servicios envía entonces un token de acceso al consumidor, que lo almacena para futuras solicitudes de acceso. Una vez validado, el token de acceso se utiliza en todas las solicitudes de acceso a los datos del usuario (dentro del ámbito de los permisos concedidos por el usuario).

Los OAuth tokens de acceso caducan, por lo que los proveedores de servicios ofrecen a los desarrolladores una forma de actualizar los tokens de acceso para futuras solicitudes. El plazo de caducidad de un token de acceso lo establece el proveedor de servicios, por lo que su duración depende de los protocolos de seguridad del proveedor de servicios. El OAuth token de acceso debe almacenarse de forma segura porque puede ser utilizado por cualquiera para obtener datos del usuario y realizar funciones en su nombre.

Si el usuario decide revocar el acceso, puede hacerlo a través del proveedor de servicios. Una vez revocado el acceso, el consumidor deberá pedir al usuario que vuelva a autenticarse para obtener cualquier dato almacenado en la aplicación del proveedor de servicios. Si el consumidor sufre una vulneración de datos en la que se revelan los tokens de acceso, el proveedor de servicios podría invalidar proactivamente todos los tokens de acceso para proteger los datos del usuario.

 

OAuth vs. OpenID

Cuando los consumidores utilizan OAuth, el proveedor de servicios proporciona acceso autorizado a los datos de un usuario solamente después de que dé su consentimiento. OAuth es una forma de compartir datos utilizando un token de autorización proporcionado por el consumidor después de que el usuario verifique sus credenciales. OpenID es distinto de OAuth, pero ambos se utilizan juntos.

El inicio de sesión único (SSO) es una estrategia de seguridad común que utiliza un proveedor para autenticar a los usuarios en varios servicios. OpenID es uno de los protocolos SSO más antiguos, introducido en 2005 para autenticar en LiveJournal. Ha pasado por algunas actualizaciones, pero se consideró demasiado difícil de implementar en comparación con otros métodos de la época, principalmente Facebook Connect. Como Facebook era una marca muy conocida, la mayoría de los desarrolladores se pasaron a Facebook Connect para que los usuarios se sintieran más cómodos autenticándose en sus aplicaciones.

En 2014, OpenID rediseñó su código y posteriormente se incorporó a OAuth. Ahora, OAuth utiliza OpenID como capa de autenticación y OAuth se ocupa de la capa de autorización. El proceso es fluido para el usuario, pero los consumidores pueden integrar más fácilmente OAuth tanto para autenticar a los usuarios como para obtener acceso a los datos de sus cuentas.

 

OAuth vs. SAML

Un producto anterior similar a OAuth es el Lenguaje de Marcado para Confirmaciones de Seguridad (o SAML, del inglés “Security Assertion Markup Language”), que está basado en XML. La principal diferencia entre SAML y OAuth es que SAML realiza tanto la autenticación como la autorización. OAuth utiliza OpenID como capa de autenticación, pero no gestiona la autenticación por sí mismo. Las aplicaciones que utilizan SAML no necesitan ningún otro servicio para proporcionar autenticación.

Otra diferencia entre los dos protocolos es el lenguaje utilizado para trasladar datos entre servicios. SAML utiliza XML; OAuth utiliza JSON, el formato preferido para las transferencias de datos. La mayoría de los servicios de datos trabajan principalmente con JSON, lo que hace que OAuth sea más fácil de integrar para la mayoría de las empresas.

Descubrimiento e informe inicial

Investigadores de Trufflesecurity identificaron esta brecha de seguridad y la reportaron a Google el 30 de septiembre del año pasado. Inicialmente, Google clasificó el hallazgo como un problema de «fraude y abuso» en lugar de una falla en OAuth o en la función de inicio de sesión. Sin embargo, tras una presentación de Dylan Ayrey, CEO y cofundador de Trufflesecurity, en la conferencia Shmoocon en diciembre, Google reconsideró la situación. Aunque otorgó una recompensa de $1,337 a los investigadores y reabrió el caso, el problema sigue sin resolverse.

Un portavoz de Google recomendó a los usuarios cerrar adecuadamente los dominios obsoletos para evitar riesgos. También instó a las aplicaciones de terceros a implementar identificadores únicos de cuenta (“sub”) para mitigar este tipo de vulnerabilidades.

Naturaleza del problema

Según Ayrey, la vulnerabilidad radica en que el sistema OAuth de Google no protege contra la compra de dominios abandonados por startups. Los nuevos propietarios pueden recrear cuentas de correo electrónico de antiguos empleados y utilizarlas para acceder a servicios como Slack, Notion, Zoom y ChatGPT. Aunque estos correos clonados no permiten acceder a comunicaciones previas, sí posibilitan iniciar sesión en plataformas que dependan del correo electrónico y el dominio alojado para la autenticación.

En una prueba, Ayrey demostró que es factible extraer información sensible de sistemas de recursos humanos, como documentos fiscales, datos de seguros y números de seguridad social. Al analizar la base de datos de Crunchbase, encontró 116,481 dominios disponibles de startups desaparecidas, lo que muestra la magnitud del problema.

Problemas técnicos en el sistema OAuth

El sistema OAuth utiliza una “subafirmación” para identificar de manera única e inmutable a los usuarios. Sin embargo, según Ayrey, existe una tasa de inconsistencia del 0.04%, lo que lleva a servicios como Slack y Notion a ignorarla y depender exclusivamente de las afirmaciones de correo electrónico y dominio. Esto permite que nuevos propietarios de dominios se hagan pasar por antiguos empleados en plataformas SaaS.

Propuestas de solución

Los investigadores sugieren que Google implemente identificadores inmutables, como un ID de usuario permanente y un ID de espacio de trabajo vinculado a la organización original. Además, los proveedores de SaaS podrían aplicar medidas como:

• Verificar fechas de registro de dominios.
• Requerir aprobaciones de nivel administrador para el acceso a cuentas.
• Implementar factores secundarios de autenticación.

Sin embargo, estas soluciones conllevan costos adicionales y mayor complejidad técnica, lo que puede desincentivar su adopción.

Impacto creciente

Esta vulnerabilidad afecta potencialmente a millones de usuarios y miles de empresas, y su alcance crece con el tiempo. Según el informe de Trufflesecurity, existen millones de cuentas de empleados vinculadas a startups desaparecidas cuyos dominios están disponibles para compra.

En Estados Unidos, alrededor de seis millones de personas trabajan para startups tecnológicas, de las cuales el 90% podría cerrar en los próximos años. Aproximadamente el 50% de estas empresas utiliza Google Workspaces, lo que incrementa el riesgo de exposición de datos confidenciales.

Recomendaciones finales

Si trabajas para una startup, asegúrate de eliminar datos confidenciales al dejar la organización y evita usar cuentas laborales para registros personales. Estas prácticas simples pueden reducir significativamente el riesgo de exposición futura.

Fuente: Bleepingcomputer

Vía:

https://blog.underc0de.org/vulnerabilidad-en-el-sistema-oauth-de-google-expone-datos-confidenciales/

https://trufflesecurity.com/blog/millions-at-risk-due-to-google-s-oauth-flaw

https://www.proofpoint.com/es/threat-reference/oauth