Modelli di attacco informatico per aggirare l’autenticazione a due fattori (o 2FA, Two-Factor Authentication, come d’ora in avanti indicherò nell’articolo) ne esistono da anni, ma alcuni metodi stanno diventando sempre più pervasivi a causa dell’aumento delle organizzazioni che adottano e implementano la 2FA con leggerezza. Sebbene siano svariati i modi attraverso cui un attacker possa tentare di violare un account su cui è stata abilitata la 2FA, il presente post tratta di una tecnica facile da sfruttare, ma difficile da prevenire: i siti di phishing proxy.

I siti di phishing proxy sono versioni più avanzate della tipica pagina di phishing per la raccolta di credenziali, in quanto consentono l’intercettazione dei token di autenticazione. Tali siti sono anche noti come siti Man-in-the-Middle/Machine-in-the-Middle (“MitM“) o Adversary-in-the-Middle (“AitM“) poiché si pongono tra l’utente (vittima) e un servizio apparentemente legittimo ma impersonato dall’attacker.

Esistono diversi kit di phishing disponibili su GitHub, e creati per essere utilizzati da Red Team e penetration tester consentendo di creare i propri siti web da utilizzare in attacchi di phishing proxy: Evilginx2, Modlishka e EvilnoVNC sono tutti kit per effettuare phishing che dispongono di modelli per servizi popolari come Okta®, Microsoft 365® (“M365“), Google Workspace® e altri.

Evilginx2: una panoramica operativa
Si tratta di un framework FOSS per realizzare attacchi phishing. Evilginx2 è scritto nel linguaggio di programmazione Go e viene fornito con vari phishlet integrati per imitare egregiamente le pagine di logon per Citrix, M365, Okta, PayPal, GitHub nonché altri sistemi e ambienti operativi: per ospitare il sito di phishing deve essere configurato utilizzando un’infrastruttura server nonché un dominio personalizzato.

L’attacker acquista un dominio, configura il DNS ed esegue i comandi necessari per strutturare il sito di phishing su di un server, ad esempio con il phishlet O365 integrato: nel periodo di tempo in cui il sito rimarrà attivo e raggiungibile, tutti gli utenti target che visiteranno il collegamento di phishing generato da Evilginx2 saranno accolti da una pagina web graficamente identica alla legittima pagina di accesso Microsoft. I comuni consigli di sicurezza informatica (“best practices”) sostengono che le pagine senza l’icona del lucchetto (la cui presenza indica l’effettiva adozione del protocollo di crittografia TLS tra client e server HTTPS) nella barra delle URL del browser dovrebbero mostrare una bandierina rossa in caso di attività dannose o di problemi con il certificato digitale: ma Evilginx2 a sua volta richiede l’adozione di un certificato TLS da Let’s Encrypt, una Certification Authority gratuita e (per usare un sottile eufemismo) poco attenta ai controlli di Identità, il che significa che le sue comunicazioni sono cifrate con HTTPS, con conseguente possibilità di effettuare phishing anche dei portali che sfruttano tale protocollo: per un utente l’unico modo per distinguere la seguente pagina web da quella di accesso legittima (ossia l’autentica) sarà l’analisi dell’URL o del certificato digitale (questo secondo caso è spesso prerogativa dei soli addetti ai lavori, programmatori, sistemisti o professionisti InfoSec).

Se un utente ignaro inserirà le sue credenziali nella pagina di accesso fraudolenta, il sito di phishing le controllerà con Microsoft per assicurarsi che siano autentiche. Successivamente, all’utente verrà richiesta una normale verifica 2FA attraverso uno qualunque dei metodi abilitati sul proprio account M365. Ad esempio, se l’account della vittima è stato configurato per ricevere SMS e/o telefonate come secondo fattore di autenticazione, la schermata che gli si presenterà potrà essere così:

