hacktricks/pentesting-web/oauth-to-account-takeover.md

# OAuth a Toma de Control de Cuenta

{% hint style="success" %}
Aprende y practica Hacking en AWS:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Aprende y practica Hacking en GCP: <img src="/.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)

<details>

<summary>Apoya a HackTricks</summary>

* Revisa 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) repos de github.

</details>
{% endhint %}

<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>

{% embed url="https://websec.nl/" %}

## Información Básica <a href="#d4a8" id="d4a8"></a>

OAuth ofrece varias versiones, con información fundamental accesible en [documentación de OAuth 2.0](https://oauth.net/2/). Esta discusión se centra principalmente en el ampliamente utilizado [tipo de concesión de código de autorización de OAuth 2.0](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**.

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 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 `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**.

### Flujo

El **flujo real de OAuth** procede de la siguiente manera:

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:
```
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123
```
3. A continuación, se le presenta una página de consentimiento.  
4. Tras su 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 tu nombre, lo que permite el acceso a los permisos a los que diste tu consentimiento:
```
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 <a href="#id-323a" id="id-323a"></a>

### Open redirect\_uri <a href="#cc36" id="cc36"></a>

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` y `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 <a href="#bda5" id="bda5"></a>

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:
```
https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>
```
### CSRF - Manejo inadecuado del parámetro de estado <a href="#bda5" id="bda5"></a>

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 **desafíos CTF** 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 <a href="#ebe4" id="ebe4"></a>

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 <a href="#e177" id="e177"></a>

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 alcances 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 **code y state**, si está **reflejado dentro del Referer header** 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 **authorization code 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 **authorization code 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**](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)

### AWS Cognito <a href="#bda5" id="bda5"></a>

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.
```bash
# 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:

{% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}

### Abusando de otros tokens de Apps <a href="#bda5" id="bda5"></a>

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**.

{% hint style="danger" %}
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 están verificando si el token fue otorgado a su ID de aplicación.
{% endhint %}

### Dos enlaces y cookie <a href="#bda5" id="bda5"></a>

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.

### Bypass de Interacción del Prompt <a href="#bda5" id="bda5"></a>

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 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**](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:

* `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...`

### Parámetros SSRFs <a href="#bda5" id="bda5"></a>

[**Consulta esta investigación**](https://portswigger.net/research/hidden-oauth-attack-vectors) **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, 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.
* **`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 desencadenado 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**](race-condition.md).

## Referencias

* [**https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1**](https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1)
* [**https://portswigger.net/research/hidden-oauth-attack-vectors**](https://portswigger.net/research/hidden-oauth-attack-vectors)

<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>

{% embed url="https://websec.nl/" %}

{% hint style="success" %}
Aprende y practica Hacking en AWS:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Aprende y practica Hacking en GCP: <img src="/.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)

<details>

<summary>Apoya a HackTricks</summary>

* 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.

</details>
{% endhint %}