# OAuth para Assumir o Controle da Conta
Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)! 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.
## Informações Básicas 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 ### Open redirect\_uri 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 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

test

``` ### CSRF - Manipulação inadequada do parâmetro de estado 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 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 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 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 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 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 **[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.