Análisis del flujo OAuth2
Examinamos cómo Chrome solicitaba, almacenaba y renovaba tokens OAuth2 durante la sincronización y el auto-inicio de sesión.
Compromiso de Token OAuth2 en Google Chrome
Descubriendo cómo los tokens OAuth2 almacenados podían eludir el MFA y otorgar acceso a servicios centrales de Google.
Resumen
Cuando las organizaciones adoptan proveedores de identidad de terceros como Google, a menudo asumen que el flujo de autenticación es seguro por defecto. Sin embargo, como demostró este trabajo de investigación, los límites de autenticación pueden ser frágiles — especialmente cuando los navegadores almacenan credenciales poderosas de forma inesperada.
Los investigadores de Cyber Defence identificaron que Google Chrome almacenaba tokens de actualización (refresh tokens) OAuth2 en texto plano. Combinado con el flujo de auto-inicio de sesión de Chrome y el mecanismo MergeSession de Google, este refresh token permitía acceso completo a servicios críticos de Google, incluido Gmail, incluso cuando la autenticación multifactor (MFA) estaba habilitada. :contentReference[oaicite:1]{index=1}
Contexto
Qué nos propusimos investigar
Expectativas de seguridad
Los usuarios suelen creer que las credenciales almacenadas por Chrome solo permiten operaciones de sincronización inofensivas como marcadores o pestañas — una suposición que nos propusimos comprobar. :contentReference[oaicite:2]{index=2}
Panorama de amenazas
El compromiso de cuentas de correo sigue siendo uno de los puntos de apoyo más dañinos para los atacantes, permitiendo restablecimientos de contraseña, suplantación e intrusiones posteriores.
Descubrimiento: el potente refresh token de Chrome
Durante la evaluación, Cyber Defence observó que Chrome podía iniciar sesión automáticamente en servicios de Google si alguna vez había sido vinculado a una cuenta de Google para sincronización. No se requería nueva autenticación.
Este comportamiento implicaba que Chrome almacenaba una credencial poderosa localmente — mucho más potente que un simple token de sincronización.
Al interceptar tráfico del navegador, confirmamos esta intuición: Chrome almacenaba un token de actualización OAuth2 completo con amplios permisos. :contentReference[oaicite:3]{index=3}
Este token podía intercambiarse directamente por nuevos tokens de acceso mediante la llamada:
POST /o/oauth2/token
Método
Cómo explotamos el token
1. Obtención del refresh token
Chrome almacenaba el token de actualización OAuth2 en texto plano en el archivo de preferencias del perfil del usuario bajo <code>oauth2LoginRefreshToken</code>. :contentReference[oaicite:4]{index=4}
2. Intercambio del refresh token
Lo intercambiamos por un token de acceso temporal utilizando el client_id y client_secret codificados en Chrome.
3. Obtención del token UberAuth
Solicitamos un token ‘uberauth’ mediante: <code>GET /OAuthLogin?issueuberauth=1</code>, usando el token de acceso para la autorización.
4. Uso de MergeSession
Creamos una URL MergeSession para iniciar sesión en servicios potentes de Google, incluido Gmail:<br><code>https://accounts.google.com/MergeSession?...&continue=https://mail.google.com/</code> :contentReference[oaicite:5]{index=5}
Eludiendo el MFA
Incluso cuando la cuenta de Google estaba protegida por autenticación multifactor, el flujo del refresh token eludía el MFA por completo. El token OAuth2 se encontraba por debajo de la capa de MFA y permitía que Chrome autenticara al usuario sin validación adicional.
Esto hacía que el refresh token fuese tan poderoso como una Contraseña Específica de Aplicación (ASP) — y en algunos sentidos más poderoso, porque interactuaba sin fricción con el stack OAuth moderno.
En resumen: poseer el refresh token significaba poseer la cuenta de Google.
Impacto
Implicaciones de seguridad
Acceso total a Gmail
El compromiso del correo permite restablecimientos de contraseña, ataques de suplantación, fraude financiero y exfiltración de datos.
Compromiso multi-servicio
Muchos servicios de Google aceptaban el flujo MergeSession, otorgando acceso amplio al ecosistema. :contentReference[oaicite:6]{index=6}
Robo de token = toma de cuenta
Cualquier atacante con acceso local, malware, o una copia del perfil de Chrome podía secuestrar la cuenta silenciosamente.
Erosión del MFA
Aunque la verificación en dos pasos bloqueaba ataques mediante ASP, la vía del refresh token eludía completamente los controles MFA.
Recomendaciones
Cyber Defence emitió la siguiente guía de remediación:
• aplicar almacenamiento cifrado de credenciales y uso del almacén de credenciales del SO
• monitorizar solicitudes MergeSession e intercambios anómalos de tokens OAuth
• restringir o deshabilitar la sincronización de cuentas de Chrome en sistemas sensibles
• implementar políticas de acceso basadas en dispositivos para reducir la portabilidad de tokens
• revisar los scopes OAuth2 usados por aplicaciones empresariales
• educar a los usuarios sobre los riesgos de las funciones de auto-inicio de sesión del navegador
Resultado
Resultados
Interacción con el proveedor
Los hallazgos se remitieron adecuadamente a los equipos de seguridad de Google para su revisión y mitigación.
Aumento de la concienciación
Las organizaciones comprendieron cómo el almacenamiento de tokens en navegadores puede socavar la protección MFA.
Mejora en las políticas
Los clientes reforzaron las políticas de uso de Chrome en sistemas administrativos, financieros y de ingeniería.
¿Necesita probar sus flujos de identidad y autenticación?
Cyber Defence se especializa en descubrir debilidades en flujos OAuth, OIDC, SAML y federación — a menudo donde las organizaciones menos lo esperan.
Asegúrese de que las fronteras de confianza estén validadas, no asumidas.