Il phishing si evolve: con l’Adversary in the Middle si aggira anche il token 2FA
La settimana scorsa, Microsoft dava notizia e analisi approfondiita di una campagna di phishing evoluta, disegnata con attenzione per evadere anche la protezione data da multi-factor authentication (MFA o 2FA), il che la rende particolarmente degna di nota ed è un passo avanti rispetto a ciò che tipicamente si immagina quando si parla di phishing, parola che ci ha abituati a pensare a mail palesemente false piene di errori oppure al solito Principe nigeriano di turno.
Giusto per dare un po’ di contesto: quante volte abbiamo sentito o letto dell’autenticazione a due fattori come elemento chiave per la sicurezza, in ogni contesto che va dal nostro account Instagram fino alle realtà aziendali?
Stiamo parlando di ciò che, forse, suona più familiare come token, sia esso in forma di chiavetta hardware o in forma di app da installare sullo smartphone. Vi sono diversi sistemi molto simili tra loro ma l’obiettivo è sempre lo stesso: il login a un account avviene non solo tramite qualcosa che si conosce (la password) ma gli accessi vanno confermati ogni volta da qualcosa che si ha con sè (il token, in forma di notifica app o di codice su un dispositivo portatile).
Ebbene, nonostante il suggerimento di implementare tale meccanismo sia sempreverde, decisamente una buona idea e preferibile al non averlo affatto, è bene sempre ricordare che gli assoluti non esistono in cybersecurity e che, anche stavolta, è bene implementare i mezzi di protezione esistenti avendo ben presente che nessuno di loro è infallibile al 100%.
Il 2FA sembrava la soluzione finale e definitiva, quindi, in quanto anche rivelando username e password a terze parti, queste non potrebbero comunque accedere al vostro account finchè non confermerete voi l’accesso dalla vostra app o token fisico, ma vediamo subito quali sono i suoi limiti.
L’attacco in questione, battezzato Adversary in the middle (AiTM), è abbastanza semplice concettualmente: consiste nel piazzare un proxy tra la persona che si loggherà all’account e i server di destinazione e la persona obiettivo verrà indirizzata a interagire, come consueto per un attacco di phishing, con la pagina di login fasulla.
Immaginiamo di essere noi l’obiettivo: ci troviamo sulla pagina che crediamo sia quella legittima e inseriamo normalmente i nostri username e password sulla pagina di login che abbiamo davanti, che è quella malevola ma ha l’apparenza tale e quale di quella vera, fino all’ultimo pixel.
Username e password verranno quindi inviati dalla pagina malevola al server vero (per esempio outlook.com) il quale manderà la richiesta 2FA come previsto sul nostro telefono, che noi, non avendo notato niente di strano, confermeremo (poco cambia se si tratta di un codice, invece, da inserire).
A questo punto, il codice (o la conferma) arriveranno anche al server vero, il quale ci invia un session cookie, ovvero un file che contiene la nostra autorizzazione appena fornita, che verrà salvato dal nostro browser e permetterà al server di ‘tenere traccia’ del fatto che ci siamo appena loggati per evitare di doverlo fare ripetutamente a ogni cambio e refresh di pagina.
Per tutto il tempo, come notato sopra, c’era tra noi e il server vero un proxy malevolo che ha intercettato tutto il traffico, incluso il session cookie, che può ora essere utilizzato da chi ha posto in essere l’attacco per utilizzare il nostro account come se fossimo noi a farlo.
Un attacco semplice, che però è stato utilizzato per accedere a mail aziendali e chiedere versamenti di denaro a clienti o fornitori, agganciandosi a thread mail esistenti e, quindi, risultando abbastanza credibili. Inutile dire che tali versamenti non sarebbero finiti nelle tasche giuste. Il potenziale danno aziendale derivante da questo genere di attacchi, avendo accesso alle mail, è enorme, specie se si fa affidamento al 100% all’idea che ogni mail è protetta da MFA.
Attacchi del genere non funzionano se il session cookie è associato a un dispositivo specifico ma, essendo questo generato dal backend del sito web su cui ci stiamo loggando, non è solitamente un fattore che possiamo controllare noi. Anche stavolta, seppur scontato e, forse, non il tipo di suggerimento che volevate, la protezione migliore è a monte, ovvero nel non finire proprio sulla pagina malevola, perchè come abbiamo visto il 2FA non sempre è in grado di salvarci
Se vuoi sostenerci, puoi farlo acquistando qualsiasi cosa dai diversi link di affiliazione che abbiamo nel nostro sito o partendo da qui oppure alcune di queste distribuzioni GNU/Linux che sono disponibili sul nostro negozio online, quelle mancanti possono essere comunque richieste, e su cui trovi anche PC, NAS e il ns ServerOne. Se ti senti generoso, puoi anche donarmi solo 1€ o più se vuoi con PayPal e aiutarmi a continuare a pubblicare più contenuti come questo. Grazie!
Hai dubbi o problemi? Ti aiutiamo noi!
Se vuoi rimanere sempre aggiornato, iscriviti al nostro canale Telegram.Se vuoi ricevere supporto per qualsiasi dubbio o problema, iscriviti alla nostra community Facebook o gruppo Telegram.
Cosa ne pensi? Fateci sapere i vostri pensieri nei commenti qui sotto.
Ti piace quello che leggi? Per favore condividilo con gli altri.
![[GUIDA] Linux: come effettuare il logout automatico per inattività](https://www.lffl.org/wp-content/uploads/2021/09/linux-logout-automatico.png "[GUIDA] Linux: come effettuare il logout automatico per inattività 3")
