Quel bonifico non sa(veva) da fare: attacco MiTM

Come ogni anno arriva il periodo delle ferie, e come ogni anno dietro l’angolo, ecco materializzarsi il pericolo di incappare in attacchi di tipi BEC (Business E-Mail Compromise) o Man in the Mail.

Si tratta di attività di manipolazione di messaggi di posta elettronica, tramite connessione IMAP, atti a persuadere i destinatari ad eseguire determinate operazioni, in modo inconsapevole (es. Bonifico su un IBAN diverso da quello originale).

Siamo in vacanza e ci siamo ricordati di aver in sospeso qualche pagamento, o di aver modificato dei dati bancari, e siccome siamo al mare utilizziamo la mail per comunicare con i nostri collaboratori che invece sono in ufficio. Tutto è molto rilassato, e quando scende la tensione, ecco che “casca anche l’asino”!

Ma è davvero così semplice eseguire questo tipo di attacco? E sopratutto, caderci?
Partiamo dal principio con un assioma incalpestabile : per eseguire questo tipo di attacco bisogna prima compromettere la casella di posta (o il server) bersaglio.


Si, perchè questo attacco prevede la configurazione dell’account di posta elettronica bersaglio tramite protocollo IMAP, quindi si deve essere se non altro in possesso delle credenziali (vedremo in altre trattazioni quali sono i principali metodi di ottenimento), di conseguenza siamo già in una fase di data-breach in cui l’azienda è già stata colpita.

Per cui, dato per svolto lo step della compromissione, il passo successivo per l’attaccante prevede la confiugrazione della mail su un client di posta open-source (Mozilla Thunderbird) e successivamente resta in “ascolto” aspettando che si presenti l’occasione per colpire.

Operativamente, si attende che arrivi la mail di cui si parlava sopra, quella che riguarda una pagamento, una fattura da saldare o qualcosa di simile, una volta individuata la mail, è tutto molto semplice : tramite l’opzione “Salva come…” è possibile salvare una copia del messaggio di posta elettronica in formato EML, e successivamente la modifica è fattibile con un qualsiasi editor come Notepad++. Sarà possibile alterare qualsiasi parte del messaggio, data, ora , mittente e destinatario, oggetto e contenuto della mail.

Terzo step, una volta ottenuto il messaggio con la dovuta manipolazione, consiste nel riposizionare il nuovo messaggio sul server andando ad eliminare l’orginale, in tale maniera nessuno potrà accorgersi di nulla e a sistema risulterà la mail manipolata. Questo è fattibile sempre tramite Thunderbird, dal proprio PC esiste la voce Messaggio–> Copia in –> [Nome dell’account IMAP] scegliendo poi se lo si vuole caricare nella posta in Arrivo o in quella Inviate.

Portato a termine questo passo, a tutti gli effetti, abbiamo nel nostro account bersaglio, un messaggio di posta che non è mai esistito , il cui contenuto è stato scelto da noi. Se l’attaccante è particolarmente bravo e andrà ad utilizzare header RFC822 coerenti con l’account bersaglio (basta prenderli da un messaggio già esistente), anche un utente smaliziato non noterà alcuna differenza tra il messaggio farlocco e qualsiasi altro messaggio orginale.

Qui la frittata è già stata fatta, che si tratti del pagamento di una multa o di una commessa milionaria, sarà elevatissima la probabilità che l’utente bersaglio cada nel tranello.

Ma quindi come è possibile capire ?

La figura del consulente informatico forense, in casi come questo, arriva sempre a posteriori, se si fa ricorso alla perizia è per individuare la causa del danno e provare a risalire a chi ha operato, quindi diciamo che non è un vero e proprio modo per accorgersi della compromissione, ma un analisi per verificare a quale livello è stato eseguito il data-breach.

Le manipolazioni, come detto, non lasciano tracce a livello RFC822 ma ne lasciano a livello di metadati IMAP, è possibile quindi verificarne l’integrità redigendo una perizia forense di una analisi investigativa.

Una delle prime verifiche possibili è quella di accertare l’intergrità della firma DKIM che solitamente viene apposta automaticamente dai provider di servizio. La verifica della firma DKIM si può fare sia sulla webmail (ad es. Gmail mostra il messaggio “firmato da: gmail.com” per i messaggi la cui firma viene verificata) oppure tramite plugin come DKIM Verifier, che aggiungono una riga alle instestazioni della mail che si vedono a schermo che riporta se la firma è valida oppure invalida, precisando in tal caso che “la mail è stata modificata”. Questa verifica ovviamente è fattibile nei casi in cui il server del mittente appone firma DKIM ai messaggi di posta uscenti.

Andando ai controlli prettamente realtivi all’IMAP, abbiamo almeno due possibilità.
La prima riguarda la verifica del campo “Order Received” (ordine ricezione), nello specifico andranno verificati i campi Order Received della mail oggetto di analisi, e delle mail precedente e successiva.
Questo perchè il campo in questione non è presente nel messaggio scaricato in formato RFC822 EML/MSG perchè viene comunicato dal protocollo IMAP nel momento in cui il client accede al messaggio, è un numero ordinale ed univoco, ed in un esempio ideale dovrebbe essere direttamente seguente al numero del messaggio precedente, e direttamente precedente al numero del messaggio successivo.
Se tale verifica da esito positivo, quindi viene “saltato” un numero (o piu) , allora è indice che permette di ipotizzare una modifica postuma, fatta al messaggio, via IMAP.
Considerando che queta non è una pratica comune agli utilizzatori base, già di per se è indice di compromissione.

Ulteriore controllo fattibile, avendo accesso al server, è quello della verifica dell’integrità del campo “Internal Date”, che contiene la data del momento in cui il messaggio di posta oggetto di analisi è stato inviato o ricevuto dal server.
Anche in questo caso, se un messaggio del 25 Luglio viene modificato il 29 Luglio, il suo Internal Date passerà al 29 Luglio, cosa che non ha senso se la data d’invio o ricezione della mail rimane 25 Luglio.

La verifica di questo paramentro tuttavia è più complicata e richiede il ricorso a soluzioni open source o a prodotti commerciali di cui parlerò in un secondo momento, dando la giusta profondità all’argomento.

A questo punto, l’analista forense, avendo in mano la verifica della firma DKIM, le internal date e valutato l’ordine dei messaggi tramite l’IMAP UID (order received) può valutare l’effettiva presenza di manipolazioni nei messaggi di posta elettronica.

Come al solito ci tengo a precisare che articoli come questo non vogliono essere dei tutorial per insegnare attacchi informatici, ma vogliono alzare la guardia evidenziando talvolta la semplicità con la quale tali azioni vengono eseguite, portando a serie conseguenze a livello aziendale.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *