Learn & practice AWS Hacking:<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
OAuth ofrece varias versiones, con información fundamental accesible en [OAuth 2.0 documentation](https://oauth.net/2/). Esta discusión se centra principalmente en el ampliamente utilizado [OAuth 2.0 authorization code grant type](https://oauth.net/2/grant-types/authorization-code/), 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**.
* **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\_secret:** Una clave confidencial, conocida únicamente por la aplicación y el servidor de autorización, utilizada para generar `access_tokens`.
* **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**.
* **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`.
1. Navegas a [https://example.com](https://example.com) y seleccionas el botón “Integrar con Redes Sociales”.
2. El sitio envía una solicitud a [https://socialmedia.com](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:
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ó:
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 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](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.
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.
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.
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.
[**Revisa esta publicación**](https://labs.detectify.com/writeups/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url)
En este informe de bug bounty: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](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.
Como [**se menciona en este informe**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), 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 inicie 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**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), era posible hacer que una víctima abriera una página con un **returnUrl** apuntando al host del atacante. Esta información sería **almacenada 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**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), algunas implementaciones de OAuth permiten indicar el parámetro **`prompt`** GET como None (**`&prompt=none`**) para **evitar que se le pida a los usuarios confirmar** el acceso otorgado en un prompt en la web si ya están conectados a la plataforma.
Como [**se explica en este video**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), 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:
### Flujo OAuth ROPC - bypass de 2 FA <a href="#b440" id="b440"></a>
Según [**esta publicación de blog**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96), 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.
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.
* **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, desencadenando 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.
* **`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.
* 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 un atacante puede facilitar SSRF durante la fase de autorización.
Aprende y practica Hacking en AWS:<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">\
Aprende y practica Hacking en GCP: <imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Consulta los [**planes de suscripción**](https://github.com/sponsors/carlospolop)!
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Comparte trucos de hacking enviando PRs a los** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositorios de github.
