Molte sono le vulnerabilità che possono implicitamente derivare dall’uso della posta elettronica e ciò per il semplice fatto che quest’ultima rappresenta senza dubbio il mezzo più efficace e veloce per lo scambio delle informazioni oggi esistente.

La prima categoria di rischi che affrontiamo è quella legata alla possibilità di una contraffazione delle intestazioni dei messaggi di posta elettronica (cd. “email spoofing”) in modo tale che essi sembrano provenire da una sorgente mentre, in realtà, sono originati da una fonte completamente diversa.

Questa forma di attacco viene in genere utilizzata per spingere l’utente a rivelare informazioni sensibili che lo riguardano attraverso un approfittamento dello stato di fiducia che egli ripone nel messaggio il quale sembra provenire da una fonte legittima (es. l’amministratore di sistema del proprio Internet Service Provider che chiede di modificare la password di accesso alla rete in un determinato modo).

Una seconda categoria di vulnerabilità è quella che comporta l’esecuzione di codice arbitrario attraverso i messaggi di posta: in questi casi la pericolosità maggiore è insita nel fatto che il codice è normalmente nascosto all’interno di comuni tag HTML che ormai la maggior parte dei moderni client di posta elettronica sono in grado di interpretare.

Fatta questa premessa va ricordato che gli stessi problemi messi in evidenza con riferimento ai controlli ActiveX muniti del flag cd. “safe for scripting” ed incorporati all’interno della pagine web si ripropongono integralmente anche per quanto riguarda la posta elettronica.

Anzi una vulnerabilità, a detta di molti, ancora più infida, poiché è in grado di aggirare qualunque meccanismo di protezione applicato agli ActiveX, è quella scoperta da Georgi Guninski ed è legata alla possibilità di “eseguire” documenti di Microsoft Office attraverso la tecnica di incapsulamento dei controlli ActiveX che fa uso dei ben noti tag <object></object>.

In pratica il problema risiede in una carenza nel meccanismo di verifica che il sistema operativo Windows compie quando, ad esempio, un tipico file di database con estensione .mdb viene caricato dal browser o dal client di posta attraverso i tag citati: non appena il client ha terminato di scaricare il file esso invoca immediatamente l’applicativo Access per aprirlo e tutto questo accade prima che l’utente abbia ricevuto una notifica sulla pericolosità della operazione con la conseguenza che, se il file contiene qualche macro VBA nociva, essa viene eseguita in modo del tutto automatico.

Infine la terza ed ultima categoria di vulnerabilità che affrontiamo è quella concernente gli attacchi tramite gli allegati di posta elettronica.

In questi casi il rischio è quello della esecuzione di codice infido che può nascondere al suo interno virus, worm e cavalli di troia.

Peraltro le tecniche che si possono adottare al riguardo sono molto varie e vanno dalla persuasione, diretta a convincere l’utente ad aprire o salvare il file allegato, fino all’impiego di tecniche più sofisticate che producono come risultato l’esecuzione nascosta del file oppure il suo salvataggio sul disco locale e la successiva esecuzione senza nessun intervento o consapevolezza da parte dell’utente stesso.

In particolare una delle forme di attacco più insidiosa è quella che prevede l’impiego dei file cd. scrap aventi una estensione del tipo .shs o .shb. 

Questi file, la cui estensione viene nascosta per default in base all’impostazione della chiave di registro HKEY_CLASSES_ROOTShellScrapNeverShowExt, sono dei wrapper, cioè una sorta di contenitori per altri oggetti incorporati che possono essere non soltanto documenti di Office ma anche altri tipi di file. 

Quando un file shs, la cui icona assomiglia molto a quella dei comuni file di testo, viene eseguito automaticamente viene anche eseguito l’oggetto incorporato.

Inoltre, tramite l’Object Packager di Microsoft, è addirittura possibile associare dei comandi all”oggetto incorporato con tutte le conseguenze che ciò può comportare.