Michele Pinassi“Le società sono sempre state modellate più dal tipo dei media con cui gli uomini comunicano
che dal contenuto della comunicazione.”
Marshall McLuhan
Al direttore di una importante delegazione corporativa a Bruxelles arriva una mail dal Direttore Generale con la richiesta urgente di effettuare un bonifico da 500.000€ sul conto corrente indicato. E il direttore, senza ciglio battere, esegue. Ignaro che il mittente reale non è il Direttore Generale ed il conto corrente indicato sembra avere una intestazione ignota.
Che sia stata una geniale truffa o una tragica fregatura, rimane il fatto che non possiamo fidarci delle e-mail che riceviamo. O, almeno, non sempre. Questo perché il protocollo SMTP, definito nell’RFC5351, non è progettato per certificare l’identità del mittente ma semplicemente per trasferire un contenuto (e-mail) dal mittente alla destinazione indicata.
Ok, detta così può essere difficile da capire. Vediamo quindi di fare chiarezza su cosa è una e-mail e di come funziona.
Partiamo dall’indirizzo e-mail, che è composto da un nome utente e dal provider del servizio. Ad esempio, o-zone@zerozone.it rappresenta l’utente “o-zone” sul provider “zerozone.it“. Quando inviamo una e-mail a questo indirizzo, il nostro server SMTP effettuerà una query DNS su zerozone.it per capire chi è l’MX (Mail eXchanger) collegato. Possiamo vedere questi dati grazie al comando ‘dig’ (oppure con uno dei tanti tools online disponibili):
~ $ dig MX zerozone.it ;; ANSWER SECTION: zerozone.it. 86392 IN MX 10 mx.mailserver.it.
che ci mostra come il server di posta elettronica che si prende carico delle email inviate a zerozone.it è mx.mailserver.it. A questo punto il nostro server si collegherà all’host mx.mailserver.it, porta TCP 25, ed attraverso una serie di comandi definiti nel protocollo SMTP, invierà il messaggio di testo contenente la nostra e-mail al destinatario.
Ricapitolando, quando inviamo una mail dal nostro MUA (Mail User Agent, che può essere Thunderbird, Outlook, Eudora…) , essa sarà inviata al server di posta in uscita (MTA – Mail Transport Agent) che si prende in carico il messaggio (immaginiamolo come fosse un ufficio postale) e lo consegna all’ufficio postale di destinazione, in attesa che il destinatario ritiri la lettera (quello che succede ogni volta che controlliamo se abbiamo nuova posta).
A questo punto, per capire il nodo della questione, vediamo cosa è una e-mail. Oltre al testo ed agli eventuali altri contenuti multimediali (immagini, video, audio…) che vi alleghiamo, una e-mail è composta prima di tutto da un header che definisce alcuni parametri essenziali, come il mittente, il destinatario, la data di spedizione e tutti i “salti” di MTA che la mail compie, oltre agli indirizzi IP degli host coinvolti:
nell’header di una e-mail si può leggere chi, o da dove, abbia realmente inviato la mail e quale percorso abbia fatto, oltre che altri interessanti dati come l’MTA usato, la data e l’ora di invio e quella di effettiva ricezione da parte del server di posta di destinazione. Tali campi sono definiti nell’RFC2045 (Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies) ed i più importanti per capire se la mail è vera oppure no sono i vari Received che indicano i servers di posta coinvolti nella trasmissione.
La chiave del problema è tutta nel protocollo SMTP e nei servers incaricati della distribuzione delle mail: come un ufficio postale, non è possibile essere sicuri dell’identità del mittente (a meno che, ovviamente, implementare altri meccanismi di sicurezza, come la Sender Policy Framework, o SPF) e quindi, se non utilizziamo altri sistemi come la cifratura asimmetrica (PGP, ad esempio con Enigmail), una verifica dei servers coinvolti può darci ragionevoli indizi sulla provenienza di una e-mail.
Infatti, e sembra strano ma è così, chiunque può inviare una e-mail a nome di chiunque altro, anche indicando mittenti che non esistono (come accade spesso nelle mail di spam), semplicemente connettendosi ad un server SMTP “open relay” oppure intenzionalmente configurato per questo scopo (ad esempio, basta installare un server Postfix su una linux box con “apt install postfix“…).
E’ semplicissimo farlo, ed è una procedura talmente banale che basta avere telnet a portata di mano e seguire, ad esempio, le istruzioni indicate sul sito della Microsoft per la verifica delle comunicazioni SMTP.
Chiaramente, e fortunatamente, non è così semplice: i server SMTP dei provider, almeno di quelli seri, implementano tutta una serie di protezioni (come le liste RBML, ad esempio) per impedire che chiunque possa inviare mail ai loro utenti. Ma si tratta comunque di protezioni aggirabili in vario modo, ad esempio violando un server all’interno dell’istituzione ed usarlo per spedire posta con il server SMTP locale: spesso i server SMTP aziendali sono aperti a tutti gli host all’interno della rete locale !
Senza voler entrare troppo nello specifico sul campo della sicurezza informatica, dobbiamo imparare ad avere sempre un occhio critico nei confronti delle e-mail che riceviamo. Lo stesso occhio che ci permette di distinguere le truffe (in cui molti, ahimè, ancora cadono) dalle comunicazioni reali. Ci sono alcuni indizi che possono aiutarci nella distinzione, senza necessariamente fare una analisi forense degli header, come ad esempio l’uso di dati personali (come nome, cognome, targa dell’auto, data di nascita…) e l’assenza di evidenti errori di ortografia o di scrittura (ad esempio, un pessimo uso dell’italiano, spesso frutto di traduzioni automatiche). Esistono, e gli ho già citati, strumenti basati sulla crittografia asimmetrica e l’hashing per apporre una firma digitale ad ogni e-mail che inviamo, che attraverso un sistema di trust condiviso, ci permette di accertare l’identità del mittente (come Enigmail).
Ricapitolando, oltre a scegliere provider affidabili per la propria casella di posta elettronica, è necessario adottare le solite precauzioni di buonsenso che ci aiutano nella vita reale. E non fate un bonifico di 500.000€ solo perché ce lo hanno chiesto in una e-mail…
Hai trovato utile questo articolo?
