Sponsored

Bypass di 2FA/MFA/OTP

Tip

Impara e fai pratica con AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara e fai pratica con GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara e fai pratica con Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)
Sfoglia il catalogo completo di HackTricks Training.

Supporta HackTricks

Tecniche avanzate di bypass dell’autenticazione a due fattori

Accesso diretto agli endpoint

Vedi Proxmox VE per un esempio specifico di prodotto in cui lo stato TFA è selezionato dal client.

Prova direttamente l’endpoint post-login e verifica che sia il server, non solo la UI, a richiedere il completamento dello stato MFA. Se un’applicazione si fida erroneamente dei metadati di navigazione, verifica anche l’header HTTP Referer, scritto correttamente; un’implementazione sicura non deve usarlo come prova dell’MFA.[2][5]

Riutilizzo dei token

Riutilizzare token già usati per l’autenticazione all’interno di un account può essere efficace.[2]

Utilizzo di token non utilizzati

Verifica se un token non utilizzato, generato per un tuo account di test, viene accettato erroneamente per un altro account di test autorizzato. Questo permette di controllare che gli OTP siano associati all’account, alla sessione, allo scopo e alla transazione corretti.[2][5]

Esposizione del token

Verifica se il token viene divulgato in una risposta dell’applicazione web.[2]

L’uso del link di verifica email inviato alla creazione dell’account può consentire l’accesso al profilo senza 2FA, come evidenziato in un post dettagliato.[3]

Manipolazione della sessione

Avvia sessioni per due account di test autorizzati, completa l’MFA in una e verifica che il suo stato di completamento non possa essere trasferito all’altra sessione. Il backend deve associare il risultato dell’MFA allo stesso account e alla sessione di pre-autenticazione.[5]

Meccanismo di reimpostazione della password

È fondamentale esaminare la funzione di reimpostazione della password, che dopo la reimpostazione effettua il login dell’utente nell’applicazione, per verificare se consente più reimpostazioni usando lo stesso link. Effettuare il login con le credenziali appena reimpostate potrebbe aggirare la 2FA.[2]

Compromissione della piattaforma OAuth

Verifica se un percorso di login federato OAuth/OIDC applica un livello di garanzia equivalente a quello del percorso dell’applicazione basato su password e MFA. Il controllo dell’account di identità upstream può aggirare l’MFA locale dell’applicazione solo se il relying party accetta quella sessione federata più debole.[5]

Attacchi brute force

Assenza di rate limit

L’assenza di un limite al numero di tentativi con il codice consente attacchi brute force, anche se va considerata la possibile presenza di un rate limit silenzioso.[1][2]

Nota che, anche se è presente un rate limit, dovresti verificare se la risposta cambia quando viene inviato l’OTP valido. In questo post, il bug hunter ha scoperto che, anche se dopo 20 tentativi non riusciti veniva attivato un rate limit con risposta 401, l’invio del codice valido restituiva una risposta 200.[4]

Brute force lento

Un attacco brute force lento è possibile quando esistono rate limit per il flusso, ma non un rate limit generale.[1]

Reimpostazione del limite di invio del codice

Inviare nuovamente il codice reimposta il rate limit, consentendo di continuare i tentativi brute force.[1]

Elusione del rate limit lato client

Se il throttling è implementato solo in JavaScript, ripeti la richiesta direttamente e verifica se il server applica autonomamente limiti per account, sessione e abuso generale.[1][5]

Le azioni interne non hanno un rate limit

I rate limit possono proteggere i tentativi di login, ma non le azioni interne dell’account.[1]

Costi dell’invio ripetuto di codici SMS

L’invio eccessivo di codici via SMS comporta costi per l’azienda, ma non aggira la 2FA.

Rigenerazione infinita degli OTP

La generazione infinita di OTP con codici semplici consente di effettuare brute force riprovando un piccolo insieme di codici.[1]

Sfruttamento di race condition

Invia lo stesso OTP o codice di recupero contemporaneamente e verifica che la convalida e il consumo siano operazioni atomiche. Esiste una race condition se più di una richiesta può riscattare un valore monouso.[5]

Vulnerabilità CSRF/Clickjacking

Esplorare le vulnerabilità CSRF o Clickjacking per disabilitare la 2FA è una strategia praticabile.[1][2]

Sfruttamento della funzione “Remember Me”

Indovinare il valore del cookie “remember me” può aggirare le restrizioni.[1]

Falsificazione dell’indirizzo IP

Falsificare l’indirizzo IP della vittima tramite l’header X-Forwarded-For può aggirare le restrizioni.[1]

Utilizzo di versioni precedenti

Sottodomini

Verifica se i sottodomini espongono applicazioni o percorsi di autenticazione precedenti, privi dell’attuale requisito MFA.[1]

Endpoint API

