OAuth a la toma de control de cuentas

Reading time: 18 minutes

Información Básica

OAuth ofrece varias versiones, con información fundamental accesible en OAuth 2.0 documentation. Esta discusión se centra principalmente en el ampliamente utilizado OAuth 2.0 authorization code grant type, proporcionando un marco de autorización que permite a una aplicación acceder o realizar acciones en la cuenta de un usuario en otra aplicación (el servidor de autorización).

Considera un sitio web hipotético https://example.com, diseñado para mostrar todas tus publicaciones en redes sociales, incluidas las privadas. Para lograr esto, se emplea OAuth 2.0. https://example.com solicitará tu permiso para acceder a tus publicaciones en redes sociales. En consecuencia, aparecerá una pantalla de consentimiento en https://socialmedia.com, describiendo los permisos solicitados y el desarrollador que realiza la solicitud. Tras tu autorización, https://example.com obtiene la capacidad de acceder a tus publicaciones en tu nombre.

Es esencial comprender los siguientes componentes dentro del marco de OAuth 2.0:

• resource owner: Tú, como el usuario/entidad, autorizas el acceso a tu recurso, como las publicaciones de tu cuenta de redes sociales.
• resource server: El servidor que gestiona las solicitudes autenticadas después de que la aplicación ha asegurado un access token en nombre del resource owner, por ejemplo, https://socialmedia.com.
• client application: La aplicación que busca autorización del resource owner, como https://example.com.
• authorization server: El servidor que emite access tokens a la client application tras la autenticación exitosa del resource owner y la obtención de autorización, por ejemplo, https://socialmedia.com.
• client_id: Un identificador público y único para la aplicación.
• client_secret: Una clave confidencial, conocida únicamente por la aplicación y el servidor de autorización, utilizada para generar access_tokens.
• response_type: Un valor que especifica el tipo de token solicitado, como code.
• scope: El nivel de acceso que la client application está solicitando del resource owner.
• redirect_uri: La URL a la que el usuario es redirigido después de la autorización. Esto generalmente debe alinearse con la URL de redirección pre-registrada.
• state: Un parámetro para mantener datos a través de la redirección del usuario hacia y desde el servidor de autorización. Su singularidad es crítica para servir como un mecanismo de protección CSRF.
• grant_type: Un parámetro que indica el tipo de concesión y el tipo de token que se devolverá.
• code: El código de autorización del authorization server, utilizado junto con client_id y client_secret por la client application para adquirir un access_token.
• access_token: El token que la client application utiliza para solicitudes API en nombre del resource owner.
• refresh_token: Permite a la aplicación obtener un nuevo access_token sin volver a solicitar al usuario.

Flujo

El flujo real de OAuth procede de la siguiente manera:

1. Navegas a https://example.com y seleccionas el botón “Integrar con Redes Sociales”.
2. El sitio luego envía una solicitud a https://socialmedia.com pidiendo tu autorización para permitir que la aplicación de https://example.com acceda a tus publicaciones. La solicitud está estructurada como:

https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123

3. Luego se te presenta una página de consentimiento.
4. Tras tu aprobación, Social Media envía una respuesta a la redirect_uri con los parámetros code y state:

https://example.com?code=uniqueCode123&state=randomString123

5. https://example.com utiliza este code, junto con su client_id y client_secret, para hacer una solicitud del lado del servidor para obtener un access_token en su nombre, lo que permite el acceso a los permisos a los que usted consintió:

POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}

6. Finalmente, el proceso concluye cuando https://example.com emplea tu access_token para hacer una llamada a la API de Social Media para acceder

Vulnerabilidades

Open redirect_uri

El redirect_uri es crucial para la seguridad en las implementaciones de OAuth y OpenID, ya que dirige a dónde se envían los datos sensibles, como los códigos de autorización, después de la autorización. Si está mal configurado, podría permitir a los atacantes redirigir estas solicitudes a servidores maliciosos, habilitando la toma de control de cuentas.

Las técnicas de explotación varían según la lógica de validación del servidor de autorización. Pueden ir desde una coincidencia estricta de rutas hasta aceptar cualquier URL dentro del dominio o subdirectorio especificado. Los métodos de explotación comunes incluyen redirecciones abiertas, recorrido de rutas, explotación de expresiones regulares débiles e inyección de HTML para el robo de tokens.

Además de redirect_uri, otros parámetros de OAuth y OpenID como client_uri, policy_uri, tos_uri e initiate_login_uri también son susceptibles a ataques de redirección. Estos parámetros son opcionales y su soporte varía entre servidores.

