efail: il pericolo viene ridimensionato

I dettagli di efail sono stati rilasciati prima del previsto! Al link https://efail.de si trova una prima descrizione, mentre una più dettagliata è in un PDF. Ecco riassunto il problema.

Come avevamo intuito, il problema risiede più nel modo in cui i client di posta gestiscono i metodi di criptazione che nel metodo stesso, in particolare per email in formato HTML. In più, l’attacco richiede l’accesso alla mail stessa da attaccare, quindi un accesso di qualche tipo all’archivio in cui si trova la mail stessa (che si trovi su un server o sul proprio pc). Per alcuni casi specifici, infine, è possibile sfruttare una attacco di tipo Man-in-the-middle, nel quale l’attaccante si pone tra il server e la vittima per modificare nella trasmissione la mail stessa: quest’ultimo tipo di attacco potrebbe essere molto complicato di per sé, però.

Le mail che ci scambiamo sono (ormai) quasi sempre di tipo HTML con qualche tipo di allegato (come specificato dallo standard MIME (Multipurpose Internet Mail Extensions – Estensioni multifunzione alla posta di Internet), che usa una designazione standard per poter identifcare le varie parti del messaggio(header –BOUNDARY per l’inizio e –BOUNDARY– per la chiusura); di fatto sia OpenPGP che S/MIME prevedono un messaggio composto da un allegato, che poi non è altro che il messaggio criptato.
Normalmente i (plugin dei) client di posta provvedono a decriptare l’allegato e visualizzarlo come fosse il messaggio, rendendo semplice l’uso.

Modificando la mail, è possibile aggiungere un header prima del messaggio criptato, che apra un collegamento il cui argomento è il messaggio criptato, ed uno in fondo, che chiuda il collegamento; quando il client di posta andrà ad aprire il messaggio farà la composizione dei tre pezzi, ma decriptando in automatico il messaggio in mezzo; a questo punto metterà insieme le varie parti del messaggio per crearne uno solo, che sarà composto da un link con il messaggio decriptato come parte del link. Se l’attaccante avrà predisposto un sito a cui puntare, potrà leggere il testo come banale richiesta al suo sito.

Affinché l’attacco abbia successo, però, c’è bisogno che la mail venga aperta dal client di posta della vittima, in quanto solo quel client avrà accesso alla chiave privata per decriptare la mail; inoltre, si ha bisogno che quel client provi in automatico da solo a contattare la URL così creata: l’esempio classico è un’immagine in una mail, tanto che è il metodo esposto nell’articolo; ma molti client (e webclient, vedi GMail) si rifiutano di scaricare le immagini in automatico da siti che non ritiene affidabili.

Insomma, l’attacco sembra piuttosto articolato e vincolato alla riuscita di qualche altro tipo di attacco, quindi non di immediata applicazione; inoltre non appare un problema di protocollo di criptazione. Queste considerazioni ci inducono a ridimensionare la criticità dell’attacco.

La mitigation consigliata per il breve periodo su efail.de è quella già data nell’annuncio: disabilitare i plugin automatici. Mentre per soluzioni definitive si invocano patch ai client e una revisione di alcuni meccanismi sia di PGP che di S/MIME: vedremo chi e come risponderà a questo appello.

Noi, forse sbagliando, non cambieremo il nostro comportamento. E voi?

Leggi il contenuto originale su Mia mamma usa Linux!