Efail_red
adv

Nonostante le problematiche di sicurezza sui sistemi di messaggistica, l’email è ancora il mezzo più diffuso con il quale scambiare dati ed informazioni anche riservate, ma quanto possiamo essere sicuri, in realtà, che nessun altro legga i nostri messaggi di posta elettronica?

Stato dell’arte

Secondo The Radicati Group Inc, compagnia che si occupa di ricerca su email, sicurezza, social networking, etc., nel 2017 sono state scambiate fino a 269 miliardi di email per giorno contenenti messaggi con dati sensibili e spesso usate per rendere sicure altre applicazioni.

Giornalisti, attivisti politici, informatori sono tra le figure più esposte ad eventuali attacchi email.

Un falso senso di sicurezza

Il protocollo TLS, di cui ci si avvale nelle telecomunicazioni, è una tecnologia che opera a livello di trasporto sul network criptando il traffico. L’email rimane, tuttavia, in chiaro sul server di posta e chiunque dovesse riuscire a compromettere un account email o il server stesso potrebbe leggere e/o cambiare il contenuto dei messaggi.

In questi casi vengono in nostro soccorso i protocolli per l’encryption end-to-end come PGP (acronimo di Pretty Good Privacy) ed S/MIME (acronimo di Secure/Multipurpose Internet Mail Extensions). Tali protocolli sono in uso da più di vent’anni, basti pensare che Phil Zimmerman sviluppò PGP nel 1991.

Sebbene S/MIME sia usato in ambienti corporativi e governativi ed altre organizzazioni come Amnesty International e Reporter Senza Frontiere raccomandino l’uso di PGP, alcuni studi mostrano che un eccesso di fiducia in tale metodologie non è giustificato.

Logica di base degli attacchi eFail

Gli attacchi eFail sfruttano, in diversi modi, le vulnerabilità dei sopra citati protocolli di encryption end-to-end. In particolare si punta alle email che sfruttano il protocollo MIME (Multipurpose Internet Mail Extention), protocollo che consente l’utilizzo di audio, video, allegati e formattazione HTML nel messaggio che, altrimenti, sarebbe solo “testo piatto”.

In primis l’intruso deve aver accesso alla mail criptata, cosa che può agevolmente fare monitorando il traffico di rete (attacco man-in-the-middle), compromettendo account, server email, backup dei sistemi. Fatto ciò, la mail viene modificata ed inviata alla vittima: mittente o destinatario della mail originale, magari modificando opportunamente i campi FROM, DATE e SUBJECT in modo da non allarmare il ricevente.

La mail non risulterà sospetta nascondendo anche la modifica al testo cifrato tramite iFrame invisibili. Il client email della vittima (programma di posta elettronica che si collega al server e scarica i messaggi per visualizzarli), a questo punto, per consentire la lettura, decripta il testo e carica eventualmente il contenuto esterno.

Il testo in chiaro viene, dunque, inviato all’intruso a causa della manipolazione che suggerisce un canale di exfiltration (leggasi estrazione) del dato, ad esempio un hyperlink nascosto nell’iFrame. Diversi sistemi di email evitano di default il caricamento dei contenuti esterni oppure ne richiedono autorizzazione all’utente. Non tutti agiscono in tal modo e, comunque, esistono metodi per bypassare la notifica all’utente. Le tecniche di attacco sfruttano le interazioni con il network, note come backchannel, che sono, ormai da tempo, considerate un noto problema di privacy.

Direct exfiltration

Questa tecnica è indipendente dal tipo di crittografia usata, non richiede modifica del testo cifrato poiché sfrutta le debolezze di alcuni client email come Apple Mail, Mail App, Thunerdbird, Postbox e Mail Mate. L’attacco, come da immagine seguente, prevede la divisione della mail in più pezzi MIME, delimitati dalla scritta BOUNDARY. Il pezzo iniziale introduce il tag HTML dell’immagine img che però verrà chiuso solo nel terzo blocco.

esempio1

Client email come i suddetti non implementano un isolamento tra il testo cifrato e quello in chiaro, i blocchi verranno decodificati separatamente e riassemblati dallo stesso client. Da tale operazione risulterà che il testo, ora in chiaro, è incluso in un tag HTML

esempio2

che verrà interpretato dal client come una chiamata al server controllato dall’intruso, inviando il testo in chiaro (%20 è lo spazio) come da immagine seguente.

esempio3

Per alcuni client email come Thunderbird e Postbox sarà necessaria un’interazione dell’utente per eseguire la chiamata. Questa si può facilmente ottenere ridisegnando l’aspetto della mail con i CSS (fogli di stile) creando una form nascosta che invierà il dato (submit) ad un click dell’utente in un qualunque punto della mail.

Malleability gadget

Questa tecnica, a differenza della precedente che si basa su errori dei client, punta sulle debolezze di vecchi sistemi di crittografia come CBC (Cipher Block Chaining) usato da S/MIME e CBF (Cipher Feedback Mode) usato da PGP. Tutti i client che rispettano gli standard saranno, quindi, sensibili a questo tipo di attacco.

Ambo i sistemi sopra citati prevedono una suddivisione in blocchi del messaggio ed ogni blocco viene fatto interagire con il blocco adiacente tramite una funzione di XOR (che ha per simbolo ⊕ ) per dare il blocco successivo.