Para aquellos que apuntan a un servidor OpenID, el punto final de descubrimiento (**.well-known/openid-configuration**) a menudo lista detalles de configuración valiosos como registration_endpoint, request_uri_parameter_supported y "require_request_uri_registration. Estos detalles pueden ayudar a identificar el punto final de registro y otros aspectos específicos de configuración del servidor.

XSS en la implementación de redirección

Como se menciona en este informe de recompensas por errores https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html, podría ser posible que la URL de redirección se esté reflejando en la respuesta del servidor después de que el usuario se autentica, siendo vulnerable a XSS. Carga útil posible para probar:

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

CSRF - Manejo inadecuado del parámetro de estado

En las implementaciones de OAuth, el uso indebido u omisión del state parameter puede aumentar significativamente el riesgo de ataques de Cross-Site Request Forgery (CSRF). Esta vulnerabilidad surge cuando el parámetro state es no utilizado, utilizado como un valor estático, o no validado o asociado correctamente con la sesión del usuario durante el inicio de sesión, permitiendo a los atacantes eludir las protecciones CSRF.

Los atacantes pueden explotar esto interceptando el proceso de autorización para vincular su cuenta con la cuenta de una víctima, lo que lleva a posibles tomas de control de cuentas al hacer que un usuario inicie sesión con un flujo oauth casi finalizado que pertenece al atacante. Esto es especialmente crítico en aplicaciones donde se utiliza OAuth para fines de autenticación.

Se han documentado ejemplos del mundo real de esta vulnerabilidad en varios CTF challenges y plataformas de hacking, destacando sus implicaciones prácticas. El problema también se extiende a integraciones con servicios de terceros como Slack, Stripe y PayPal, donde los atacantes pueden redirigir notificaciones o pagos a sus cuentas.

El manejo y validación adecuados del state parameter son cruciales para protegerse contra CSRF y asegurar el flujo de OAuth.

Pre Toma de Control de Cuenta

1. Sin Verificación de Correo Electrónico en la Creación de Cuenta: Los atacantes pueden crear preventivamente una cuenta utilizando el correo electrónico de la víctima. Si la víctima más tarde utiliza un servicio de terceros para iniciar sesión, la aplicación podría vincular inadvertidamente esta cuenta de terceros a la cuenta pre-creada del atacante, lo que lleva a un acceso no autorizado.
2. Explotando la Verificación de Correo Electrónico Laxa de OAuth: Los atacantes pueden explotar servicios de OAuth que no verifican correos electrónicos registrándose con su servicio y luego cambiando el correo electrónico de la cuenta al de la víctima. Este método también arriesga el acceso no autorizado a la cuenta, similar al primer escenario pero a través de un vector de ataque diferente.

Divulgación de Secretos

Identificar y proteger los parámetros secretos de OAuth es crucial. Mientras que el client_id puede ser divulgado de manera segura, revelar el client_secret presenta riesgos significativos. Si el client_secret se ve comprometido, los atacantes pueden explotar la identidad y confianza de la aplicación para robar access_tokens de usuarios e información privada.

Una vulnerabilidad común surge cuando las aplicaciones manejan erróneamente el intercambio del code de autorización por un access_token del lado del cliente en lugar del lado del servidor. Este error lleva a la exposición del client_secret, permitiendo a los atacantes generar access_tokens bajo la apariencia de la aplicación. Además, a través de ingeniería social, los atacantes podrían escalar privilegios al agregar ámbitos adicionales a la autorización de OAuth, explotando aún más el estatus de confianza de la aplicación.

Fuerza Bruta del Secreto del Cliente

Puedes intentar fuerza bruta del client_secret de un proveedor de servicios con el proveedor de identidad para intentar robar cuentas.
La solicitud para BF puede parecer similar a:

POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
Connection: close

code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]

Referer Header leaking Code + State

Una vez que el cliente tiene el código y el estado, si está reflejado dentro del encabezado Referer cuando navega a una página diferente, entonces es vulnerable.

Access Token Stored in Browser History

Ve al historial del navegador y verifica si el access token está guardado allí.

Everlasting Authorization Code

El código de autorización debería vivir solo por un tiempo para limitar la ventana de tiempo en la que un atacante puede robarlo y usarlo.

Authorization/Refresh Token not bound to client

Si puedes obtener el código de autorización y usarlo con un cliente diferente, entonces puedes tomar el control de otras cuentas.

Happy Paths, XSS, Iframes & Post Messages to leak code & state values

Check this post

AWS Cognito

En este informe de bug bounty: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ puedes ver que el token que AWS Cognito devuelve al usuario podría tener suficientes permisos para sobrescribir los datos del usuario. Por lo tanto, si puedes cambiar el correo electrónico del usuario por un correo electrónico de otro usuario, podrías ser capaz de tomar el control de otras cuentas.

# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]

