Compromissione dell’account

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Problema di autorizzazione

Si dovrebbe tentare di cambiare l’email di un account e il processo di conferma deve essere esaminato. Se risulta debole, l’email dovrebbe essere cambiata con quella della vittima prevista e poi confermata.

Problema di normalizzazione Unicode

  1. L’account della vittima prevista victim@gmail.com
  2. Si dovrebbe creare un account usando Unicode
    per esempio: vićtim@gmail.com

Come spiegato in this talk, l’attacco precedente potrebbe essere effettuato anche abusando di third party identity providers:

  • Crea un account nel third party identity con un’email simile a quella della vittima usando qualche carattere unicode (vićtim@company.com).
  • Il third party provider non dovrebbe verificare l’email
  • Se l’identity provider verifica l’email, forse puoi attaccare la parte di dominio come: victim@ćompany.com e registrare quel dominio sperando che l’identity provider generi la versione ascii del dominio mentre la piattaforma della vittima normalizza il nome di dominio.
  • Effettua il login tramite questo identity provider nella piattaforma della vittima che dovrebbe normalizzare il carattere unicode e permetterti di accedere all’account della vittima.

Per maggiori dettagli, fare riferimento al documento sulla normalizzazione Unicode:

Unicode Normalization

Riutilizzo del token di reset

Se il sistema target permette che il link di reset venga riutilizzato, si dovrebbero fare sforzi per trovare altri link di reset usando strumenti come gau, wayback, o scan.io.

Fase pre-compromissione dell’account

  1. L’email della vittima dovrebbe essere usata per registrarsi sulla piattaforma, impostando una password (va tentata anche la conferma, anche se la mancanza di accesso alle email della vittima potrebbe rendere impossibile questa operazione).
  2. Si dovrebbe aspettare che la vittima si registri usando OAuth e confermi l’account.
  3. Si spera che la registrazione regolare venga confermata, permettendo l’accesso all’account della vittima.

CORS Misconfiguration per la compromissione dell’account

Se la pagina contiene CORS misconfigurations potresti essere in grado di rubare informazioni sensibili dall’utente per compromettere il suo account o fargli modificare le informazioni di autenticazione per lo stesso scopo:

CORS - Misconfigurations & Bypass

CSRF per la compromissione dell’account

Se la pagina è vulnerabile a CSRF potresti essere in grado di far sì che l’utente modifichi la sua password, email o autenticazione in modo da poter poi accedervi:

CSRF (Cross Site Request Forgery)

XSS per la compromissione dell’account

Se trovi una XSS nell’applicazione potresti essere in grado di rubare cookie, local storage, o info dalla pagina web che potrebbero permetterti di compromettere l’account:

XSS (Cross Site Scripting)

  • Attribute-only reflected payloads on login pages can hook document.onkeypress, exfiltrate keystrokes through new Image().src, and steal credentials without submitting the form. See Attribute-only login XSS behind WAFs for a practical workflow.

Same Origin + Cookies

Se trovi una XSS limitata o un subdomain take over, potresti giocare con i cookie (fixandoli ad esempio) per tentare di compromettere l’account della vittima:

Cookies Hacking

Attaccare il meccanismo di reset della password

Reset/Forgotten Password Bypass

Reset delle security-question che si fidano di username forniti dal client

Se un flow di “update security questions” accetta un parametro username nonostante il chiamante sia già autenticato, puoi sovrascrivere i dati di recupero di qualsiasi account (inclusi gli admin) perché il backend tipicamente esegue UPDATE ... WHERE user_name = ? con il tuo valore non attendibile. Il pattern è:

  1. Effettua il login con un utente usa-e-getta e cattura il cookie di sessione.
  2. Invia il username della vittima più le nuove risposte tramite il form di reset.
  3. Autenticati immediatamente tramite l’endpoint di login con le security-question usando le risposte che hai appena iniettato per ereditare i privilegi della vittima.
POST /reset.php HTTP/1.1
Host: file.era.htb
Cookie: PHPSESSID=<low-priv>
Content-Type: application/x-www-form-urlencoded

username=admin_ef01cab31aa&new_answer1=A&new_answer2=B&new_answer3=C

Qualsiasi cosa protetta dal contesto $_SESSION della vittima (dashboard di amministrazione, funzionalità pericolose come stream-wrapper, ecc.) è ora esposta senza toccare le risposte reali.

Gli username enumerati possono poi essere presi di mira via the overwrite technique sopra oppure riutilizzati contro servizi accessori (FTP/SSH password spraying).

Response Manipulation

Se la risposta di autenticazione può essere ridotta a un semplice booleano, prova a cambiare false in true e vedi se ottieni accesso.

OAuth to Account takeover

OAuth to Account takeover

Host Header Injection

  1. L’header Host viene modificato dopo l’avvio di una richiesta di reset password.
  2. L’header proxy X-Forwarded-For viene cambiato in attacker.com.
  3. Gli header Host, Referrer e Origin vengono simultaneamente cambiati in attacker.com.
  4. Dopo aver avviato un reset della password e poi scelto di reinviare la mail, vengono impiegati tutti e tre i metodi sopra citati.

Response Manipulation

  1. Code Manipulation: il codice di stato viene modificato in 200 OK.
  2. Code and Body Manipulation:
  • Il codice di stato viene cambiato in 200 OK.
  • Il body della risposta viene modificato in {"success":true} o in un oggetto vuoto {}.

Queste tecniche di manipolazione sono efficaci in scenari in cui JSON è utilizzato per la trasmissione e la ricezione dei dati.

Cambiare l’email della sessione corrente

From this report:

  • L’attaccante richiede di cambiare la propria email con una nuova
  • L’attaccante riceve un link per confermare il cambio dell’email
  • L’attaccante invia il link alla vittima che ci clicca sopra
  • L’email della vittima viene cambiata in quella indicata dall’attaccante
  • L’attacco può recuperare la password e prendere il controllo dell’account

This also happened in this report.

Bypass email verification for Account Takeover

  • L’attaccante effettua il login 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 cambio email)
  • Ora il sito permette a victim@test.com di effettuare il login e abbiamo bypassato la verifica email dell’utente vittima.

Old Cookies

As explained in this post, era possibile effettuare il login in un account, salvare i cookie come utente autenticato, fare logout, e poi effettuare di nuovo il login.
Con il nuovo login, anche se potevano essere generati cookie diversi, i vecchi ricominciavano a funzionare.

Trusted device cookies + batch API leakage

Identificatori di dispositivo a lunga durata che controllano il recovery possono essere rubati quando una batch API permette di copiare subresponses non leggibili in sink scrivibili.

  • Individua un trusted-device cookie (SameSite=None, long-lived) usato per allentare i controlli di recovery.
  • Trova un first-party endpoint che restituisce quell’ID dispositivo in JSON (es. uno scambio OAuth code che ritorna machine_id) ma non è leggibile cross-origin.
  • Usa una batch/chained API che permette di referenziare subresponses precedenti ({result=name:$.path}) e scriverle in uno sink visibile dall’attaccante (page post, upload-by-URL, ecc.). Esempio con Facebook Graph API:
POST https://graph.facebook.com/
batch=[
{"method":"post","omit_response_on_success":0,"relative_url":"/oauth/access_token?client_id=APP_ID%26redirect_uri=REDIRECT_URI","body":"code=SINGLE_USE_CODE","name":"leaker"},
{"method":"post","relative_url":"PAGE_ID/posts","body":"message={result=leaker:$.machine_id}"}
]
access_token=PAGE_ACCESS_TOKEN&method=post
  • Carica la batch URL in un <iframe> nascosto in modo che la vittima invii il trusted-device cookie; il riferimento JSON-path copia machine_id nel post controllato dall’attaccante anche se la OAuth response è illeggibile per la pagina.
  • Replay: imposta il cookie del device rubato in una nuova sessione. Recovery ora considera il browser come trusted, spesso esponendo flussi più deboli “no email/phone” (es., upload automatico di documenti) per aggiungere un’email dell’attaccante senza la password o 2FA.

Riferimenti

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks