# Tomada de Conta

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

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

O e-mail de uma conta deve ser tentado a ser alterado, e o processo de confirmação **deve ser examinado**. Se encontrado **fraco**, o e-mail deve ser alterado para o do alvo pretendido e então confirmado.

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

1. A conta do alvo 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 e-mail semelhante ao da vítima usando algum caractere unicode (`vićtim@company.com`).
- O provedor de terceiros não deve verificar o e-mail.
- Se o provedor de identidade verificar o e-mail, talvez você possa atacar a parte do domínio como: `victim@ćompany.com` e registrar esse domínio, esperando que o provedor de identidade gere a versão ascii do domínio enquanto a plataforma da vítima normaliza o nome do domínio.
- Faça login via este provedor de identidade na plataforma da vítima, que deve normalizar o caractere unicode e permitir que você acesse a conta da 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 e-mail da 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 e-mails da vítima possa tornar isso impossível).
2. Deve-se esperar até que a vítima se inscreva usando OAuth e confirme a conta.
3. Espera-se que a inscrição regular seja confirmada, permitindo o acesso à conta da 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 com que o **usuário modifique sua senha**, e-mail 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, pode brincar com os cookies (fixando-os, por exemplo) para tentar comprometer a conta da 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 e-mail, 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 e-mail da sessão atual

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

- O atacante solicita alterar seu e-mail para um novo.
- O atacante recebe um link para confirmar a alteração do e-mail.
- O atacante envia o link para a vítima para que ela clique.
- O e-mail da 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).

### Bypass de verificação de e-mail para Tomada de Conta
- O atacante faz login com attacker@test.com e verifica o e-mail ao se inscrever.
- O atacante altera o e-mail verificado para victim@test.com (sem verificação secundária na alteração do e-mail).
- Agora o site permite que victim@test.com faça login e contornamos a verificação de e-mail do usuário vítima.

### 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 depois fazer login novamente.\
Com o novo login, embora cookies diferentes possam ser gerados, os antigos voltaram a funcionar.

## 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}}