# Change email address
aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com
{
"CodeDeliveryDetailsList": [
{
"Destination": "i***@f***.com",
"DeliveryMedium": "EMAIL",
"AttributeName": "email"
}
]
}

Para obtener información más detallada sobre cómo abusar de AWS Cognito, consulta:

AWS - Cognito Unauthenticated Enum - HackTricks Cloud

Abusando de otros tokens de Apps

Como se menciona en este informe, los flujos de OAuth que esperan recibir el token (y no un código) podrían ser vulnerables si no verifican que el token pertenece a la aplicación.

Esto se debe a que un atacante podría crear una aplicación que soporte OAuth y login con Facebook (por ejemplo) en su propia aplicación. Luego, una vez que una víctima inicia sesión con Facebook en la aplicación del atacante, el atacante podría obtener el token OAuth del usuario otorgado a su aplicación y usarlo para iniciar sesión en la aplicación OAuth de la víctima usando el token de usuario de la víctima.

Dos enlaces y cookie

Según este informe, era posible hacer que una víctima abriera una página con un returnUrl apuntando al host del atacante. Esta información se almacenaría en una cookie (RU) y en un paso posterior el prompt preguntará al usuario si desea dar acceso a ese host del atacante.

Para eludir este prompt, era posible abrir una pestaña para iniciar el flujo de Oauth que establecería esta cookie RU usando el returnUrl, cerrar la pestaña antes de que se muestre el prompt y abrir una nueva pestaña sin ese valor. Entonces, el prompt no informará sobre el host del atacante, pero la cookie se establecería en él, por lo que el token se enviará al host del atacante en la redirección.

Bypass de Interacción del Prompt

Como se explica en este video, algunas implementaciones de OAuth permiten indicar el parámetro prompt GET como None (&prompt=none) para evitar que se pida a los usuarios que confirmen el acceso otorgado en un prompt en la web si ya están conectados a la plataforma.

response_mode

Como se explica en este video, podría ser posible indicar el parámetro response_mode para indicar dónde deseas que se proporcione el código en la URL final:

