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

# OAuth para Assumir o Controle da Conta

<details>

<summary><strong>Aprenda hacking AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Outras maneiras de apoiar o HackTricks:

* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.

</details>

## Informações Básicas <a href="#d4a8" id="d4a8"></a>

O OAuth oferece várias versões, com informações fundamentais acessíveis na [documentação do OAuth 2.0](https://oauth.net/2/). Esta discussão se concentra principalmente no amplamente utilizado [tipo de concessão de código de autorização OAuth 2.0](https://oauth.net/2/grant-types/authorization-code/), fornecendo um **framework de autorização que permite que um aplicativo acesse ou execute ações na conta de um usuário em outro aplicativo** (o servidor de autorização).

Considere um site hipotético _**https://exemplo.com**_, projetado para **mostrar todas as suas postagens em redes sociais**, incluindo as privadas. Para alcançar isso, o OAuth 2.0 é empregado. _https://exemplo.com_ solicitará sua permissão para **acessar suas postagens em redes sociais**. Consequentemente, uma tela de consentimento aparecerá em _https://redesocial.com_, detalhando as **permissões solicitadas e o desenvolvedor fazendo a solicitação**. Após sua autorização, _https://exemplo.com_ ganha a capacidade de **acessar suas postagens em seu nome**.

É essencial compreender os seguintes componentes dentro do framework OAuth 2.0:

- **dono do recurso**: Você, como **usuário/entidade**, autoriza o acesso ao seu recurso, como suas postagens em redes sociais.
- **servidor de recursos**: O **servidor que gerencia solicitações autenticadas** após o aplicativo ter obtido um `token de acesso` em nome do `dono do recurso`, por exemplo, **https://redesocial.com**.
- **aplicativo cliente**: O **aplicativo que busca autorização** do `dono do recurso`, como **https://exemplo.com**.
- **servidor de autorização**: O **servidor que emite `tokens de acesso`** para o `aplicativo cliente` após a autenticação bem-sucedida do `dono do recurso` e a obtenção de autorização, por exemplo, **https://redesocial.com**.
- **client\_id**: Um identificador público e único para o aplicativo.
- **client\_secret:** Uma chave confidencial, conhecida apenas pelo aplicativo e pelo servidor de autorização, usada para gerar `tokens de acesso`.
- **response\_type**: Um valor especificando **o tipo de token solicitado**, como `código`.
- **escopo**: O **nível de acesso** que o `aplicativo cliente` está solicitando do `dono do recurso`.
- **redirect\_uri**: A **URL para a qual o usuário é redirecionado após a autorização**. Isso geralmente deve estar alinhado com a URL de redirecionamento pré-registrada.
- **state**: Um parâmetro para **manter dados durante o redirecionamento do usuário para e do servidor de autorização**. Sua singularidade é crítica para servir como um **mecanismo de proteção CSRF**.
- **grant\_type**: Um parâmetro que indica **o tipo de concessão e o tipo de token a ser retornado**.
- **código**: O código de autorização do `servidor de autorização`, usado em conjunto com `client_id` e `client_secret` pelo aplicativo cliente para adquirir um `token de acesso`.
- **token de acesso**: O **token que o aplicativo cliente usa para solicitações de API** em nome do `dono do recurso`.
- **refresh\_token**: Permite que o aplicativo **obtenha um novo `token de acesso` sem solicitar novamente a permissão do usuário**.

### Fluxo

O **fluxo real do OAuth** procede da seguinte forma:

1. Você navega até [https://exemplo.com](https://exemplo.com) e seleciona o botão "Integrar com Redes Sociais".
2. O site então envia uma solicitação para [https://redesocial.com](https://redesocial.com) pedindo sua autorização para permitir que o aplicativo de https://exemplo.com acesse suas postagens. A solicitação é estruturada da seguinte forma:
```
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123
```
3. Em seguida, você é apresentado com uma página de consentimento.

4. Após a sua aprovação, a Rede Social envia uma resposta para o `redirect_uri` com os parâmetros `code` e `state`:
```
https://example.com?code=uniqueCode123&state=randomString123
```
5. https://example.com utiliza este `código`, juntamente com seu `client_id` e `client_secret`, para fazer uma solicitação do lado do servidor para obter um `access_token` em seu nome, permitindo o acesso às permissões às quais você consentiu:
```
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
```
6. Finalmente, o processo é concluído quando https://example.com utiliza seu `access_token` para fazer uma chamada de API para as Redes Sociais para acessar

## Vulnerabilidades <a href="#323a" id="323a"></a>

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

O `redirect_uri` é crucial para a segurança nas implementações de OAuth e OpenID, pois direciona para onde os dados sensíveis, como códigos de autorização, são enviados pós-autorização. Se mal configurado, poderia permitir que atacantes redirecionassem essas solicitações para servidores maliciosos, possibilitando a tomada de controle da conta.

As técnicas de exploração variam com base na lógica de validação do servidor de autorização. Podem variar desde a correspondência estrita de caminhos até a aceitação de qualquer URL dentro do domínio ou subdiretório especificado. Métodos comuns de exploração incluem redirecionamentos abertos, travessia de caminho, exploração de regex fracos e injeção de HTML para roubo de token.

Além do `redirect_uri`, outros parâmetros do OAuth e OpenID como `client_uri`, `policy_uri`, `tos_uri` e `initiate_login_uri` também são suscetíveis a ataques de redirecionamento. Esses parâmetros são opcionais e seu suporte varia entre os servidores.

Para aqueles visando um servidor OpenID, o ponto de descoberta (`**.well-known/openid-configuration**`) frequentemente lista detalhes valiosos de configuração como `registration_endpoint`, `request_uri_parameter_supported` e "`require_request_uri_registration`. Esses detalhes podem auxiliar na identificação do ponto de registro e outras especificidades de configuração do servidor.

### XSS na implementação de redirecionamento <a href="#bda5" id="bda5"></a>

Conforme mencionado neste relatório de recompensa por bugs [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html), pode ser possível que a **URL de redirecionamento esteja sendo refletida na resposta** do servidor após o usuário se autenticar, sendo **vulnerável a XSS**. Payload possível para teste:
```
https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>
```
### CSRF - Manipulação inadequada do parâmetro de estado <a href="#bda5" id="bda5"></a>

Nas implementações do OAuth, o uso indevido ou omissão do **parâmetro `state`** pode aumentar significativamente o risco de ataques de **Cross-Site Request Forgery (CSRF)**. Essa vulnerabilidade surge quando o parâmetro `state` não é usado, é usado como um valor estático ou não é validado corretamente, permitindo que os atacantes ignorem as proteções contra CSRF.

Os atacantes podem explorar isso interceptando o processo de autorização para vincular sua conta à conta de uma vítima, levando a possíveis **tomadas de controle de conta**. Isso é especialmente crítico em aplicações onde o OAuth é usado para **fins de autenticação**.

Exemplos do mundo real dessa vulnerabilidade foram documentados em vários desafios de **CTF** e **plataformas de hacking**, destacando suas implicações práticas. O problema também se estende a integrações com serviços de terceiros como **Slack**, **Stripe** e **PayPal**, onde os atacantes podem redirecionar notificações ou pagamentos para suas contas.

O tratamento adequado e a validação do **parâmetro `state`** são cruciais para proteger contra CSRF e garantir a segurança do fluxo do OAuth.

### Pré Tomada de Conta <a href="#ebe4" id="ebe4"></a>

1. **Sem Verificação de Email na Criação de Conta**: Os atacantes podem criar antecipadamente uma conta usando o email da vítima. Se a vítima posteriormente usar um serviço de terceiros para fazer login, a aplicação pode inadvertidamente vincular essa conta de terceiros à conta pré-criada do atacante, resultando em acesso não autorizado.

2. **Explorando a Verificação de Email Laxa do OAuth**: Os atacantes podem explorar serviços OAuth que não verificam emails ao se registrar no serviço e, em seguida, alterar o email da conta para o da vítima. Esse método também apresenta riscos de acesso não autorizado à conta, semelhante ao primeiro cenário, mas por meio de um vetor de ataque diferente.

### Divulgação de Segredos <a href="#e177" id="e177"></a>

Identificar e proteger os parâmetros secretos do OAuth é crucial. Enquanto o **`client_id`** pode ser divulgado com segurança, revelar o **`client_secret`** apresenta riscos significativos. Se o `client_secret` for comprometido, os atacantes podem explorar a identidade e a confiança da aplicação para **roubar `access_tokens`** e informações privadas.

Uma vulnerabilidade comum surge quando as aplicações lidam erroneamente com a troca do `code` de autorização por um `access_token` no lado do cliente em vez do lado do servidor. Esse erro leva à exposição do `client_secret`, permitindo que os atacantes gerem `access_tokens` sob a aparência da aplicação. Além disso, por meio de engenharia social, os atacantes podem escalar privilégios adicionando escopos adicionais à autorização do OAuth, explorando ainda mais o status confiável da aplicação.

### Bruteforce do Client Secret

Você pode tentar **fazer bruteforce no client\_secret** de um provedor de serviços com o provedor de identidade para tentar roubar contas.\
A solicitação para o BF pode se parecer com:
```
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]
```
### Cabeçalho Referer vazando Código + Estado

Uma vez que o cliente tenha o **código e estado**, se ele estiver **refletido dentro do cabeçalho Referer** ao navegar para uma página diferente, então está vulnerável.

### Token de Acesso Armazenado no Histórico do Navegador

Vá para o **histórico do navegador e verifique se o token de acesso está salvo lá**.

### Código de Autorização Eterno

O **código de autorização deve existir apenas por algum tempo para limitar a janela de tempo em que um atacante pode roubá-lo e usá-lo**.

### Token de Autorização/Atualização não vinculado ao cliente

Se você conseguir obter o **código de autorização e usá-lo com um cliente diferente, então você pode assumir o controle de outras contas**.

### Caminhos Felizes, XSS, Iframes e Mensagens Post para vazar códigos e valores de estado

**[Verifique este 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>

Neste relatório de recompensa por bugs: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) você pode ver que o **token** que o **AWS Cognito** devolve ao usuário pode ter **permissões suficientes para sobrescrever os dados do usuário**. Portanto, se você puder **alterar o e-mail do usuário por um e-mail de usuário diferente**, você pode **assumir** outras contas.
```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"
}
]
}
```
### Abusando de tokens de outros aplicativos <a href="#bda5" id="bda5"></a>

Como [**mencionado neste artigo**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), os fluxos do OAuth que esperam receber o **token** (e não um código) podem ser vulneráveis se não verificarem se o token pertence ao aplicativo.

Isso ocorre porque um **atacante** poderia criar um **aplicativo que suporta OAuth e fazer login com o Facebook** (por exemplo) em seu próprio aplicativo. Então, uma vez que uma vítima faz login com o Facebook no **aplicativo do atacante**, o atacante poderia obter o **token OAuth do usuário fornecido ao seu aplicativo e usá-lo para fazer login no aplicativo OAuth da vítima usando o token de usuário da vítima**.

{% hint style="danger" %}
Portanto, se o atacante conseguir fazer com que o usuário acesse seu próprio aplicativo OAuth, ele poderá assumir o controle da conta da vítima em aplicativos que esperam um token e não verificam se o token foi concedido ao ID de seu aplicativo.
{% endhint %}

### Dois links e cookie <a href="#bda5" id="bda5"></a>

De acordo com [**este artigo**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), era possível fazer com que uma vítima abrisse uma página com um **returnUrl** apontando para o host do atacante. Essas informações seriam **armazenadas em um cookie (RU)** e em uma **etapa posterior**, o **prompt** perguntaria ao **usuário** se ele deseja conceder acesso a esse host do atacante.

Para contornar esse prompt, era possível abrir uma guia para iniciar o **fluxo OAuth** que definiria esse cookie RU usando o **returnUrl**, fechar a guia antes que o prompt fosse exibido e abrir uma nova guia sem esse valor. Assim, o **prompt não informará sobre o host do atacante**, mas o cookie será definido para ele, então o **token será enviado para o host do atacante** na redireção.

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

**[Confira esta pesquisa](https://portswigger.net/research/hidden-oauth-attack-vectors) para mais detalhes sobre essa técnica.**

O Registro Dinâmico de Clientes no OAuth serve como um vetor menos óbvio, mas crítico para vulnerabilidades de segurança, especificamente para ataques de **Server-Side Request Forgery (SSRF)**. Este endpoint permite que servidores OAuth recebam detalhes sobre aplicativos clientes, incluindo URLs sensíveis que podem ser explorados.

**Pontos-chave:**

- O **Registro Dinâmico de Clientes** geralmente é mapeado para `/register` e aceita detalhes como `client_name`, `client_secret`, `redirect_uris` e URLs para logotipos ou Conjuntos de Chaves Web JSON (JWKs) via solicitações POST.
- Este recurso segue as especificações estabelecidas em **RFC7591** e **OpenID Connect Registration 1.0**, que incluem parâmetros potencialmente vulneráveis ao SSRF.
- O processo de registro pode inadvertidamente expor servidores ao SSRF de várias maneiras:
- **`logo_uri`**: Um URL para o logotipo do aplicativo cliente que pode ser buscado pelo servidor, desencadeando SSRF ou levando a XSS se o URL for manipulado incorretamente.
- **`jwks_uri`**: Um URL para o documento JWK do cliente, que se for maliciosamente elaborado, pode fazer com que o servidor faça solicitações de saída para um servidor controlado pelo atacante.
- **`sector_identifier_uri`**: Faz referência a um array JSON de `redirect_uris`, que o servidor pode buscar, criando uma oportunidade de SSRF.
- **`request_uris`**: Lista URIs de solicitação permitidos para o cliente, que podem ser explorados se o servidor buscar esses URIs no início do processo de autorização.

**Estratégia de Exploração:**

- SSRF pode ser acionado registrando um novo cliente com URLs maliciosos em parâmetros como `logo_uri`, `jwks_uri` ou `sector_identifier_uri`.
- Embora a exploração direta via `request_uris` possa ser mitigada por controles de lista branca, fornecer um `request_uri` pré-registrado controlado pelo atacante pode facilitar o SSRF durante a fase de autorização.