mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-30 16:39:32 +00:00
Translated ['pentesting-web/oauth-to-account-takeover.md'] to pt
This commit is contained in:
Translator
parent
abba30be01
commit
223d1de330
1 changed files with 100 additions and 91 deletions
|
|
@ -1,16 +1,16 @@
|
|||
# OAuth para Assumir o Controle da Conta
|
||||
# OAuth to Account takeover
|
||||
|
||||
<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:
|
||||
|
||||
* 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 do PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* 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)!
|
||||
* 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)
|
||||
* **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)**.**
|
||||
* **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.
|
||||
* **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 do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
|
||||
</details>
|
||||
|
||||
|
|
@ -18,36 +18,35 @@ Outras maneiras de apoiar o HackTricks:
|
|||
|
||||
{% embed url="https://websec.nl/" %}
|
||||
|
||||
|
||||
## 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.
|
||||
- **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 que especifica **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 é fundamental 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**.
|
||||
* **resource owner**: Você, como **usuário/entidade**, autoriza o acesso ao seu recurso, como as postagens da sua conta de rede social.
|
||||
* **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**.
|
||||
* **client application**: O **aplicativo que busca autorização** do `resource owner`, como **https://example.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\_secret:** Uma chave confidencial, conhecida apenas pelo aplicativo e pelo servidor de autorização, usada para gerar `access_tokens`.
|
||||
* **response\_type**: Um valor especificando **o tipo de token solicitado**, como `code`.
|
||||
* **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**. 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 é crítica para servir como um **mecanismo de proteção contra CSRF**.
|
||||
* **grant\_type**: Um parâmetro indicando **o tipo de concessão e o tipo de token a ser retornado**.
|
||||
* **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`.
|
||||
* **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 `access_token` sem solicitar novamente ao 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:
|
||||
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://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
|
||||
?response_type=code
|
||||
|
|
@ -56,64 +55,62 @@ https://socialmedia.com/auth
|
|||
&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`:
|
||||
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`:
|
||||
```
|
||||
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
|
||||
Host: socialmedia.com
|
||||
...{"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>
|
||||
|
||||
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>
|
||||
```
|
||||
### 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 **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:
|
||||
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:
|
||||
```
|
||||
POST /token HTTP/1.1
|
||||
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]
|
||||
```
|
||||
### 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>
|
||||
|
||||
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
|
||||
# Read info of the user
|
||||
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" %}
|
||||
|
||||
### 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" %}
|
||||
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 %}
|
||||
|
||||
### 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>
|
||||
|
||||
**[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.
|
||||
- Este recurso adere às 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 expor inadvertidamente 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 de forma inadequada.
|
||||
- **`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 uma matriz 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.
|
||||
* **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 no **RFC7591** e **OpenID Connect Registration 1.0**, que incluem parâmetros potencialmente vulneráveis a SSRF.
|
||||
* O processo de registro pode inadvertidamente expor servidores a SSRF de várias maneiras:
|
||||
* **`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`**: 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`**: Refere-se a um array JSON de `redirect_uris`, que o servidor pode buscar, criando uma oportunidade de SSRF.
|
||||
* **`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:**
|
||||
|
||||
- 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` controlado pelo atacante pré-registrado pode facilitar o SSRF durante a fase de autorização.
|
||||
* SSRF pode ser desencadeada registrando um novo cliente com URLs maliciosas em parâmetros como `logo_uri`, `jwks_uri` ou `sector_identifier_uri`.
|
||||
* 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
|
||||
|
||||
* [**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/" %}
|
||||
|
|
@ -223,10 +232,10 @@ Se a plataforma que você está testando for um provedor OAuth, [**leia isso par
|
|||
|
||||
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)!
|
||||
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* 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)!
|
||||
* 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)
|
||||
* **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 os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
* **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 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>
|
||||
|
|
|
|||
Loading…
Reference in a new issue