In che modo i pentesters si avvicinano all'attacco 2FA (autenticazione a due fattori)?

Il tuo obiettivo come pentester è identificare minacce precedentemente sconosciute o non riconosciute.

Sii estremamente chiaro che tutto ciò che fai qui deve essere esplicitamente autorizzato dal tuo cliente. Se non lo fai puoi metterti nei guai seri. Se ti stai chiedendo informazioni su quello che chiedi nello scambio di stack di leggi .

Attaccare due fattori può essere facile se non è configurato correttamente. In molti casi ci sono meccanismi di ripristino o bypass che ricorrono alle e-mail. Se è configurato correttamente, diventa poco pratico attaccare direttamente e hai bisogno di esaminare le vie di acquisizione dei token o di compromettere direttamente un'applicazione autenticata.

Se il secondo fattore è un token hardware, sarà necessario MitM l'applicazione che sta consumando il token. Se l'applicazione è HTTP o un altro trasporto non criptato, questo può essere ottenuto con l'acquisizione di rete (non proprio MitM ma è necessaria una posizione MitM per eseguire l'acquisizione). Se l'applicazione utilizza TLS con un certificato non valido, è possibile ottenere questo tramite avvelenamento DNS (in attesa di richieste DNS per il dominio di destinazione e invio di numerose risposte DNS con TTL di grandi dimensioni che indirizzano l'utente al MitM con il proprio certificato autofirmato. l'applicazione utilizza HTTPS con certificati validi che potrebbero compromettere un endpoint tramite altre tecniche e acquisire direttamente la voce token sullo user agent. Potrebbe valere la pena di compromettere un'applicazione che consuma il token. Se utilizzano un sistema token TOTP, è possibile compromettere i più deboli dei servizi che utilizzano lo stesso token seriale e quindi riutilizzano il token all'interno della finestra di scadenza.Se utilizzano un sistema token gestito una tantum come Safenet Cryptocard questo non funzionerà poiché il token viene consumato in uso indipendentemente dal timeout. essere quello di catturare il token al primo tentativo, sostituire un valore falso con il vero autenticatore, e side-channel una sessione separata per autenticarsi. pensa di aver fatto un errore di digitazione e di riprovare. Mentre sei in quella posizione, potresti essere in grado di dirottare direttamente i cookie di sessione o altri token direttamente se non vengono utilizzate difese complementari come sessioni bloccate con dispositivi / IP o anti-CSRF.

Se il secondo fattore è già stato fatto tramite e-mail, il vettore di attacco è l'acquisizione di rete di SMTP in entrata sul MX. Questo potrebbe non essere pratico se il cliente utilizza un fornitore in outsourcing sicuro. Dovrebbe essere relativamente facile se eseguono i propri server di posta.

Se il secondo fattore viene eseguito tramite SMS, è possibile che i token di spunta siano fisicamente presenti poiché molti telefoni sono configurati in modo autonatico per mostrare i testi anche se bloccati. Ci sono attacchi più sofisticati che coinvolgono telefoni compromettenti che possono essere usati in altro modo.

L'ingegneria sociale è l'ultimo trucco qui però. Se in qualche modo puoi chiedere a un utente di chiamarti per aiuto proponendo come supporto IT o altrimenti potrebbero semplicemente dirti il token direttamente mentre li "aiuti" a risolvere il problema.

Ricordami questo articolo recente .

_{(Passa il mouse per lo spoiler)}

A phishing attack got him using a domain name similar to Google's with a valid cert.

Altri metodi potrebbero essere:

• Token OTP prevedibili
• MITM in cui non è presente alcuna crittografia o autenticazione per proteggere i dati in transito, quindi l'OTP può essere intercettato e utilizzato dall'hacker.
• Debole crittografia o autenticazione che consente anche quanto sopra.
• Difetti logici nell'implementazione - ad es. consentire un OTP da un altro account utente, consentendo il riutilizzo di OTPs, ecc.
• Punti deboli nei token dei dispositivi affidabili (prevedibilità, perdita, ecc.). Qui è dove si dice che un cookie viene rilasciato sul dispositivo utilizzato per l'autenticazione al fine di contrassegnarlo come un dispositivo attendibile che non ha bisogno del secondo fattore in futuro.
• XSS che consente il recupero del token.
• CSRF che consente di disabilitare l'autenticazione a due fattori.
• Ripristino 2FA (ad es. dispositivo perduto) utilizzando un meccanismo molto meno sicuro (ad esempio, un attacco fisico in cui l'account email è stato registrato e la disattivazione di 2FA implica semplicemente il clic su un collegamento).

2FA è molto più sicuro e quindi più difficile da rompere. Tuttavia ricordo di aver sentito parlare di un metodo in passato per servizi che utilizzavano la verifica SMS come secondo fattore. Se avessi la password e anche il numero di telefono, potresti provare un attacco SE sul provider di telefonia mobile e provare a far sì che l'agente faccia reindirizzamenti dei messaggi al tuo numero. Quindi tutti i codici di verifica SMS andrebbero all'attaccante.