Account Takeover
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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.
L'account della vittima designata victim@gmail.com
Un account dovrebbe essere creato utilizzando Unicode
per esempio: vićtim@gmail.com
Come spiegato in questo intervento, l'attacco precedente potrebbe essere effettuato abusando di 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 di 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 di 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:
Unicode NormalizationSe il sistema target consente il riutilizzo del link di reset, dovrebbero essere fatti sforzi per trovare più link di reset utilizzando strumenti come gau, wayback o scan.io.
L'email della vittima dovrebbe essere utilizzata per registrarsi sulla piattaforma, e dovrebbe essere impostata una password (dovrebbe essere fatto un tentativo di confermarla, anche se la mancanza di accesso alle email della vittima potrebbe rendere questo impossibile).
Si dovrebbe aspettare fino a quando la vittima si registra utilizzando OAuth e conferma l'account.
Si spera che la registrazione regolare venga confermata, consentendo l'accesso all'account della vittima.
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:
CORS - Misconfigurations & BypassSe 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:
CSRF (Cross Site Request Forgery)Se trovi un XSS nell'applicazione potresti essere in grado di rubare cookie, storage locale, o informazioni dalla pagina web che potrebbero permetterti di prendere il controllo dell'account:
XSS (Cross Site Scripting)Se trovi un XSS limitato o un takeover di sottodominio, potresti giocare con i cookie (fissandoli per esempio) per cercare di compromettere l'account della vittima:
Cookies HackingSe la risposta di autenticazione può essere ridotta a un semplice booleano prova a cambiare false in true e vedere se ottieni accesso.
L'intestazione Host viene modificata dopo l'inizio di una richiesta di reset della password.
L'intestazione proxy X-Forwarded-For viene alterata in attacker.com.
Le intestazioni Host, Referrer e Origin vengono contemporaneamente cambiate in attacker.com.
Dopo aver avviato un reset della password e poi optato per rinviare la mail, vengono impiegati tutti e tre i metodi sopra menzionati.
Manipolazione del Codice: Il codice di stato viene alterato in 200 OK.
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.
Da questo rapporto:
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.
Come spiegato in questo post, 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.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
