mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
130 lines
6.3 KiB
Markdown
130 lines
6.3 KiB
Markdown
# Account Takeover
|
|
|
|
{{#include ../banners/hacktricks-training.md}}
|
|
|
|
## **Problema di Autorizzazione**
|
|
|
|
L'email di un account dovrebbe essere tentata per essere cambiata, e il processo di conferma **deve essere esaminato**. Se risulta **debole**, l'email dovrebbe essere cambiata con quella della vittima designata e poi confermata.
|
|
|
|
## **Problema di Normalizzazione Unicode**
|
|
|
|
1. L'account della vittima designata `victim@gmail.com`
|
|
2. Un account dovrebbe essere creato utilizzando Unicode\
|
|
per esempio: `vićtim@gmail.com`
|
|
|
|
Come spiegato in [**questo intervento**](https://www.youtube.com/watch?v=CiIyaZ3x49c), l'attacco precedente potrebbe essere effettuato abusando dei fornitori di identità di terze parti:
|
|
|
|
- Creare un account nel fornitore di identità di terze parti con un'email simile a quella della vittima utilizzando qualche carattere unicode (`vićtim@company.com`).
|
|
- Il fornitore di terze parti non dovrebbe verificare l'email.
|
|
- Se il fornitore di identità verifica l'email, forse puoi attaccare la parte del dominio come: `victim@ćompany.com` e registrare quel dominio e sperare che il fornitore di identità generi la versione ascii del dominio mentre la piattaforma della vittima normalizza il nome del dominio.
|
|
- Accedi tramite questo fornitore di identità nella piattaforma della vittima che dovrebbe normalizzare il carattere unicode e permetterti di accedere all'account della vittima.
|
|
|
|
Per ulteriori dettagli, fare riferimento al documento sulla Normalizzazione Unicode:
|
|
|
|
{{#ref}}
|
|
unicode-injection/unicode-normalization.md
|
|
{{#endref}}
|
|
|
|
## **Riutilizzo del Token di Reset**
|
|
|
|
Se il sistema target consente che il **link di reset venga riutilizzato**, dovrebbero essere fatti sforzi per **trovare più link di reset** utilizzando strumenti come `gau`, `wayback` o `scan.io`.
|
|
|
|
## **Pre Account Takeover**
|
|
|
|
1. L'email della vittima dovrebbe essere utilizzata per registrarsi sulla piattaforma, e dovrebbe essere impostata una password (si dovrebbe tentare di confermarla, anche se la mancanza di accesso alle email della vittima potrebbe rendere questo impossibile).
|
|
2. Si dovrebbe aspettare fino a quando la vittima si registra utilizzando OAuth e conferma l'account.
|
|
3. Si spera che la registrazione regolare venga confermata, consentendo l'accesso all'account della vittima.
|
|
|
|
## **Misconfigurazione CORS per Account Takeover**
|
|
|
|
Se la pagina contiene **misconfigurazioni CORS**, potresti essere in grado di **rubare informazioni sensibili** dall'utente per **prendere il controllo del suo account** o fargli cambiare le informazioni di autenticazione per lo stesso scopo:
|
|
|
|
{{#ref}}
|
|
cors-bypass.md
|
|
{{#endref}}
|
|
|
|
## **Csrf per Account Takeover**
|
|
|
|
Se la pagina è vulnerabile a CSRF, potresti essere in grado di far **modificare all'utente la sua password**, email o autenticazione in modo da poter accedere:
|
|
|
|
{{#ref}}
|
|
csrf-cross-site-request-forgery.md
|
|
{{#endref}}
|
|
|
|
## **XSS per Account Takeover**
|
|
|
|
Se trovi un XSS nell'applicazione, potresti essere in grado di rubare cookie, storage locale o informazioni dalla pagina web che potrebbero consentirti di prendere il controllo dell'account:
|
|
|
|
{{#ref}}
|
|
xss-cross-site-scripting/
|
|
{{#endref}}
|
|
|
|
## **Stessa Origine + Cookie**
|
|
|
|
Se trovi un XSS limitato o un takeover di sottodominio, potresti giocare con i cookie (fissandoli ad esempio) per cercare di compromettere l'account della vittima:
|
|
|
|
{{#ref}}
|
|
hacking-with-cookies/
|
|
{{#endref}}
|
|
|
|
## **Attacco al Meccanismo di Reset della Password**
|
|
|
|
{{#ref}}
|
|
reset-password.md
|
|
{{#endref}}
|
|
|
|
## **Manipolazione della Risposta**
|
|
|
|
Se la risposta di autenticazione può essere **ridotta a un semplice booleano, prova a cambiare false in true** e vedere se ottieni accesso.
|
|
|
|
## OAuth per Account Takeover
|
|
|
|
{{#ref}}
|
|
oauth-to-account-takeover.md
|
|
{{#endref}}
|
|
|
|
## Iniezione dell'Intestazione Host
|
|
|
|
1. L'intestazione Host viene modificata dopo l'inizio di una richiesta di reset della password.
|
|
2. L'intestazione proxy `X-Forwarded-For` viene alterata in `attacker.com`.
|
|
3. Le intestazioni Host, Referrer e Origin vengono contemporaneamente cambiate in `attacker.com`.
|
|
4. Dopo aver avviato un reset della password e poi optato per rinviare la mail, vengono impiegati tutti e tre i metodi sopra menzionati.
|
|
|
|
## Manipolazione della Risposta
|
|
|
|
1. **Manipolazione del Codice**: Il codice di stato viene alterato in `200 OK`.
|
|
2. **Manipolazione del Codice e del Corpo**:
|
|
- Il codice di stato viene cambiato in `200 OK`.
|
|
- Il corpo della risposta viene modificato in `{"success":true}` o un oggetto vuoto `{}`.
|
|
|
|
Queste tecniche di manipolazione sono efficaci in scenari in cui viene utilizzato JSON per la trasmissione e la ricezione dei dati.
|
|
|
|
## Cambiare l'email della sessione corrente
|
|
|
|
Da [questo rapporto](https://dynnyd20.medium.com/one-click-account-take-over-e500929656ea):
|
|
|
|
- L'attaccante richiede di cambiare la sua email con una nuova.
|
|
- L'attaccante riceve un link per confermare il cambiamento dell'email.
|
|
- L'attaccante invia alla vittima il link affinché lo clicchi.
|
|
- L'email della vittima viene cambiata in quella indicata dall'attaccante.
|
|
- L'attaccante può recuperare la password e prendere il controllo dell'account.
|
|
|
|
Questo è accaduto anche in [**questo rapporto**](https://dynnyd20.medium.com/one-click-account-take-over-e500929656ea).
|
|
|
|
### Bypassare la verifica dell'email per Account Takeover
|
|
- L'attaccante accede con attacker@test.com e verifica l'email al momento della registrazione.
|
|
- L'attaccante cambia l'email verificata in victim@test.com (nessuna verifica secondaria sul cambiamento dell'email).
|
|
- Ora il sito consente a victim@test.com di accedere e abbiamo bypassato la verifica dell'email dell'utente vittima.
|
|
|
|
### Vecchi Cookie
|
|
|
|
Come spiegato [**in questo post**](https://medium.com/@niraj1mahajan/uncovering-the-hidden-vulnerability-how-i-found-an-authentication-bypass-on-shopifys-exchange-cc2729ea31a9), era possibile accedere a un account, salvare i cookie come utente autenticato, disconnettersi e poi accedere di nuovo.\
|
|
Con il nuovo accesso, anche se potrebbero essere generati cookie diversi, i vecchi hanno ricominciato a funzionare.
|
|
|
|
## Riferimenti
|
|
|
|
- [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}}
|