OAuth to Account takeover
Last updated
Last updated
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
OAuth ofrece varias versiones, con información fundamental accesible en documentación de OAuth 2.0. Esta discusión se centra principalmente en el tipo de concesión de código de autorización de OAuth 2.0, 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:
propietario del recurso: Tú, como el usuario/entidad, autorizas el acceso a tu recurso, como las publicaciones de tu cuenta de redes sociales.
servidor de recursos: El servidor que gestiona las solicitudes autenticadas después de que la aplicación ha asegurado un access token en nombre del propietario del recurso, por ejemplo, https://socialmedia.com.
aplicación cliente: La aplicación que busca autorización del propietario del recurso, como https://example.com.
servidor de autorización: El servidor que emite access tokens a la aplicación cliente tras la autenticación exitosa del propietario del recurso 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 aplicación cliente está solicitando del propietario del recurso.
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 unicidad 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 servidor de autorización, utilizado junto con client_id y client_secret por la aplicación cliente para adquirir un access_token.
access_token: El token que la aplicación cliente utiliza para solicitudes API en nombre del propietario del recurso.
refresh_token: Permite a la aplicación obtener un nuevo access_token sin volver a solicitar al usuario.
El flujo real de OAuth procede de la siguiente manera:
Navegas a https://example.com y seleccionas el botón “Integrar con Redes Sociales”.
El sitio 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:
A continuación, se le presenta una página de consentimiento.
Tras su aprobación, Social Media envía una respuesta a la redirect_uri con los parámetros code y state:
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 tu nombre, lo que permite el acceso a los permisos a los que diste tu consentimiento:
Finalmente, el proceso concluye cuando https://example.com emplea tu access_token para hacer una llamada a la API de Social Media para acceder
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 enumera 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 otras especificaciones de configuración del servidor.
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 autentique, siendo vulnerable a XSS. Carga útil posible para probar:
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 adecuadamente, 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. 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 hacking platforms, 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 la validación adecuados del state parameter son cruciales para protegerse contra CSRF y asegurar el flujo de OAuth.
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.
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.
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 usuario 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.
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:
Una vez que el cliente tiene el code y state, si está reflejado dentro del Referer header cuando navega a una página diferente, entonces es vulnerable.
Ve al historial del navegador y verifica si el access token está guardado allí.
El authorization code debería vivir solo por un tiempo para limitar la ventana de tiempo en la que un atacante puede robarlo y usarlo.
Si puedes obtener el authorization code y usarlo con un cliente diferente, entonces puedes tomar el control de otras cuentas.
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 diferente, podrías ser capaz de tomar el control de otras cuentas.
Para obtener información más detallada sobre cómo abusar de AWS Cognito, consulta:
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.
Por lo tanto, si el atacante logra que el usuario acceda a su propia aplicación OAuth, podrá tomar el control de la cuenta de la víctima en aplicaciones que esperan un token y no verifican si el token fue otorgado a su ID de aplicación.
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.
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.
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...
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.
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:
La víctima accede a la página web del atacante
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.
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.
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.
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 hacer 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 controlado por un atacante previamente registrado puede facilitar SSRF durante la fase de autorización.
Si la plataforma que estás probando es un proveedor OAuth lee esto para probar posibles Condiciones de Carrera.
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