Si riporta di seguito lo schema logico dei 2 algoritmi al solo fine di illustrare la logica di concatenazione differente.

esempio4

esempio5

La XOR mescola i bit come da schema seguente; essa è un’operazione “malleabile” in quanto ad un’inversione di bit in uno dei due operandi, corrisponde un’inversione di bit del testo in chiaro finale, nella stessa posizione. Questo, ovviamente, può causare anche risultati impredicibili.

XOR

La concatenazione degli elementi può essere sfruttata per inserire nel testo della mail il tag precedentemente visto che indurrà il client ad eseguire la chiamata.

Per inserire un testo all’interno del testo cifrato sarà necessario:

  • Conoscere una parte in chiaro della mail: tipicamente la parte criptata delle mail comincia con Content-type: multipart/signed, stringa che, a seconda della dimensione dei blocchi (tipicamente 8 o 16bit), ci renderà noto anche più di un blocco.

  • Un gadget: un blocco da posizionare adiacente al blocco con il testo noto e che lo trasformerà, tramite la XOR, nel tag desiderato. La conoscenza del testo del blocco noto consentirà di sapere cosa aggiungere per la trasformazione. La costruzione del blocco varia a seconda del protocollo che si attacca.

Un attacco al PGP è, in generale, più complesso di quello all’ S/MIME in quanto il testo in chiaro viene compresso dal primo protocollo.

Scongiurare le contromisure

I client email moderni eseguono un controllo di genuinità con un MDC (Modification Detection Code) che tipicamente occupa gli ultimi 22byte del testo cifrato. Se il codice non è valido, cosa che certamente si verifica se si modifica il testo cifrato come visto, il client dovrebbe smettere di decodificare il testo dell’email. Tale controllo può essere aggirato rimuovendo i byte interessati in modo che il controllo non avvenga affatto, oppure cambiando il tipo di pacchetto da SEIP (crittografia simmetrica con protezione d’integrità) a SE (senza protezione). Tale operazione è abbastanza semplice perché la definizione del tipo di pacchetto non è criptata nel contenuto della mail, anche se l’aggiunta di un paio di byte è necessaria per compensare la trasformazione.

Come difendersi?

Esistono dei comportamenti che possono scongiurare o, comunque, rendere molto difficile il successo di questo tipo di attacchi.

  • Nel breve periodo:

    • Rimuovere le chiavi private S/MIME e PGP dai client email per evitare che essi decriptino il contenuto dei messaggi. Si potrebbe, invece, copiare la stringa cifrata in tool esterni che la decodificheranno per noi. Tale procedura rende la lettura delle email più laboriosa ma evita l’exfiltration ed è la più sicura al momento.

    • Disabilitare la presentazione come HTML dei messaggi in ingresso. Questo impedirà al client di chiamare un URL a causa di un tag HTML presente. Tale procedura è più agile ma non esclude la presenza di altre exfiltration per i messaggi non HTML che, comunque, rientrano nelle tipologie di attacco più complesse e meno frequenti

  • Nel medio periodo: andrebbero sviluppate patch per rimediare alle vulnerabilità descritte.

  • Nel lungo periodo: aggiornamento dei protocolli S/MIME e PGP, tali standard sono, come già accennato, attempati e non prevedono certi comportamenti e tecniche d’intrusione che si sono affinati nel tempo.

Mappa dei client

La tabella a seguire riporta lo stato dell’arte dei client email analizzati dallo studio ed il loro comportamento con i vari protocolli.

SO

Client

S/MIME

PGP

 

 

 

-MDC

+MDC

SE

Windows

Outlook 2007

E

E

E

No

Outlook 2010

E

No

No

No

Outlook 2013

Ei

No

No

No

Outlook 2016

Ei

No

No

No

Win. 10 Mail

E

NA

NA

NA

Win. Live Mail

E

NA

NA

NA

The Bat!

Ei

No

No

No

Postbox

E

E

E

E

eM Client

E

No

E

No

IBM Notes

E

No

No

No

Linux

Thunderbird

E

E

E

E

Evolution

E

No

No

No

Trojita

E

No

No

No

KMail

Ei

No

No

No

Claws

No

No

No

No

Mutt

No

No

No

No

macOS

Apple Mail

E

E

E

E

MailMate

E

No

No

No

Airmail

E

E

E

E

iOS

Mail App

E

NA

NA

NA

Canary Mail

NA

No

No

No

Android

K-9 Mail

NA

No

No

No

R2Mail2

E

No

E

No

MailDroid

E

No

E

No

Nine

E

NA

NA

NA

Webmail

United Internet

NA

No

No

No

Mailbox.org

NA

No

No

No

ProtonMail

NA

No

No

No

Mailfence

NA

No

No

No

GMail

E

NA

NA

NA

Webapp

Roundcube

NA

No

No

E

Horde IMP

Ei

No

E

E

AfterLogic

NA

No

No

No

Rainloop

NA

No

No

No

Mailpile

NA

No

No

No

Legenda

-MDC

Client che supporta SEIP ed accetta i messaggi senza MDC

+MDC

Client che supporta SEIP ed ignora i messaggi con MDC errato se presente

SE

Client che supporta SE senza protezione d’integrità

SO

Sistema Operativo

E

Client che consentono l’exfiltration

Ei

Client che consentono l’exfiltration solo con interazione utente

No

Client che non consentono l’exfiltration

NA

Client che non supportano l’encryption