# Tomada de Conta

{{#include ../banners/hacktricks-training.md}}

## **Problema de Autorização**

O email de uma conta deve ser tentado a ser alterado, e o processo de confirmação **deve ser examinado**. Se encontrado **fraco**, o email deve ser alterado para o do vítima pretendido e então confirmado.

## **Problema de Normalização Unicode**

1. A conta do vítima pretendido `victim@gmail.com`
2. Uma conta deve ser criada usando Unicode\
por exemplo: `vićtim@gmail.com`

Como explicado em [**esta palestra**](https://www.youtube.com/watch?v=CiIyaZ3x49c), o ataque anterior também poderia ser realizado abusando de provedores de identidade de terceiros:

- Criar uma conta no provedor de identidade de terceiros com um email semelhante ao do vítima usando algum caractere unicode (`vićtim@company.com`).
- O provedor de terceiros não deve verificar o email.
- Se o provedor de identidade verificar o email, talvez você possa atacar a parte do domínio como: `victim@ćompany.com` e registrar esse domínio e esperar que o provedor de identidade gere a versão ascii do domínio enquanto a plataforma do vítima normaliza o nome do domínio.
- Faça login via este provedor de identidade na plataforma do vítima que deve normalizar o caractere unicode e permitir que você acesse a conta do vítima.

Para mais detalhes, consulte o documento sobre Normalização Unicode:

{{#ref}}
unicode-injection/unicode-normalization.md
{{#endref}}

## **Reutilização do Token de Redefinição**

Se o sistema alvo permitir que o **link de redefinição seja reutilizado**, esforços devem ser feitos para **encontrar mais links de redefinição** usando ferramentas como `gau`, `wayback` ou `scan.io`.

## **Pré Tomada de Conta**

1. O email do vítima deve ser usado para se inscrever na plataforma, e uma senha deve ser definida (uma tentativa de confirmá-la deve ser feita, embora a falta de acesso aos emails do vítima possa tornar isso impossível).
2. Deve-se esperar até que o vítima se inscreva usando OAuth e confirme a conta.
3. Espera-se que a inscrição regular seja confirmada, permitindo o acesso à conta do vítima.

## **Configuração CORS Incorreta para Tomada de Conta**

Se a página contiver **configurações CORS incorretas**, você pode ser capaz de **roubar informações sensíveis** do usuário para **tomar conta de sua conta** ou fazer com que ele altere informações de autenticação para o mesmo propósito:

{{#ref}}
cors-bypass.md
{{#endref}}

## **CSRF para Tomada de Conta**

Se a página for vulnerável a CSRF, você pode ser capaz de fazer o **usuário modificar sua senha**, email ou autenticação para que você possa acessá-la:

{{#ref}}
csrf-cross-site-request-forgery.md
{{#endref}}

## **XSS para Tomada de Conta**

Se você encontrar um XSS na aplicação, pode ser capaz de roubar cookies, armazenamento local ou informações da página da web que poderiam permitir que você tomasse conta da conta:

{{#ref}}
xss-cross-site-scripting/
{{#endref}}

## **Mesma Origem + Cookies**

Se você encontrar um XSS limitado ou uma tomada de subdomínio, você poderia brincar com os cookies (fixando-os, por exemplo) para tentar comprometer a conta do vítima:

{{#ref}}
hacking-with-cookies/
{{#endref}}

## **Atacando o Mecanismo de Redefinição de Senha**

{{#ref}}
reset-password.md
{{#endref}}

## **Manipulação de Resposta**

Se a resposta de autenticação puder ser **reduzida a um simples booleano, apenas tente mudar falso para verdadeiro** e veja se você obtém algum acesso.

## OAuth para Tomada de Conta

{{#ref}}
oauth-to-account-takeover.md
{{#endref}}

## Injeção de Cabeçalho Host

1. O cabeçalho Host é modificado após a iniciação de um pedido de redefinição de senha.
2. O cabeçalho proxy `X-Forwarded-For` é alterado para `attacker.com`.
3. Os cabeçalhos Host, Referrer e Origin são simultaneamente alterados para `attacker.com`.
4. Após iniciar uma redefinição de senha e optar por reenviar o email, todos os três métodos mencionados são empregados.

## Manipulação de Resposta

1. **Manipulação de Código**: O código de status é alterado para `200 OK`.
2. **Manipulação de Código e Corpo**:
- O código de status é alterado para `200 OK`.
- O corpo da resposta é modificado para `{"success":true}` ou um objeto vazio `{}`.

Essas técnicas de manipulação são eficazes em cenários onde JSON é utilizado para transmissão e recebimento de dados.

## Alterar email da sessão atual

De [este relatório](https://dynnyd20.medium.com/one-click-account-take-over-e500929656ea):

- O atacante solicita alterar seu email para um novo.
- O atacante recebe um link para confirmar a alteração do email.
- O atacante envia ao vítima o link para que ele clique.
- O email do vítima é alterado para o indicado pelo atacante.
- O atacante pode recuperar a senha e tomar conta da conta.

Isso também aconteceu em [**este relatório**](https://dynnyd20.medium.com/one-click-account-take-over-e500929656ea).

### Cookies Antigos

Como explicado [**neste post**](https://medium.com/@niraj1mahajan/uncovering-the-hidden-vulnerability-how-i-found-an-authentication-bypass-on-shopifys-exchange-cc2729ea31a9), foi possível fazer login em uma conta, salvar os cookies como um usuário autenticado, sair e então fazer login novamente.\
Com o novo login, embora cookies diferentes possam ser gerados, os antigos começaram a funcionar novamente.

## Referências

- [https://infosecwriteups.com/firing-8-account-takeover-methods-77e892099050](https://infosecwriteups.com/firing-8-account-takeover-methods-77e892099050)
- [https://dynnyd20.medium.com/one-click-account-take-over-e500929656ea](https://dynnyd20.medium.com/one-click-account-take-over-e500929656ea)

{{#include ../banners/hacktricks-training.md}}