Archivi categoria: efail

efail: il pericolo viene ridimensionato

Facebooktwittergoogle_plusredditlinkedin

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?

efail: le email criptate con PGP o S/MIME sono a rischio

Facebooktwittergoogle_plusredditlinkedin

Avere la sicurezza che i propri messaggi saranno letti solo dal destinatario è parte ormai irrinunciabile delle nostre comunicazioni, specialmente via Internet, e la crittografia esiste proprio per questo.
Da almeno un decennio lo standard per lo scambio di file ed email è OpenPGP (sua con l’implementazione closed PGP che con la open GPG), ed esistono anche servizi che garantiscono lo scambio sicuro di messaggi grazie a questa tecnologia, come ProtonMail.

Per chi non sapesse come funziona PGP, più sotto troverà una breve spiegazione.

Il 13 maggio, tramite un tweet, il ricercatore Sebastian Schinzel ha annunciato una falla di sicurezza, in particolare per gli utilizzatori di PGP e S/MIME nello scambio di email, già battezzata efail (e-fallimento); nello stesso tweet ha rimandato al 15 maggio per avere i dettagli.
Da notare che anche la EFF (Electronic Frontier Foundation) ha deciso di dare risalto all’annuncio con un suo comunicato, nel quale si può leggere quanto segue:

EFF has been in communication with the research team, and can confirm that these vulnerabilities pose an immediate risk to those using these tools for email communication, including the potential exposure of the contents of past messages.

La EFF è in comunicazione col team di ricerca e può confermare che queste vulnerabilità pongono un rischio immediato per quanti usino quei tool per comunicazioni via mail, compreso la potenziale esposizione dei contenuti dei messaggi vecchi.

Il pericolo quindi sembra reale, e non è legato ad un atto di intercettazione – ovvero un attacco da attuare alla trasmissione o ricezione del messaggio – ma ad un vero e proprio problema di metodo –  e quindi un attacco che può essere portato anche alle mail già archiviate.

L’invito è quello di disabilitare o proprio disinstallare le estensioni del client di posta che sfrutti questi meccanismi di criptazione, con tanto di istruzioni per Thunderbird con EnigmailApple Mail con GPGTools e Outlook con Gpg4win.

Per sapere esattamente di cosa si tratti dovremo aspettare maggiori informazioni, che saranno rilasciate oggi, ma il fatto che vengano citati sia PGP che S/MIME, e che si faccia riferimento solo alle mail, fa pensare che il problema sia più nel protocollo usato per le mail in generale che nella sicurezza dei meccanismi di criptazione PGP (e della sua implementazione open GPG).

Appena sapremo qualcosa in più, vi aggiorneremo!

Facciamo un riassunto sui meccanismi di PGP e S/MIME e le nozione base di crittografia associate.

Proprio perché la crittografia è una necessità sentita da tanto tempo, esistono tante soluzioni, ma di fatto la più diffusa ed utilizzata è PGP (Pretty Good Privacy – Priviacy piuttosto buona), descritta nelle specifiche OpenPGP, ed implementata in Linux con GPG (GNU Privacy Guard – Guardia della privacy GNU). Sì, la giungla delle sigle è piuttosto complicata, ma diciamo che tutte prevedono il supporto per una serie di algoritmi e tecniche di criptazione che possono essere applicate a tanti livelli; ci occuperemo solo di quanto succeda con una mail o un file in generale.

In generale troviamo diffusi due sistemi di criptazione:

  • simmetrico
  • asimmetrico

Nel primo caso viene generata una sola chiave, da usare sia per criptare che decriptare un messaggio; si definisce simmetrico proprio perché il processo di criptazione e decriptazione è lo stesso, cambiano solo i dati di partenza.
Nel secondo caso le chiavi sono due: una pubblica, per criptare il messaggio, ed una privata, per decriptarlo. In questo caso la chiave privata è da custodire gelosamente, mentre è necessario distribuire quella pubblica. Questo secondo metodo è di gran lunga quello più usato su internet, in quanto su questo principio si basano tutte le comunicazioni sicure (da HTTPS ad SSH).

PGP usa un sistema misto (o ibrido), in cui i dati sono criptati con metodo simmetrico, mentre la chiave stessa con metodo asimmetrico, usando la chiave pubblica specifica del destinatario.
Per esempio, se Alice deve criptare un file da mandare a Bruno, le operazioni da fare sono:

  1. generazione di una chiave;
  2. applicazione della chiave al file con metodo simmetrico;
  3. criptazione della chiave stessa con la chiave pubblica di Bruno;
  4. unione dei dati criptati e della chiave criptata in un unico file.

Bruno, alla ricezione del file, dovrà effettuare una analoga sequenza di operazioni:

  1. separazione della chiave criptata dai dati criptati
  2. decriptazione della chiave usata per i dati tramite la propria chiave privata
  3. uso della chiave per decriptare i dati

L’uso di chiavi pubbliche associate ad una certo destinatario rende necessaria una infrastruttura ad hoc per la distribuzione delle chiavi pubbliche, per evitare di dover scambiare prima queste informazioni e invece richiederle quando necessario; proprio per questo esistono una serie di server, chiamati key server, deputati proprio a questo scopo.

S/MIME descrive un metodo simile, ma al posto delle chiavi asimmetriche usa certificati x509; per questo meccanismo non esiste un metodo standard di distribuzione dei certificati, che devono essere scambiati tra i corrispondenti prima di iniziare una comunicazione.