Se la 2FA viene approvata con successo, alla vittima sembrerà di aver effettuato un accesso con le proprie credenziali. Gli sforzi per accedere a risorse aggiuntive richiederanno un altro accesso poiché l’attacker dovrà ora sganciarsi dal sito ingannevole per accedere al vero workspace on-line della vittima. Gli utenti potrebbero essere avvertiti da una richiesta aggiuntiva di autenticazione o dal fatto che tutto ciò che è stato promesso loro nell’e-mail di phishing non è al momento disponibile, ma molti utenti potrebbero ancora non rendersi conto di essere stati oggetto di phishing.

Dall’altra parte (lato attacker) l’operatore del sito di phishing avvierà il comando sessions dalla propria istanza Evilginx2, potendo così visualizzare tutte le credenziali acquisite, nonché i dettagli su qualsiasi sessione specifica e token associati, similmente al seguente screenshot:

L’attacker ora provvederà a copiare il testo del cookie (visibile nella parte inferiore delle informazioni sulla sessione) importandolo in un browser utilizzando qualsiasi plug-in di modifica dei cookie (come ad esempio EditThisCookie). Quando aggiornerà la pagina di accesso di Microsoft, verrà eseguito l’accesso come utente sottoposto a phishing. Il seguente diagramma mostra ad alto livello il workflow dell’attacco:

Evidenze utili a scopo di Digital Forensics
Sebbene possa essere intricato identificare con certezza l’uso di un sito di phishing che sfrutti proxy malevoli come Evilginx2, esistono modelli su cui periti forensi e analisti InfoSec possono far affidamento per accertare se un attacker ha effettivamente rubato il cookie di un utente attraverso un sito di phishing, tra cui:

• accessi che continuano a essere effettuati da indirizzi IP anomali
• tutte le attività degli attacker avranno lo stesso SessionId, anche se il cookie viene spostato dal server di phishing per essere importato in un browser di un altro sistema
• gli accessi iniziali dal server di phishing appariranno come la stringa dello User Agent legittimo della vittima

Indirizzi IP anomali
In questo scenario è possibile applicare i tipici metodi per identificare compromissioni della posta elettronica. Anche se all’utente sembra che stia accedendo tramite Microsoft, le sue credenziali verranno inviate a Microsoft tramite il sito di phishing, quindi sarà l’indirizzo IP pubblico del phishing server, e non l’IP del device utilizzato dall’utente, che apparirà nei log del primo accesso.

Coerenza dell’ID di sessione
L’indirizzo IP del server di phishing viene tracciato a seguito del primo accesso, ma potrebbe cambiare con la successiva attività loggata. Nei tipici attacchi AitM, l’accesso avviene sul server di phishing ma l’autore dell’attacco poi sposta il cookie su di un’altra macchina, per importarlo in un browser. Poiché il cookie è il medesimo, il SessionId nell’Unified Audit Log (“UAL”) sarà coerente tra gli accessi, anche se proverranno da indirizzi IP e/o User Agent differenti. Per gli eventi riconducibili a UserLoggedIn, nell’UAL è possibile reperire il SessionId sotto la voce “Device Properties”.

Nella griglia l’indirizzo IP del server di phishing è evidenziato in rosso, e termina con .91, mentre l’indirizzo IP del sistema fake gestito dall’attacker è evidenziato in arancione (ha .94 come ultimo ottetto). Gli accessi successivi con l’indirizzo IP .94 si sono verificati quando l’attacker ha importato il cookie catturato dal server di phishing in un browser Chrome, continuando a interagire con l’account della vittima: il SessionId visualizzato in blu è lo stesso durante tutta l’attività di phishing, poiché l’attacker ha riutilizzato il medesimo cookie di autenticazione.