• response_mode=query -> El código se proporciona dentro de un parámetro GET: ?code=2397rf3gu93f
• response_mode=fragment -> El código se proporciona dentro del parámetro de fragmento de la URL #code=2397rf3gu93f
• response_mode=form_post -> El código se proporciona dentro de un formulario POST con un input llamado code y el valor
• response_mode=web_message -> El código se envía en un mensaje post: window.opener.postMessage({"code": "asdasdasd...

Flujo OAuth ROPC - bypass de 2 FA

Según esta publicación de blog, este es un flujo de OAuth que permite iniciar sesión en OAuth a través de nombre de usuario y contraseña. Si durante este flujo simple se devuelve un token con acceso a todas las acciones que el usuario puede realizar, entonces es posible eludir 2FA usando ese token.

ATO en página web redirigiendo basado en redirección abierta al referente

Esta publicación de blog comenta cómo fue posible abusar de un redireccionamiento abierto al valor del referente para abusar de OAuth para ATO. El ataque fue:

1. La víctima accede a la página web del atacante
2. La víctima abre el enlace malicioso y un opener inicia el flujo de Google OAuth con response_type=id_token,code&prompt=none como parámetros adicionales usando como referente el sitio web del atacante.
3. En el opener, después de que el proveedor autoriza a la víctima, los envía de vuelta al valor del parámetro redirect_uri (web de la víctima) con un código 30X que aún mantiene el sitio web del atacante en el referente.
4. El sitio web de la víctima activa el redireccionamiento abierto basado en el referente redirigiendo al usuario víctima al sitio web del atacante, ya que el respose_type era id_token,code, el código se enviará de vuelta al atacante en el fragmento de la URL permitiéndole tomar el control de la cuenta del usuario a través de Google en el sitio de la víctima.

Parámetros SSRFs

Consulta esta investigación Para más detalles sobre esta técnica.

El Registro Dinámico de Clientes en OAuth sirve como un vector menos obvio pero crítico para vulnerabilidades de seguridad, específicamente para ataques de Server-Side Request Forgery (SSRF). Este endpoint permite a los servidores OAuth recibir detalles sobre aplicaciones cliente, incluyendo URLs sensibles que podrían ser explotadas.

Puntos Clave:

• El Registro Dinámico de Clientes a menudo se mapea a /register y acepta detalles como client_name, client_secret, redirect_uris, y URLs para logotipos o Conjuntos de Claves Web JSON (JWKs) a través de solicitudes POST.
• Esta característica se adhiere a las especificaciones establecidas en RFC7591 y OpenID Connect Registration 1.0, que incluyen parámetros potencialmente vulnerables a SSRF.
• El proceso de registro puede exponer inadvertidamente a los servidores a SSRF de varias maneras:
• logo_uri: Una URL para el logotipo de la aplicación cliente que podría ser recuperada por el servidor, activando SSRF o llevando a XSS si la URL se maneja incorrectamente.
• jwks_uri: Una URL al documento JWK del cliente, que si se elabora maliciosamente, puede causar que el servidor realice solicitudes salientes a un servidor controlado por un atacante.
• sector_identifier_uri: Hace referencia a un array JSON de redirect_uris, que el servidor podría recuperar, creando una oportunidad de SSRF.
• request_uris: Enumera las URIs de solicitud permitidas para el cliente, que pueden ser explotadas si el servidor recupera estas URIs al inicio del proceso de autorización.

Estrategia de Explotación:

• SSRF puede ser activado registrando un nuevo cliente con URLs maliciosas en parámetros como logo_uri, jwks_uri, o sector_identifier_uri.
• Si bien la explotación directa a través de request_uris puede ser mitigada por controles de lista blanca, proporcionar un request_uri pre-registrado y controlado por el atacante puede facilitar SSRF durante la fase de autorización.

Condiciones de Carrera de Proveedores OAuth

Si la plataforma que estás probando es un proveedor de OAuth lee esto para probar posibles Condiciones de Carrera.

Ataque de Reclamaciones Mutables

En OAuth, el campo sub identifica de manera única a un usuario, pero su formato varía según el Servidor de Autorización. Para estandarizar la identificación del usuario, algunos clientes utilizan correos electrónicos o identificadores de usuario. Sin embargo, esto es arriesgado porque:

• Algunos Servidores de Autorización no garantizan que estas propiedades (como el correo electrónico) permanezcan inmutables.
• En ciertas implementaciones—como "Iniciar sesión con Microsoft"—el cliente depende del campo de correo electrónico, que es controlado por el usuario en Entra ID y no verificado.
• Un atacante puede explotar esto creando su propia organización de Azure AD (por ejemplo, doyensectestorg) y usándola para realizar un inicio de sesión en Microsoft.
• Aunque el Object ID (almacenado en sub) es inmutable y seguro, la dependencia de un campo de correo electrónico mutable puede permitir un takeover de cuenta (por ejemplo, secuestrando una cuenta como victim@gmail.com).

Ataque de Confusión de Cliente

En un Ataque de Confusión de Cliente, una aplicación que utiliza el Flujo Implícito de OAuth no verifica que el token de acceso final sea específicamente generado para su propio ID de Cliente. Un atacante configura un sitio web público que utiliza el Flujo Implícito de OAuth de Google, engañando a miles de usuarios para que inicien sesión y así recolectar tokens de acceso destinados al sitio del atacante. Si estos usuarios también tienen cuentas en otro sitio web vulnerable que no valida el ID de Cliente del token, el atacante puede reutilizar los tokens recolectados para hacerse pasar por las víctimas y tomar el control de sus cuentas.

Ataque de Actualización de Alcance

El tipo de Concesión de Código de Autorización implica comunicación segura de servidor a servidor para transmitir datos de usuario. Sin embargo, si el Servidor de Autorización confía implícitamente en un parámetro de alcance en la Solicitud de Token de Acceso (un parámetro no definido en el RFC), una aplicación maliciosa podría actualizar los privilegios de un código de autorización solicitando un alcance más alto. Después de que se genera el Token de Acceso, el Servidor de Recursos debe verificarlo: para tokens JWT, esto implica verificar la firma JWT y extraer datos como client_id y scope, mientras que para tokens de cadena aleatoria, el servidor debe consultar al Servidor de Autorización para recuperar los detalles del token.

Secuestro de Esquema de Redirección

En implementaciones móviles de OAuth, las aplicaciones utilizan esquemas URI personalizados para recibir redirecciones con Códigos de Autorización. Sin embargo, dado que múltiples aplicaciones pueden registrar el mismo esquema en un dispositivo, se viola la suposición de que solo el cliente legítimo controla la URI de redirección. En Android, por ejemplo, un URI de Intent como com.example.app:// oauth se captura según el esquema y los filtros opcionales definidos en el intent-filter de una aplicación. Dado que la resolución de intent de Android puede ser amplia—especialmente si solo se especifica el esquema—un atacante puede registrar una aplicación maliciosa con un intent filter cuidadosamente elaborado para secuestrar el código de autorización. Esto puede habilitar un takeover de cuenta ya sea a través de la interacción del usuario (cuando múltiples aplicaciones son elegibles para manejar el intent) o mediante técnicas de bypass que explotan filtros excesivamente específicos, como se detalla en el diagrama de flujo de evaluación de Ostorlab.

Referencias

• https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1
• https://portswigger.net/research/hidden-oauth-attack-vectors
• https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html