Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-28 07:31:10 +00:00
Code Issues Projects Releases Packages Wiki Activity

Translated ['pentesting-web/oauth-to-account-takeover.md'] to pt

Browse source
This commit is contained in:
Translator 2024-07-18 11:47:45 +00:00
parent abba30be01
commit 223d1de330
1 changed files with 100 additions and 91 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

191
pentesting-web/oauth-to-account-takeover.md
View file

@ -1,16 +1,16 @@
# OAuth para Assumir o Controle da Conta # OAuth to Account takeover
<details> <details>
<summary><strong>Aprenda hacking na 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> <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: 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)! * Se você quer 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 do PEASS & HackTricks**](https://peass.creator-spring.com) * Obtenha o [**swag oficial do 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) * 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 do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.** * **Junte-se ao** 💬 [**grupo no Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo no 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. * **Compartilhe seus truques de hacking enviando PRs para os repositórios do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details> </details>
@ -18,36 +18,35 @@ Outras maneiras de apoiar o HackTricks:
{% embed url="https://websec.nl/" %} {% embed url="https://websec.nl/" %}
## Informações Básicas <a href="#d4a8" id="d4a8"></a> ## Informações Básicas <a href="#d4a8" id="d4a8"></a>
OAuth oferece várias versões, com insights fundamentais acessíveis em [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). OAuth oferece várias versões, com insights fundamentais acessíveis em [OAuth 2.0 documentation](https://oauth.net/2/). Esta discussão centra-se principalmente no amplamente utilizado [OAuth 2.0 authorization code grant type](https://oauth.net/2/grant-types/authorization-code/), fornecendo uma **estrutura de autorização que permite a um aplicativo acessar ou realizar 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, é utilizado o OAuth 2.0. _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**. Considere um site hipotético _**https://example.com**_, projetado para **exibir todas as suas postagens nas redes sociais**, incluindo as privadas. Para conseguir isso, é empregado o OAuth 2.0. _https://example.com_ solicitará sua permissão para **acessar suas postagens nas redes sociais**. Consequentemente, uma tela de consentimento aparecerá em _https://socialmedia.com_, detalhando as **permissões solicitadas e o desenvolvedor que está fazendo a solicitação**. Após sua autorização, _https://example.com_ ganha a capacidade de **acessar suas postagens em seu nome**.
É essencial compreender os seguintes componentes dentro do framework do OAuth 2.0: É essencial compreender os seguintes componentes dentro da estrutura do OAuth 2.0:
- **dono do recurso**: Você, como **usuário/entidade**, autoriza o acesso ao seu recurso, como suas postagens em redes sociais. * **resource owner**: Você, como **usuário/entidade**, autoriza o acesso ao seu recurso, como as postagens da sua conta de rede social.
- **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**. * **resource server**: O **servidor que gerencia as solicitações autenticadas** após o aplicativo ter garantido um `access token` em nome do `resource owner`, por exemplo, **https://socialmedia.com**.
- **aplicativo cliente**: O **aplicativo que busca autorização** do `dono do recurso`, como **https://exemplo.com**. * **client application**: O **aplicativo que busca autorização** do `resource owner`, como **https://example.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**. * **authorization server**: O **servidor que emite `access tokens`** para o `client application` após a autenticação bem-sucedida do `resource owner` e a obtenção da autorização, por exemplo, **https://socialmedia.com**.
- **client\_id**: Um identificador público e único para o aplicativo. * **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`. * **client\_secret:** Uma chave confidencial, conhecida apenas pelo aplicativo e pelo servidor de autorização, usada para gerar `access_tokens`.
- **response\_type**: Um valor que especifica **o tipo de token solicitado**, como `código`. * **response\_type**: Um valor especificando **o tipo de token solicitado**, como `code`.
- **escopo**: O **nível de acesso** que o `aplicativo cliente` está solicitando do `dono do recurso`. * **scope**: O **nível de acesso** que o `client application` está solicitando do `resource owner`.
- **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. * **redirect\_uri**: A **URL para a qual o usuário é redirecionado após a autorização**. Esta geralmente deve alinhar-se 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 é fundamental para servir como um **mecanismo de proteção CSRF**. * **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 contra CSRF**.
- **grant\_type**: Um parâmetro que indica **o tipo de concessão e o tipo de token a ser retornado**. * **grant\_type**: Um parâmetro indicando **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`. * **code**: O código de autorização do `authorization server`, usado em conjunto com `client_id` e `client_secret` pelo client application para adquirir um `access_token`.
- **token de acesso**: O **token que o aplicativo cliente usa para solicitações de API** em nome do `dono do recurso`. * **access\_token**: O **token que o client application usa para solicitações de API** em nome do `resource owner`.
- **refresh\_token**: Permite que o aplicativo **obtenha um novo `token de acesso` sem solicitar novamente a permissão do usuário**. * **refresh\_token**: Permite que o aplicativo **obtenha um novo `access_token` sem solicitar novamente ao usuário**.
### Fluxo ### Fluxo
O **fluxo real do OAuth** procede da seguinte forma: 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". 1. Você navega para [https://example.com](https://example.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: 2. O site então envia uma solicitação para [https://socialmedia.com](https://socialmedia.com) pedindo sua autorização para permitir que o aplicativo de https://example.com acesse suas postagens. A solicitação é estruturada como:
``` ```
https://socialmedia.com/auth https://socialmedia.com/auth
?response_type=code ?response_type=code
@ -56,64 +55,62 @@ https://socialmedia.com/auth
&scope=readPosts &scope=readPosts
&state=randomString123 &state=randomString123
``` ```
3. Em seguida, você é apresentado com uma página de consentimento. 3. Você é então apresentado a uma página de consentimento.
4. Após sua aprovação, a Social Media envia uma resposta para o `redirect_uri` com os parâmetros `code` e `state`:
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 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: 5. https://example.com utiliza este `code`, junto 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 acesso às permissões às quais você consentiu:
``` ```
POST /oauth/access_token POST /oauth/access_token
Host: socialmedia.com Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"} ...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
``` ```
6. Por fim, o processo conclui conforme https://example.com utiliza seu `access_token` para fazer uma chamada de API para as Redes Sociais para acessar 6. Finalmente, o processo conclui quando https://example.com emprega seu `access_token` para fazer uma chamada de API para Social Media para acessar
## Vulnerabilidades <a href="#323a" id="323a"></a> ## Vulnerabilidades <a href="#id-323a" id="id-323a"></a>
### Open redirect\_uri <a href="#cc36" id="cc36"></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. O `redirect_uri` é crucial para a segurança em implementações OAuth e OpenID, pois direciona onde dados sensíveis, como códigos de autorização, são enviados após a autorização. Se mal configurado, pode permitir que atacantes redirecionem essas solicitações para servidores maliciosos, possibilitando a tomada de 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. As técnicas de exploração variam com base na lógica de validação do servidor de autorização. Elas podem variar desde a correspondência estrita de caminho até aceitar 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 fracas 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. Além de `redirect_uri`, outros parâmetros 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 servidores.
Para aqueles visando um servidor OpenID, o endpoint 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 endpoint de registro e outras especificidades de configuração do servidor. Para aqueles que visam um servidor OpenID, o endpoint 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 ajudar a identificar o endpoint de registro e outras especificidades de configuração do servidor.
### XSS in redirect implementation <a href="#bda5" id="bda5"></a> ### 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: Como mencionado neste relatório de bug bounty [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 o **URL de redirecionamento esteja sendo refletido na resposta** do servidor após a autenticação do usuário, sendo **vulnerável a XSS**. Possível payload para testar:
``` ```
https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1> 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> ### CSRF - Improper handling of state parameter <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 utilizado, usado como um valor estático ou não validado corretamente**, permitindo que os atacantes ignorem as proteções contra CSRF. Em implementações OAuth, o uso indevido ou a 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 utilizado, usado como um valor estático ou não validado corretamente**, permitindo que atacantes contornem as proteções 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**. Os atacantes podem explorar isso interceptando o processo de autorização para vincular sua conta à conta da vítima, levando a potenciais **sequestros 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. Exemplos reais dessa vulnerabilidade foram documentados em vários **desafios 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. O manuseio e a validação adequados do **parâmetro `state`** são cruciais para proteger contra CSRF e garantir a segurança do fluxo OAuth.
### Pré Tomada de Conta <a href="#ebe4" id="ebe4"></a> ### Pre Account Takeover <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. 1. **Sem Verificação de Email na Criação de Conta**: Atacantes podem criar uma conta antecipadamente usando o email da vítima. Se a vítima posteriormente usar um serviço de terceiros para login, a aplicação pode inadvertidamente vincular essa conta de terceiros à conta pré-criada pelo atacante, levando a acesso não autorizado.
2. **Explorando Verificação de Email Laxa do OAuth**: Atacantes podem explorar serviços OAuth que não verificam emails registrando-se com seu serviço e, em seguida, alterando o email da conta para o da vítima. Esse método apresenta riscos semelhantes de acesso não autorizado, semelhante ao primeiro cenário, mas através de um vetor de ataque diferente.
2. **Explorando a Verificação de Email Laxa do OAuth**: Os atacantes podem explorar serviços OAuth que não verificam emails se registrando com seu serviço e depois alterando 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. ### Disclosure of Secrets <a href="#e177" id="e177"></a>
### Divulgação de Segredos <a href="#e177" id="e177"></a> Identificar e proteger 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`** de usuários e informações privadas.
Identificar e proteger os parâmetros secretos do OAuth é crucial. Enquanto o **`client_id`** pode ser divulgado com segurança, revelar o **`client_secret`** representa 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 atacantes gerem `access_tokens` sob a aparência da aplicação. Além disso, através de engenharia social, os atacantes poderiam escalar privilégios adicionando escopos adicionais à autorização OAuth, explorando ainda mais o status confiável da aplicação.
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 poderiam aumentar os privilégios adicionando escopos adicionais à autorização do OAuth, explorando ainda mais o status confiável da aplicação. ### Client Secret Bruteforce
### Bruteforce do Cliente Secreto Você pode tentar **bruteforce do client\_secret** de um provedor de serviços com o provedor de identidade para tentar roubar contas.\
A solicitação para BF pode ser semelhante a:
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 POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded content-type: application/x-www-form-urlencoded
@ -123,29 +120,29 @@ 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] 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 ### Referer Header vazando Code + State
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. Uma vez que o cliente tenha o **code e state**, se eles forem **refletidos dentro do cabeçalho Referer** quando ele navega para uma página diferente, então está vulnerável.
### Token de Acesso Armazenado no Histórico do Navegador ### Access Token Armazenado no Histórico do Navegador
Vá para o **histórico do navegador e verifique se o token de acesso está salvo lá**. Vá para o **histórico do navegador e verifique se o access token está salvo lá**.
### Código de Autorização Eterno ### Everlasting Authorization Code
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**. O **authorization code deve viver apenas por algum tempo para limitar a janela de tempo onde um atacante pode roubá-lo e usá-lo**.
### Token de Autorização/Atualização não vinculado ao cliente ### Authorization/Refresh Token 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**. Se você conseguir o **authorization code e usá-lo com um cliente diferente, então você pode tomar conta de outras contas**.
### Caminhos Felizes, XSS, Iframes e Mensagens Post para vazar códigos e valores de estado ### Happy Paths, XSS, Iframes & Post Messages para vazar valores de code & state
**[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)** [**Confira 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> ### 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 ser capaz de **assumir** outras contas. Neste relatório de bug bounty: [**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** retorna para o usuário pode ter **permissões suficientes para sobrescrever os dados do usuário**. Portanto, se você puder **alterar o email do usuário para um email de outro usuário**, você pode ser capaz de **tomar conta** de outras contas.
```bash ```bash
# Read info of the user # Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...] aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]
@ -162,57 +159,69 @@ aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ
] ]
} }
``` ```
Para obter informações mais detalhadas sobre como abusar do AWS Cognito, verifique: Para mais informações detalhadas sobre como abusar do AWS cognito, confira:
{% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %} {% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}
### Abusando de tokens de outros aplicativos <a href="#bda5" id="bda5"></a> ### Abusando de tokens de outros Apps <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. Como [**mencionado neste artigo**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), fluxos OAuth que esperam receber o **token** (e não um código) podem ser vulneráveis se não verificarem que 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. Em seguida, 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**. Isso ocorre porque um **atacante** poderia criar uma **aplicação suportando OAuth e fazer login com Facebook** (por exemplo) em sua própria aplicação. Então, uma vez que uma vítima faça login com Facebook na **aplicação do atacante**, o atacante poderia obter o **token OAuth do usuário dado à sua aplicação e usá-lo para fazer login na aplicação OAuth da vítima usando o token do usuário da vítima**.
{% hint style="danger" %} {% 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 do seu aplicativo. Portanto, se o atacante conseguir que o usuário acesse sua própria aplicação OAuth, ele será capaz de tomar conta da conta da vítima em aplicações que esperam um token e não verificam se o token foi concedido ao ID do aplicativo deles.
{% endhint %} {% endhint %}
### Dois links e cookie <a href="#bda5" id="bda5"></a> ### Dois links & 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. De acordo com [**este artigo**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), era possível fazer uma vítima abrir uma página com um **returnUrl** apontando para o host do atacante. Esta informação seria **armazenada em um cookie (RU)** e em um **passo posterior** o **prompt** **perguntaria** ao **usuário** se ele deseja dar 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. Em seguida, 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. Para contornar este prompt, era possível abrir uma aba para iniciar o **fluxo OAuth** que definiria este cookie RU usando o **returnUrl**, fechar a aba antes que o prompt fosse mostrado, e abrir uma nova aba sem esse valor. Então, o **prompt não informaria sobre o host do atacante**, mas o cookie estaria definido para ele, então o **token seria enviado para o host do atacante** na redireção.
### Bypass de Interação de Prompt <a href="#bda5" id="bda5"></a>
Como explicado neste [**vídeo**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), algumas implementações OAuth permitem indicar o parâmetro GET **`prompt`** como None (**`&prompt=none`**) para **evitar que os usuários sejam solicitados a confirmar** o acesso dado em um prompt na web se já estiverem logados na plataforma.
### response\_mode
Como [**explicado neste vídeo**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), pode ser possível indicar o parâmetro **`response_mode`** para indicar onde você deseja que o código seja fornecido na URL final:
* `response_mode=query` -> O código é fornecido dentro de um parâmetro GET: `?code=2397rf3gu93f`
* `response_mode=fragment` -> O código é fornecido dentro do parâmetro de fragmento da URL `#code=2397rf3gu93f`
* `response_mode=form_post` -> O código é fornecido dentro de um formulário POST com um input chamado `code` e o valor
* `response_mode=web_message` -> O código é enviado em uma mensagem post: `window.opener.postMessage({"code": "asdasdasd...`
### Parâmetros SSRFs <a href="#bda5" id="bda5"></a> ### 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.** [**Confira esta pesquisa**](https://portswigger.net/research/hidden-oauth-attack-vectors) **para mais detalhes desta técnica.**
O Registro Dinâmico do Cliente 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. O Registro Dinâmico de Cliente 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 exploradas.
**Pontos-chave:** **Pontos Chave:**
- O **Registro Dinâmico do Cliente** é frequentemente 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. * **Registro Dinâmico de Cliente** é frequentemente mapeado para `/register` e aceita detalhes como `client_name`, `client_secret`, `redirect_uris` e URLs para logos ou Conjuntos de Chaves JSON Web (JWKs) via requisições POST.
- Este recurso adere às especificações estabelecidas em **RFC7591** e **OpenID Connect Registration 1.0**, que incluem parâmetros potencialmente vulneráveis ao SSRF. * Este recurso adere às especificações estabelecidas no **RFC7591** e **OpenID Connect Registration 1.0**, que incluem parâmetros potencialmente vulneráveis a SSRF.
- O processo de registro pode expor inadvertidamente servidores ao SSRF de várias maneiras: * O processo de registro pode inadvertidamente expor servidores a 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 de forma inadequada. * **`logo_uri`**: Uma URL para o logo do aplicativo cliente que pode ser buscada pelo servidor, desencadeando SSRF ou levando a XSS se a URL for mal manipulada.
- **`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. * **`jwks_uri`**: Uma URL para o documento JWK do cliente, que se maliciosamente elaborada, pode fazer com que o servidor faça requisições externas para um servidor controlado pelo atacante.
- **`sector_identifier_uri`**: Faz referência a uma matriz JSON de `redirect_uris`, que o servidor pode buscar, criando uma oportunidade de SSRF. * **`sector_identifier_uri`**: Refere-se 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. * **`request_uris`**: Lista URIs de requisição permitidas para o cliente, que podem ser exploradas se o servidor buscar essas URIs no início do processo de autorização.
**Estratégia de Exploração:** **Estratégia de Exploração:**
- O SSRF pode ser acionado registrando um novo cliente com URLs maliciosos em parâmetros como `logo_uri`, `jwks_uri` ou `sector_identifier_uri`. * SSRF pode ser desencadeada registrando um novo cliente com URLs maliciosas 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` controlado pelo atacante pré-registrado pode facilitar o SSRF durante a fase de autorização. * Enquanto a exploração direta via `request_uris` pode ser mitigada por controles de lista branca, fornecer um `request_uri` pré-registrado e controlado pelo atacante pode facilitar SSRF durante a fase de autorização.
## Condições de Corrida em provedores OAuth ## Condições de Corrida de Provedores OAuth
Se a plataforma que você está testando for um provedor OAuth, [**leia isso para testar possíveis Condições de Corrida**](race-condition.md). Se a plataforma que você está testando é um provedor OAuth [**leia isto para testar possíveis Condições de Corrida**](race-condition.md).
## Referências ## Referências
* [**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://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) * [**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> <figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %} {% embed url="https://websec.nl/" %}
@ -223,10 +232,10 @@ Se a plataforma que você está testando for um provedor OAuth, [**leia isso par
Outras maneiras de apoiar o HackTricks: Outras maneiras de apoiar o HackTricks:
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * Se você quer 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) * Obtenha o [**swag oficial do 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) * 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)**.** * **Junte-se ao** 💬 [**grupo no Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo no telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud). * **Compartilhe suas dicas de hacking enviando PRs para os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) no github.
</details> </details>