User Agent pattern
In molte indagini riguardanti accessi abusivi alle e-mail, chi si occupa di Digital Forensics può rilevare l’attività criminosa seguendo le tracce dello User Agent, che è una stringa che identifica il tipo di dispositivo e il client utilizzati per accedere all’account. Generalmente l’utente legittimo avrà uno User Agent diverso da quello dell’attacker poiché quest’ultimo accede dalla propria infrastruttura. Tuttavia, Evilginx2 è in grado di acquisire la stringa dello User Agent della vittima, dando così la possibilità all’attacker di clonare l’User Agent dell’utente legittimo: questo significa che sebbene il sito di phishing possa essere eseguito su un sistema Linux, se la vittima fa click sul collegamento utilizzando Firefox su un computer Windows 10, lo User Agent che sarà tracciato nei file di log risulterà identico a quello originale della vittima. Nei log UAL mostrati nella griglia, ad esempio, la finta vittima durante i test ha effettuato l’accesso al sito di phishing utilizzando Windows 10 e il browser Opera, lo stesso User Agent che viene rilevato negli accessi iniziali originati dall’indirizzo IP del server di phishing.

Questo tentativo di fondersi con accessi legittimi nei log di autenticazione ha implicazioni sostanziali per gli investigatori: senza uno User Agent anomalo, l’unico chiaro indicatore di compromissione nell’evento di accesso è l’indirizzo IP difforme. In uno scenario in cui l’attacker dovesse impiegare una botnet o un’altra infrastruttura appartenente a ISP aziendali, il rilevamento di questa attività diventerebbe molto complicata.

Nella seconda fase dell’attacco, una volta catturati i cookie, il phisher provvederà a importarli nel suo browser: il truffatore potrà visualizzare lo User Agent dalla sessione catturata all’interno di Evilginx2, e clonarlo all’interno del proprio browser in modo da non destare sospetti.

Tecniche di Prevenzione

Autenticazione FIDO2
I meccanismi di autenticazione basati su hardware che sfruttano i protocolli FIDO2 attualmente sembrano essere il miglior modo per mitigare il rischio che un attacker eluda la 2FA in una qualunque delle sue forme. L’autenticazione FIDO2 utilizza chiavi crittografiche preregistrate (con un servizio come Microsoft 365) per consentire all’utente di autenticarsi su quel sito: la sfida presentata al dispositivo FIDO2 dal servizio include dettagli sull’origine della richiesta (come l’URI del sito) ed é per questo che i tentativi di autenticazione a un sito di phishing fraudolento utilizzando questi protocolli falliscono miseramente. Esempi di autenticazione FIDO2 includono token hardware come Yubikeys o una soluzione integrata nel laptop utente come Windows Hello.

Tuttavia, laddóve sono disponibili anche metodi di autenticazione alternativi, esiste il rischio di attacchi di downgrade all’autenticazione FIDO2: ad esempio, un’organizzazione può aver impostato l’autenticazione FIDO2 come metodo principale, ma in alternativa potrebbe anche consentire l’invio di password monouso (OTP) tramite SMS o e-mail. Oltre a questo rischio, ci sono ragioni logistiche per cui l’autenticazione FIDO2 può essere difficile da implementare, infatti, il suo utilizzo costituisce un cambiamento strutturale per la maggior parte degli utenti e in molti casi comporta costi aggiuntivi per le organizzazioni che allo stato attuale utilizzano standard di autenticazione vetusti.

Circoscrivere gli accessi
Le organizzazioni che continuano a utilizzare notifiche push, telefonate o SMS come secondo fattore di autenticazione dovrebbero prendere in considerazione l’utilizzo di un approccio di sicurezza informatica a più livelli che includa anche la limitazione degli accessi esterni agli account utente: questo scenario generalmente viene implementato consentendo l’accesso remoto solo da indirizzi IP approvati, come il range degli indirizzi IP delle VPN aziendali, ma soprattutto richiedendo che i dispositivi di autenticazione siano gestiti dall’organizzazione attraverso l’utilizzo di PKI, certificati digitali e architetture di rete basate sullo standard Zero Trust: tali controlli e modelli architetturali costituiscono misure di Cybersecurity efficaci e drastiche in grado di rendere estremamente difficile la vita alle cybergang.

Protocolli di sicurezza su più livelli
Ulteriori tecniche che aiutano a ridurre al minimo il rischio che questo attacco vada a segno già nelle sue fasi iniziali includono l’utilizzo di filtri antispam (utilizzando i filtri incorporati nella piattaforma di posta elettronica aziendale piuttosto che (ancora meglio) quelli disponibili in un’appliance di terze parti) e di proxy web per filtrare il traffico HTTP/HTTPS degli utenti. Attraverso l’uso dei proxy, agli utenti può essere facilmente impedito di visitare siti di phishing noti o altri portali appartenenti a categorie rischiose per la postazione stessa dell’utente ma soprattutto per la rete informatica dell’organizzazione. Un altro fattore chiave è la formazione in ambito Cybersecurity, in particolare sul tema Phishing: istruire dipendenti, manager e consulenti esterni dell’organizzazione a identificare email palesemente contraffatte o pericolose attraverso “campagne di Phishing” a sorpresa, volte a scoprire chi in azienda non è ancora in grado di distinguere un’email autentica da un tentativo di Phishing, è fondamentale, aggiungerei doveroso per un reale progresso della Cybersecurity Posture.

Sebbene la riduzione della durata dei token non impedisca completamente la possibilità di un accesso abusivo agli account target, limita concretamente l’impatto complessivo sull’organizzazione, riducendo al minimo il tempo che un attacker avrà a disposizione per raggiungere i suoi obiettivi fraudolenti. Nello specifico di M365, i Sysadmin possono modificare la durata della sessione: l’accesso condizionato può infatti essere configurato anche per particolari gruppi di utenti, come gli amministratori. Il reset delle password in M365 invaliderà i vecchi token persistenti, costituendo quindi un’efficace deterrente per gli account che hanno subìto questo attacco.

Considerazioni conclusive
La Cybersecurity è in continua evoluzione e le capacità degli attacker di eludere la 2FA non sono una novità. I furti di sessione e gli attacchi AitM esistono da anni, ma con il crescente numero di organizzazioni che stanno adottando la 2FA come linea difensiva, gli attacker stanno a loro volta raffinando le tecniche per effettuare accessi abusivi negli account delle vittime. Tali attacchi costituiscono una minaccia non solo per i classici sistemi e servizi di posta elettronica aziendale (BEC), poiché anche altri servizi come Okta, Citrix ecc.. sono potenzialmente a rischio della medesima minaccia. La compromissione di questi account può avere come conseguenza la violazione della rete dell’organizzazione su vasta scala, culminando nella distribuzione a tappeto di ransomware, nel furto e/o nell’esfiltrazione di dati, nonché, dulcis in fundo, nell’installazione di kit APT per un futuro riutilizzo o rivendita delle backdoor impiantate nella rete del target, ovviamente a totale insaputa dell’organizzazione.

Gli attacker possono potenzialmente aggirare la 2FA anche senza possedere le competenze tecniche necessarie per creare un sito di phishing proxy. Servizi di Phishing-as-a-Service si noleggiano per circa duecento euro al mese, una cifra irrisoria rispetto a quanto può guadagnare illecitamente un truffatore da un singolo bonifico bancario reindirizzato. Scenario ancora più facile per l’attacker è quello in cui l’utente target (o potremmo dire utOnto in questo caso!) disgraziatamente accetti notifiche push sul proprio smartphone anche quando non ha avviato di sua iniziativa il logon su di un portale web: sebbene la 2FA sia uno strumento indispensabile e non negoziabile nel mondo della Cybersecurity, non costituisce una soluzione definitiva. Perduto e perso chi crede fermamente il contrario.

Articoli di approfondimento:
Link1
Link2
Link3