Le versioni precedenti delle API, indicate da percorsi di directory /v*/, potrebbero essere vulnerabili a tecniche di bypass della 2FA.[1]

Gestione delle sessioni precedenti

Terminare le sessioni esistenti quando si attiva la 2FA protegge gli account dall’accesso non autorizzato tramite sessioni compromesse.[1]

Difetti di controllo degli accessi con i codici di backup

La generazione immediata e il potenziale recupero non autorizzato dei codici di backup all’attivazione della 2FA, soprattutto in presenza di configurazioni errate di CORS o vulnerabilità XSS, comportano un rischio.[1][2]

Divulgazione di informazioni nella pagina 2FA

La divulgazione di informazioni sensibili (ad esempio, il numero di telefono) nella pagina di verifica 2FA è un problema.[1]

Disattivazione della 2FA tramite reimpostazione della password

Un possibile metodo di bypass consiste nel creare un account, attivare la 2FA, reimpostare la password ed effettuare successivamente il login senza che venga richiesta la 2FA.[2]

Richieste esca

L’uso di richieste esca per mascherare i tentativi brute force o ingannare i meccanismi di rate limiting aggiunge un ulteriore livello alle strategie di bypass. Per creare queste richieste è necessaria una comprensione approfondita delle misure di sicurezza e dei meccanismi di rate limiting dell’applicazione.

Errori nella costruzione dell’OTP

Se l’OTP deriva solo da dati prevedibili o forniti dal client, un utente potrebbe riuscire a riprodurlo. Verifica che i codici siano generati usando un segreto crittograficamente sicuro, abbiano una validità limitata, siano monouso e siano associati all’account e all’azione corretti.[5]

Autenticazione step-up non applicata (acr, amr, auth_time)

Alcune app consentono agli utenti di effettuare il login con un metodo debole e richiedono l’MFA o un nuovo login solo prima di un’azione sensibile (modificare l’email, aggiungere un beneficiario, esportare dati, accedere a un’area di amministrazione). Questa modalità è chiamata autenticazione step-up. Con OpenID Connect o OAuth, di solito funziona così:

  • Il client richiede al provider di identità un login più sicuro usando acr_values=<level> e/o max_age=<seconds> nella richiesta di autorizzazione.[6]
  • L’ID token, o un profilo di access token che include il contesto di autenticazione, può indicare cosa è avvenuto: acr (il livello di autenticazione soddisfatto), amr (i metodi utilizzati, ad esempio ["pwd","otp"]) e auth_time (quando l’utente si è autenticato). Non tutti questi claim sono presenti in ogni token.[6]
  • Un’API che richiede un login più sicuro risponde con 401 e WWW-Authenticate: Bearer error="insufficient_user_authentication", acr_values="...", max_age=..., e deve verificare acr e auth_time nel token ricevuto.[7]

acr_values è solo una richiesta. Il client (o l’API) deve verificare i claim ricevuti. OIDC Core specifica che il client dovrebbe verificare che il valore acr sia appropriato e controllare auth_time, richiedendo una nuova autenticazione se è trascorso troppo tempo.[6] Se non lo fa, è possibile aggirare lo step-up.

Test black-box con un account di test che ha l’MFA:

  1. Intercetta la richiesta di autorizzazione step-up e rimuovi acr_values / max_age, oppure modifica acr_values impostando un valore più debole (ad esempio, da mfa o urn:...:loa:2 al valore osservato durante il login normale). Completa il login senza MFA e usa il risultato per l’azione sensibile.
  2. Chiama direttamente l’endpoint sensibile usando il token o la sessione del login normale (acr basso, amr senza otp/mfa). La richiesta deve essere rifiutata con una challenge step-up.
  3. Usa un token con auth_time più vecchio del max_age richiesto (effettua il login, attendi e poi prova l’azione).
  4. Dopo uno step-up riuscito (ad esempio, per visualizzare una chiave API), riutilizza la stessa sessione o lo stesso token “elevato” per altre azioni sensibili e per la stessa azione molto tempo dopo. Verifica se lo stato elevato è limitato a una singola azione e ha una scadenza.
  5. Se l’app memorizza il risultato dello step-up in un flag lato client ("mfaVerified": true, cookie elevated=1 o un campo in un token non firmato), modificalo manualmente.

L’applicazione è vulnerabile se l’azione sensibile riesce senza un acr/amr più sicuro o con un auth_time più vecchio del limite consentito. Se un flag di sessione elevata viene riutilizzato per funzioni non correlate, vedi anche riutilizzo dello stato di autorizzazione associato alla sessione.

References

Tip

Impara e fai pratica con AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara e fai pratica con GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara e fai pratica con Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)
Sfoglia il catalogo completo di HackTricks Training.

Supporta HackTricks
Sponsored