E’ stato pubblicato oggi su Youtube il video del mio workshop del 30 maggio per l’HackInBo Safe Edition, durante il quale ho mostrato come – in ambito di attacchi di tipo Business Email Compromise o Man in The Mail – possono avvenire delle manipolazioni con sostituzione degli allegati di posta tramite connessione IMAP, finalizzati a persuadere il destinatario a emettere bonifici su conti IBAN fraudolenti. Fortunatamente, tramite tecniche di email forensics e strumenti open source come Thunderbird (eventualmente con l’ausilio di alcuni plugin), Notepad++, Curl e una conoscenza specifica di alcuni aspetti del protocollo IMAP queste manipolazioni possono essere rilevate e identificate con precisione dal consulente informatico forense, al fine di produrre una perizia informatica sulle manipolazioni delle caselle di posta e sui messaggi di posta elettronica, anche PEC.

Nel video girato durante la giornata di HackInBo Safe Edition pubblicato su Youtube si può seguire in dettaglio l’ora di workshop e, volendo, anche riprodurne le attività tecniche simulando un’azione di di falsificazione di messaggi e allegati di posta con successiva perizia informatica di analisi forense tramite analisi del sorgente RFC 822, princìpi del protocollo IMAP e firme DKIM, predisponendo quanto segue:

1. Mozilla Thunderbird (client di posta elettronica, preferibile in versione portable);
2. DKIM Verifier (estensione per Thunderbird che permette di verificare firme DKIM);
3. Notepad++ (editor di testi versatile e open source)
4. CURL (strumento per scaricare risorse da diversi protocolli internet, incluso IMAP)
5. mpack/munpack (tool per estrarre o inserire manualmente allegati da un messaggio di posta elettronica)
6. openssl (software utile per convertire gli allegati ai messaggi di posta da e verso codifica base64)
7. un paio di account di posta elettronica che supportino il protocollo IMAP, come ad esempio GMail

Buona parte degli strumenti elencati sopra sono utilizzabili su distribuzioni Linux – come ad esempio Tsurugi Linux – ma anche su Windows (tramite binari compilati in Win32/64 oppure tramite WSL) o ancora su Mac OS (mediante homebrew/macports). Si consideri che le valutazioni esposte durante il workshop sono pienamente applicabili anche alla verifica di manipolazioni e originalità di messaggi di posta elettronica certificata PEC.

Il workshop si apre con un esempio di manipolazione e falsificazione di messaggi di posta elettronica, con il fine di cambiarne contenuti o sostituirne l’allegato. La particolarità è che l’alterazione fraudolenta non avviene soltanto su una copia sul PC del messaggio di posta, ma va a modificare il messaggio originale presente sul server di posta elettronica, in modo tale che anche accedendo alla webmail o scaricando la posta da un’altra postazione, si ottenga il messaggio manipolato e non più quello originale. Questo è, tra l’altro, esattamente ciò che avviene durante alcuni tipi di attacco Man in The Mail o Business Email Compromise (MiTM/BEC) durante il quale la vittima non si accorge che l’allegato su cui è indicato l’IBAN del conto bancario verso cui disporre il bonifico di pagamento della fattura del fornitore è stato modificato.

La manipolazione dell’email o PEC avviene in modo piuttosto semplice: si salva il messaggio in locale tramite la funzione di “Salva come…” di Thunderbird che permette di salvare il messaggio di posta elettronica in formato EML, che poi non è altro che un file di testo. Per fare una manipolazione del testo di un messaggio di posta elettronica o alterare in maniera fraudolenta elementi come data, ora, mittente, destinatario, oggetto, etc… è sufficiente aprire il file con un editor come Notepad++ e cambiare le parti che si desidera alterare, salvando successivamente il file. Aprendo il file EML su Thunderbird (è sufficiente cliccare due volte sul nome del file) si nota già che le alterazioni sono state applicate, ovviamente soltanto in locale sul PC e non sul server.

È leggermente più complicato fare una modifica fraudolenta all’allegato di un messaggio di posta elettronica, perché è necessario identificare il punto del file EML in cui si trova (è sufficiente aprire il file con un editor) e sostituirlo con il nuovo allegato, codificato in base64. La codifica del nuovo allegato (quello che, nel caso di attacchi BEC, contiene l’IBAN del conto bancario dei criminali) si può fare sia tramite comando openssl, sia creando una nuova mail con il comando mpack e copiando poi soltanto la parte con l’allegato nel messaggio di posta che vogliamo manipolare. Per sostituire un allegato/attachment di posta elettronica il criminale può quindi quindi procedere come segue, tramite il comando openssl che converte in base64 il nuovo PDF oppure tramite il tool mpack che crea un nuovo messaggio di posta dentro il quale viene allegato il PDF fraudolento, che poi si andrà a copiare e incollare nel nuovo messaggio EML.

Una volta ottenuto il messaggio con testo e/o allegato manipolato, il passo successivo che fanno i delinquenti è quello di riposizionare il nuovo messaggio sul server di posta eliminando quello originale, in modo chi dovesse scaricare l’email o accedere alla casella di posta non si accorga di nulla. Questa operazione è fattibile, sempre con Thunderbird, con un passaggio strategico che consiste nel cancellare il messaggio originale, aprire il messaggio fraudolento presente sul PC e posizionarsi sul menù di Thunderbird alla voce “Messaggio -> Copia in -> [account di posta configurato in IMAP] -> Posta in arrivo“. In questo modo, il messaggio di posta manipolato andrà a sostituire quello originale anche da parte di chi accede via webmail, perché la modifica è avvenuta sul server. La cosa rilevante è che il caricamento di un messaggio di posta sul server può essere fatto sia nella Inbox, contenente la Posta in Arrivo, ma anche nella Outbox, cioè nella cartella della Posta Inviata.

Un malintenzionato può quindi sostituire il contenuto di un messaggio o del suo allegato sia nella posta inviata sia in quella ricevuta, ma allo stesso modo può creare un messaggio e posizionarlo in posta inviata anche se tale email non è mai esistita, allo stesso modo in cui può creare una mail e posizionarla in posta ricevuta quando in realtà non è mai stata ricevuta. Da un’analisi della casella di posta, entrambi i messaggi sembrerebbero del tutto originali e integri, in particolare se il malintenzionato facesse attenzione a utilizzare header RFC822 coerenti (prendendoli, ad esempio, da messaggi realmente esistenti e se possibile inviati o ricevuti dallo stesso soggetto dell’email manipolata).

Si noti che in alcuni casi, la cancellazione via client di posta non è effettiva ma tiene in cache la mail che può poi essere ripristinata dalla mailbox anche se ne andiamo a ricaricare una leggermente diversa: si consiglia quindi di eliminare il messaggio tramite webmail oppure accertarsi che la cancellazione via IMAP abbia avuto effetto. Nel video si vede che dopo la cancellazione via IMAP e il caricamento del messaggio di posta manipolato, tramite la webmail viene mostrato ancora il vecchio messaggio originale, che invece viene sostituito da quello nuovo se la cancellazione avviene direttamente all’interno della webmail.

Questa sostituzione chiaramente si può applicare anche a messaggi di posta inviati, alterandone quindi il destinatario, contenuto, allegati, oggetto e facendo credere a chi dovesse accedere alla mailbox sul server che la mail sia originale e così sia stata inviata.

Importante sottolineare che, dal punto di vista del sorgente RFC822, cioè della costruzione del messaggio in termini d’intestazione (header), corpo (body) e allegati (attachment) una email così manipolata non è facilmente distinguibile ad una originale anzi, spesso non presenta differenze rispetto a una mail originale e quindi una perizia informatica potrebbe attestare la validità del messaggio quando in realtà si tratta di un’email falsificata e manipolata.

A questo punto, entra in gioco il consulente informatico forense, che viene chiamato per redigere una perizia informatica a seguito di analisi tecnica della mailbox, così da accertare la presenza di manipolazioni o alterazioni o, al contrario, l’integrità e originalità del messaggio di posta elettronica. La seconda fase del video è proprio relativa all’attività di verifica delle manipolazioni dei messaggi di posta elettronica ordinaria (PEO) tramite l’utilizzo di strumentazione open source e metodologie basate sui princìpi del protocollo IMAP.

Fortunatamente, le manipolazioni ai messaggi di posta elettronica possono non lasciare tracce a livello RFC822 ma ne lasciano quasi sempre a livello di metadati IMAP, permettendo quindi al perito informatico di analizzare diversi elementi per accertare l’integrità o meno della corrispondenza, sia essa via posta elettronica tradizionale o PEC, redigendo una perizia informatica forense di acquisizione forense e analisi investigativa.

Innanzitutto, una verifica che il consulente informatico forense può fare durante la sua indagine digitale è quella di accertare l’integrità della firma DKIM, che viene apposta in automatico ad esempio da parte della casella di posta Gmail. 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.

Passando invece al protocollo IMAP, le verifiche che possiamo fare sono almeno due. Il primo è il controllo del campo “ordine ricezione” (“order received”) della mail oggetto di verifica confrontando il numero con il messaggio prima e quello dopo. Tale campo – non presente nel messaggio che viene scaricato in formato RFC822 EML o MSG – viene comunicato dal protocollo IMAP quando il client accede al messaggio ed è un numero ordinale che viene attribuito dal server a ogni messaggio, in genere univoco per cartella. La inbox avrà così un messaggio con Order Received (talvolta definito anche IMAP UID) 341, il messaggio successivo sarà 342, poi 343, 344 e così via. Se il messaggio con UID 342 a un certo punto viene alterato, cambia il codice e ne assume uno nuovo “saltando” quindi in avanti e superando quelli arrivati dopo di lui. Un’analisi della linearità dei numeri IMAP UID quindi permette già in diversi casi di rilevare una modifica postuma a un messaggio, fatta anche a livello server tramite caricamento dei file via IMAP.

Ulteriore controllo che l’informatico forense può fare, avendo accesso al server, è quello della verifica dell’integrità del campo INTERNAL DATE, che contiene la data marchiata dal server nel momento in cui il messaggio di posta oggetto di analisi è stato inviato o ricevuto dal server, in sostanza quando è stato salvato su disco. Anche in questo caso, se un messaggio del 30 maggio viene modificato il 3 giugno, il suo INTERNAL DATE passerà al 3 giugno, cosa che non ha senso se la data d’invio o ricezione della mail rimane 30 maggio.

L’accesso al dato INTERNALDATE è più complicato perché Thunderbird non lo mostra, per quanto ci siano dei plugin che sembrano poterlo fare ma non funzionano correttamente. Bisogna quindi ricorrere a soluzioni open source o a prodotti commerciali come FEC (Forensic Email Collector), SecurCube Downloader, F-Response o simili.

Avendo a disposizione software open source, possiamo sviluppare qualche linea di codice in python che vada a utilizzare la libreria imaplib chiamando il comando “fetch(message, ‘(INTERNALDATE)’” oppure più semplicemente sfruttare la potenzialità del comando cURL, utilizzato in genere per scaricare pagine web o file da Internet.

Con gli opportuni parametri, il comando cURL può essere utilizzato per accedere tramite protocollo IMAP o IMAPS a server di posta elettronica e scaricare messaggi di posta, intere mailbox o più semplicemente i metadati IMAP che altrimenti sarebbe difficile ottenere. Con una sola riga, riusciamo quindi a ottenere diversi parametri legati a tutte le email presenti nella Inbox della casella di posta [email protected], utilizzata per i test durante il workshop.

curl –insecure –url “imaps://imap.gmail.com/INBOX” –user “[email protected]” –request “fetch 1:* (UID FLAGS INTERNALDATE ENVELOPE)”

Lanciando questo comando in pochi decimi di secondo si ottengono i metadati IMAP InternalDate, UID (order received) oltre ai FLAGS come “Seen” (che indica se un messaggio di posta è stato letto oppure no), se è JUNK (marchiato come “spam”), data d’invio scritta nell’ENVELOPE (quindi impostata dal client) e altri parametri utili per l’analisi. In questo caso, è strategico verificare se il campo Internal Date è coerente con la data d’invio oppure se di discosta di molto, incrociando eventuali anomalie con il raffronto degli UID (o “order received”).

Il comando cURL può essere personalizzato con diversi parametri, ad esempio è possibile estrarre il solo campo IMAP InternalDate dal messaggio con UID 9 nella mailbox “safedition” della casella Gmail nel folder INBOX, con password “password123” (se viene omessa la password da linea di comando, viene chiesta in tempo reale durante l’avvio del tool).

curl –insecure –url “imaps://imap.gmail.com/INBOX” –user “[email protected]:password123” –request “fetch 9 INTERNALDATE”

Una volta raccolti tutti questi dati, esaminato il file RFC822, valutate l’ordine dei messaggi “ORDER RECEIVED” o IMAP UID, verificate le date INTERNALDATE, verificata la firma DKIM, etc… il consulente informatico forense potrà valutare l’integrità delle mail, l’assenza o presenza di manipolazioni, eventuali anomalie nelle mailbox e nei messsaggi di posta elettronica.

Ricordiamo, a completamento dell’articolo, che i provider di posta elettronica sono in grado di fornire – su richiesta da parte dell’Autorità Giudiziaria e raramente da parte dei Legali – ulteriori dati a supporto delle indagini informatiche forensi. Ad esempio, i provider mantengono per un anno di tempo i log di utilizzo della casella di posta elettronica , memorizzando i metadati (non ovviamente i contenuti) dei messaggi inviati e ricevuti, cioè mittente, destinatario, data d’invio/ricezione, oggetto, dimensione messaggio talvolta integrati con ulteriori elementi come server SMTP utilizzato, IP di provenienza o altri dati tecnici.

Per quanto riguarda invece le attività dell’utente sulla casella di posta – utili spesso per rilevare accessi non autorizzati, manipolazioni ai messaggi, apertura di email, cancellazione e rimozione di mail, modifica di allegati altre attività non autorizzate è disponibile presso buona parte dei provider una sezione di storico degli accessi, che permette di visionare i dettagli degli ultimi accessi, in termini di numero di accessi o di giorni/settimane/mesi di storico. Tali dettagli spesso arrivano anche a informazioni tecniche sui browser utilizzati, gli indirizzi IP e il tipo di operazione eseguito dall’utente (es. cambio password, aggiunta numero di telefono di sicurezza, etc…).

Con maggiore difficoltà è possibile anche ottenere dal provider (se ne mantiene copia e se la fornisce al proprietario, al suo legale o soltanto all’Autorità Giudiziaria) anche lo storico delle attività eseguite tramite webmail, IMAP o POP, potendo così ricostruire attività di accesso e operazioni di falsificaizione, manipolazione, aggiunta o cancellazione eseguite sulle singole email da interfaccia web o tramite i protocolli IMAP o POP.