Question:
Quelles actions dois-je, en tant qu'utilisateur final, entreprendre en réponse à EFAIL?
Anders
2018-05-14 18:58:42 UTC
view on stackexchange narkive permalink

On parle beaucoup de EFAIL:

Les attaques EFAIL exploitent les vulnérabilités des normes OpenPGP et S / MIME pour révéler le texte en clair des e-mails chiffrés. En un mot, EFAIL abuse du contenu actif des e-mails HTML, par exemple des images ou des styles chargés en externe, pour exfiltrer le texte brut via les URL demandées.

Alors, que dois-je faire en tant qu'utilisateur final en réponse pour ça? Dois-je immédiatement arrêter d'envoyer et / ou de recevoir des e-mails cryptés? Ou peut-être tous les e-mails? Ou arrêter d'utiliser PGP pour quoi que ce soit? Existe-t-il une solution rapide? Des correctifs à installer? Et si oui, des correctifs à quoi? D'autres actions à entreprendre?

Notez qu'il s'agit d'une question sur ce qu'il faut faire en tant qu'utilisateur final. Il ne s'agit pas du fonctionnement interne de la vulnérabilité ou de la manière de résoudre le problème au niveau du protocole.

Oui, je sais que cette question est largement répondue dans le lien fourni.Mais j'ai pensé qu'il serait bon d'aborder ce problème sur ce site, car je soupçonne que cela suscitera beaucoup d'intérêt.
Je me demande si la désactivation du rendu HTML dans le client de messagerie pourrait aider.Si vous affichez uniquement le message sous forme de texte brut, aucune image ne sera extraite du serveur distant et l'exploit ne devrait donc pas fonctionner.
[Question similaire sur Crypto.SE] (https://crypto.stackexchange.com/questions/59229/is-the-software-that-uses-pgp-broken-or-is-it-pgp-itself)
@MartinVegter, se demande également (et donc poster comme commentaire pas une réponse), mais je devrais penser que décocher l'option "Charger le contenu distant dans les messages" devrait suffire.(Cela permet toujours le rendu HTML, mais toutes les images hébergées à distance seront laissées vides et ne seront pas récupérées.)
La vraie vulnérabilité réside dans ces applications qui gèrent à la fois du texte clair et chiffré en même temps ...
@Wildcard - où se trouve ce paramètre "Charger le contenu distant dans les messages"?
@MartinVegter, c'est son nom dans Apple Mail.Thunderbird a le paramètre sous un nom différent;Je suis sur mobile, mais je peux le rechercher plus tard.Quel est votre client de messagerie?
La désactivation du rendu HTML peut ne pas suffire s'il existe des mécanismes de préchargement en cours.Le courrier HTML n'est de toute façon utilisé qu'à des fins de marketing, il est donc préférable de supprimer tout support et de revenir au bon vieux texte brut.Je souris à la banalité de ce hack magnifiquement efficace et aux milliers d'experts en sécurité qui ne pouvaient pas voir la forêt pour les arbres.
Cinq réponses:
#1
+34
Craig Hicks
2018-05-15 00:35:29 UTC
view on stackexchange narkive permalink

Notamment, PGP n'est pas le problème. Le problème réside dans les applications de gestion du courrier de votre navigateur que vous avez autorisées à utiliser vos clés PGP. Ces applications de navigateur déchiffrent le message comme elles le devraient, mais à l'intérieur de ce message, en plus de votre secret se trouve une URL de Troie qui est un site d'attaquants. Votre application de navigateur a stupidement essayé de se connecter à l'URL qui a votre secret ajouté à la fin.

Pour la plupart des gens, la méthode la plus pratique est (à partir de votre lien):

À court terme: désactiver le rendu HTML. Les attaques EFAIL abusent du contenu actif, principalement sous la forme d'images HTML, de styles, etc. La désactivation de la présentation des e-mails HTML entrants dans votre client de messagerie fermera la manière la plus courante d'attaquer EFAIL. Notez qu'il existe d'autres backchannels possibles dans les clients de messagerie qui ne sont pas liés au HTML mais qui sont plus difficiles à exploiter.

Ensuite, toute URL du message déchiffré apparaîtra sous forme de texte, y compris le cheval de Troie URL. Vous seriez presque certainement capable de regarder l'URL et de savoir que quelque chose n'allait pas. Si rien n'allait, et si votre programme de messagerie a un bouton pour vous permettre de basculer en vue HTML pour ce seul courrier, vous pourrez alors lire le courrier en toute sécurité.

L'autre méthode suggérée:

À court terme: pas de décryptage dans le client de messagerie. La meilleure façon de prévenir les attaques EFAIL est de ne déchiffrer les e-mails S / MIME ou PGP que dans une application distincte en dehors de votre client de messagerie. Commencez par supprimer vos clés privées S / MIME et PGP de votre client de messagerie, puis décryptez les e-mails cryptés entrants en copiant & en collant le texte chiffré dans une application distincte qui effectue le décryptage pour vous. De cette façon, les clients de messagerie ne peuvent pas ouvrir les canaux d'exfiltration. C'est actuellement l'option la plus sûre avec l'inconvénient que le processus est plus impliqué.

pourrait être plus difficile. Sur un téléphone portable, cela peut être très très difficile. Sur un ordinateur portable ou de bureau, cela dépend de la facilité avec laquelle il serait facile de configurer l'application non-navigateur ou de demander à quelqu'un de le faire pour vous. Le temps fastidieux passé à couper et coller dépend du nombre de messages chiffrés que vous devez traiter.

Vous voudrez également faire attention à ce que l'application non-navigateur n'essaye pas automatiquement de contacter l'URL.


EDIT: L'ajout de guillemets au message ne protégera pas votre courrier chiffré envoyé. Merci à @Anders d'avoir souligné la référence.

"Applications de gestion du courrier dans votre navigateur" - n'est-ce pas à l'envers?Je comprends que la vulnérabilité se trouve dans le «navigateur» (analyseur HTML) dans les applications / clients de messagerie.
Un exemple: Firefox est un navigateur et Thunderbird est une application client installée par l'utilisateur dans Firefox.Toujours pas de capacité PGP.Ensuite, le module complémentaire Enigmail est installé sur Thunderbird.Enigmail contient le code qui effectue le décryptage, mais Thunderbird scanne ce résultat décrypté (comme un courrier ordinaire) trouve les URL et essaie automatiquement de les afficher.Je dirais donc que c'est le code d'analyse (l'analyseur HTML sonne bien) qui est appelé par Thunderbird qui fait la fuite.Si tel est le cas, c'est Thunderbird qui doit être modifié pour bac à sable les données déchiffrées.
Un autre navigateur avec d'autres clients de messagerie (comparable à Thunderbird) peut avoir intégré la gestion PGP - ne nécessitant pas d'add-on.Mais le changement requis est le même: bac à sable le résultat décrypté.
@CraigHicks Que diable?Thunderbird n'est * pas * une application cliente exécutée dans Firefox (au moins à un moment donné, ils ont partagé le framework xulrunner).Ça n'a aucun sens.Il ne scanne pas non plus automatiquement le résultat pour les URL ou quelque chose.Il affiche le HTML intégré dans un élément de type navigateur intégré.
Les erreurs d'ingénierie cryptographique dans OpenPGP et S / MIME - et les objectifs de sécurité généralement incohérents - font absolument partie du problème ici.Les schémas modernes de cryptage à clé publique n'admettent pas la modification sélective qu'efail utilise pour déclencher les canaux d'exfiltration;un faussaire ne peut remplacer que les messages en gros.
@JonasWielicki - Vous avez raison.Thunderbird est un client de messagerie> de bureau
@SqueamishOssifrage - Vous avez raison.Et le lien de l'OP en fait une stratégie nécessaire à long terme: "" "Long terme: Mettre à jour les standards OpenPGP et S / MIME. Les attaques EFAIL exploitent les failles et les comportements indéfinis des standards MIME, S / MIME et OpenPGP.les normes doivent être mises à jour, ce qui prendra un certain temps. "" "
Concernant votre modification, [efail.de] (https://efail.de/#no-quotes) aborde ce problème et explique pourquoi ce n'est pas une solution.
@CraigHicks La raison pour laquelle j'ai fait le commentaire ci-dessus est qu'il est trompeur de dire que «PGP n'est pas le problème.Le problème réside dans les applications de gestion du courrier ... «quand il y a un problème clair dans PGP (son mécanisme de cryptage à clé publique ne parvient pas à fournir IND-CCA2; de même S / MIME, qui est encore plus blessé), même si _cette manifestation particulière_de ce problème survient uniquement en combinaison avec des dysfonctionnements en aval dans les expéditeurs.
@SqueamishOssifrage - Il me semble que la question de savoir si OpenPGP satisfait ou non IND-CCA2 est orthogonale à l'existence d'EFAIL.EFAIL ne s'appuie pas sur IND-CCA2, il repose sur la remise d'un oracle gratuitement - qui est le «service gratuit» fourni avec les applications de traitement de courrier défectueuses.Il est vrai que si OpenPGP n'est pas sécurisé IND-CCA1, alors toutes les clés (clés qui ont fait l'objet d'abus par la fourniture accidentelle de l'oracle) sont compromises.Si OpenPGP est sécurisé IND-CCA2, ces clés seront en sécurité une fois le service oracle arrêté.(a continué...)
(... suite).La recherche qui a découvert EFAIL ne traite pas la question de l'IND-CCA2, elle montre seulement la présence d'un oracle.Et pour me répéter, cet oracle est la faute du logiciel client de messagerie.Référence pour la définition de IND-CCA * = https://en.wikipedia.org/wiki/Ciphertext_indistinguishability#Indistinguishability_under_chosen_ciphertext_attack/adaptive_chosen_ciphertext_attack_(IND-CCA1,_IND-CCA2)
@CraigHicks L'attaque fonctionne en transformant un texte chiffré valide en un texte chiffré valide associé.Ceci est un exemple classique de rupture de NM-CCA2, qui est équivalent à IND-CCA2.Il y a un autre problème qui est que gpg commence également à imprimer la sortie avant de vérifier le MDC.C'est un bogue dans gpg («fonctionnalité» selon laquelle il peut être abusé pour le déchiffrement de flux de fichiers de plusieurs téraoctets), _et_ un bogue dans le protocole OpenPGP qui n'interdit pas un tel comportement.Je ne veux pas dire que les expéditeurs ne sont pas irréprochables;mon point est qu'il est systématiquement cassé tout autour, et PGP est une partie du problème.
@SqueamishOssifrage - J'aurais également dû noter que si OpenPGP n'est pas sécurisé IND-CCA1, non seulement les clés maltraitées ne sont pas bonnes, mais tous les messages passés qui n'étaient même pas passés à l'oracle lorsqu'il était disponible risquent maintenant d'être décryptéshors ligne. Je crois que l'hypothèse courante est qu'OpenPGP est au moins sécurisé IND-CCA1.
@CraigHicks Breaking IND-CCA1 n'implique rien sur la récupération des clés.Voici les définitions standard et les relations entre eux: http://www.di.ens.fr/~pointche/Documents/Papers/1998_crypto.pdf
Laissez-nous [continuer cette discussion dans le chat] (https://chat.stackexchange.com/rooms/77538/discussion-between-craig-hicks-and-squeamish-ossifrage).
La deuxième stratégie dit-elle essentiellement la même chose que la première?Autrement dit, laisser le décryptage être effectué par un autre programme qui ne rend vraisemblablement pas HTML?C'est la seule façon dont je peux imaginer que cela fonctionne, mais comme cela semble être la même solution de base, je ne suis pas sûr de bien comprendre.Je suppose que cela a du sens si seul un petit volume d'e-mails utilise PGP, car le HTML sur les e-mails non PGP ne rend rien de moins sûr qu'il ne l'est déjà.
@Kat - La première stratégie consiste à désactiver le HTML pour tous les mails, chiffrés ou non.Presque tous les agents de messagerie ont cette option et c'est pourquoi elle est suggérée.Dans ce cas, le lecteur lirait l'URL attaquante dans le cadre du message, mais cela ne déclencherait pas le bogue.--- La deuxième stratégie consiste à désactiver le décryptage.Ensuite, le message affiché est toujours chiffré et ne contiendra donc pas l'URL.Mais le lecteur devra copier et coller (ou télécharger) ce message encore crypté et le décrypter d'une autre manière pour le lire.
#2
+12
Squeamish Ossifrage
2018-05-15 08:24:44 UTC
view on stackexchange narkive permalink
  1. Désactivez le rendu HTML. (Pas de envoi HTML: rendu HTML. Peu importe le courrier que vous envoyez; ce qui compte, c'est ce que votre expéditeur fait à la réception du courrier de l'adversaire .)

  2. Pensez à configurer votre messagerie pour désactiver le téléchargement automatique de la clé PGP, la vérification S / MIME OCSP, le téléchargement S / MIME CRL, le téléchargement intermédiaire S / MIME CA; pensez à mettre à jour régulièrement vos trousseaux de clés et vos magasins de certificats. Il y a un compromis ici: vous pouvez vous tirer une balle dans le pied en ne remarquant pas les certificats révoqués et vous pouvez vous désanonymiser avec des lots de téléchargements associés, mais le téléchargement automatique de la clé de votre expéditeur ou le vérificateur OCSP ou le téléchargeur de CRL peuvent vous tirer une balle dans le pied.

  3. Pensez à désactiver le déchiffrement automatique dans votre messagerie. Il y a un compromis ici: vous pouvez vous tirer une balle dans le pied en élevant la barrière à la communication si haut que vous ne voulez plus le faire, mais le déchiffrement automatique de votre expéditeur peut vous tirer dans le pied.

  4. Suivez le guide de thegrugq pour savoir comment utiliser PGP si vous devez utiliser PGP pour vous défendre contre un modèle de menace sérieuse et que vous êtes prêt à utiliser la ligne de commande gpg avec toute la surcharge mentale que cela implique. (Lisez les pages de manuel d'OpenSSL si vous devez utiliser S / MIME, mais ne vous attendez pas à ce que l'utilitaire de ligne de commande OpenSSL soit soumis à un examen minutieux…)

  5. Si vous connaissez quelqu'un connecté au développement OpenPGP ou S / MIME, soutenez leurs efforts pour leur faire utiliser l'ingénierie de cryptographie moderne et articuler des objectifs de sécurité significatifs dans des applications du monde réel comme les mailers et la vérification de paquets, pas seulement l'outil de ligne de commande gpg . (Ne réclamez pas Hacker News car l'humanité a déjà dépassé son quota d'air chaud HN.)

  6. Utilisez Signal.

  7. En savoir plus sur les détails sur crypto.se.

Pouvez-vous expliquer ce que le n ° 2 a à voir avec efail?
@Bergi Il existe plusieurs canaux d'exfiltration différents.Si l'attaquant édite un message partiellement connu pour mettre une partie inconnue - disons qu'il s'agit des octets `0a 1b 2c 3d` - à la position d'un identifiant de clé OpenPGP dans la signature, il peut être en mesure de faire en sorte que votre mailertélécharger `http: //pool.sks-keyservers.net/pks/lookup? search = 0x0a1b2c3d & op = get`.Cela s'applique de la même manière aux URL S / MIME OCSP, CRL et CA.
"Vous pouvez vous tirer une balle dans le pied en élevant la barrière à la communication si haut que vous ne voulez plus le faire" - j'appellerais cela une victoire si cela signifie ne plus ouvrir Outlook.
#3
+9
Tom K.
2018-05-15 13:08:32 UTC
view on stackexchange narkive permalink

Il existe une autre solution en dehors de la désactivation du rendu HTML - ce que vous devriez néanmoins faire.

Voici une liste des clients et webmailers concernés 1 :

List of affected clients, webapps and webmailers

Le L'attaque efail dans sa forme actuelle repose avant tout sur une vulnérabilité du client. Si vous utilisez l'un des clients concernés, vous voudrez peut-être envisager de passer à un autre pour le moment, bien que ce ne soit peut-être pas une solution à long terme. Gardez également votre client et votre plugin S / MIME et / ou PGP à jour. On suppose qu'Enigmail 2.0 atténue déjà Efail. 1

{1} https://efail.de/efail-attack-paper.pdf
{2} https://www.heise.de/newsticker/meldung/Efail-Was-Sie-jetzt-beachten-muessen-um-sicher-E-Mails- zu-verschicken-4048988.html

Tous les clients / webmailers de cette liste sont-ils affectés, ou dois-je regarder les couleurs, et si oui dans quelle (s) colonne (s)?
Sous la liste se trouve une explication des quatre symboles qui ont été utilisés.Le vert signifie que le client n'est pas affecté.Le rouge signifie que le client est affecté sans interaction de l'utilisateur.
Ainsi, à titre d'exemple, "Evolution" a un rouge et trois verts.Affecté ou pas?La colonne S / MIME est-elle pertinente ou ne devrait-elle regarder que PGP?(Honnêtement, je ne sais pas ...)
1. En général: S / MIME et PGP sont deux normes différentes pour le chiffrement à clé publique (PKE).Vous pouvez utiliser l'un ou les deux (ou aucun).Certains clients ne fournissent aucune interface pour l'un ou l'autre, de sorte qu'un utilisateur final doit installer des plugins.2. Votre exemple spécifique: Evolution semble prendre en charge à la fois S / MIME et PGP.De plus, l'implémentation de S / MIME semble être affectée par l'attaque efail, alors que son implémentation PGP ne l'est pas.Si vous utilisez PGP pour le chiffrement et que vous utilisez Evolution en tant que client, vous n'êtes - pour autant que nous le sachions maintenant - vulnérable à l'attaque efail.Si vous utilisez S / MIME et Evolution, vous l'êtes.
#4
+6
ste-fu
2018-05-14 19:34:15 UTC
view on stackexchange narkive permalink

Le conseil actuel est d'éviter de déchiffrer automatiquement l'e-mail dans votre client de messagerie. Dans la plupart des cas, cela signifie désinstaller le plugin concerné. Vous devez ensuite copier le texte chiffré dans une application distincte pour l'afficher.

Vous devriez toujours pouvoir envoyer du courrier chiffré, à condition que le destinataire prenne les précautions appropriées, même si cela impliquerait probablement d'utiliser le plugins problématiques.

Selon le commentaire de Martin Vetger, la désactivation du rendu html automatique peut également largement atténuer l'attaque, bien que les chercheurs aient également déclaré qu'il y avait d'autres canaux disponibles qui pourraient être exploités avec plus de travail.

Ce que cela signifie pour vous en tant qu'utilisateur final variera beaucoup.

Pour bénéficier de cet exploit, l'attaquant doit être en mesure de modifier le message électronique en transit ou de renvoyer un courrier électronique qu'ils ont précédemment capturé. De toute évidence, plusieurs États-nations ou votre employeur peuvent le faire, mais je suppose que vous ne trouverez probablement pas de nombreux criminels exploitant un point d'accès Wi-Fi douteux dans l'espoir de récupérer des informations personnelles sensibles de vos e-mails PGP.

Si vous l'êtes juste soucieux de la confidentialité, vous pourriez probablement continuer. L'e-mail sera toujours chiffré sur le serveur de messagerie, et GCHQ / NSA, etc. peut être en mesure de le récupérer, mais les forces de l'ordre ne peuvent pas l'utiliser contre vous.

Vous pourriez chercher à restreindre les règles de pare-feu sur votre machine aussi, de sorte que le client de messagerie ne puisse communiquer que sur 1 ou 2 ports. Cela bloquerait complètement le vecteur html et couperait potentiellement beaucoup d'autres voies d'exfiltration.

Si des vies sont en jeu, il est préférable de l'abandonner ...

+1 pour avoir mentionné l'option de blocage du client de messagerie via les règles de pare-feu.
#5
+6
Anders
2018-05-15 16:53:32 UTC
view on stackexchange narkive permalink

Correctifs à court terme

Il existe deux correctifs à court terme à choisir:

  1. Désactivez le rendu HTML dans votre client de messagerie. (Et notez que le rendu HTML, c'est-à-dire l'afficher, pas l'envoyer .)
  2. Arrêtez de déchiffrer les e-mails dans votre client de messagerie (par exemple en désactivant le PGP plugin), et à la place, copiez-collez les données cryptées dans un programme séparé pour effectuer le décryptage.

La page Web EFAIL fait référence à des moyens potentiels d'exfiltrer des données sans HTML , donc simplement faire le # 1 pourrait ne pas être complètement sûr. C'est probablement pourquoi EFF recommande également le n ° 2. Donc, bien que le n ° 2 soit moins pratique, il est probablement plus sécurisé.

Installer les mises à jour

Puisque la vulnérabilité réside dans la façon dont les clients de messagerie interagissent avec PGP, vous voudrez mettre à jour votre client de messagerie et tous les plugins. Lorsque le problème est résolu dans votre client de messagerie, vous pouvez arrêter les mesures à court terme. Les n ° 1 et n ° 2 sont des précautions de sécurité raisonnables même en l'absence d'EFAIL, donc si vous avez pris l'habitude de les utiliser, vous pouvez aussi bien continuer.

OpenPGP ou l'une de ses implémentations ne le sont pas intrinsèquement cassé, donc même si vous devez toujours garder vos logiciels à jour, il n'est pas nécessaire de les mettre à jour spécifiquement à cause de cela. Vous n'aurez pas non plus à arrêter de les utiliser.

Souvenez-vous des autres participants

Étant donné que l'expéditeur et tous les destinataires peuvent déchiffrer les e-mails, l'attaque EFAIL peut être dirigée contre l'un des ceux-ci. Ainsi, même si vous prenez les précautions ci-dessus, les messages que vous envoyez et recevez peuvent encore être décryptés si les personnes avec lesquelles vous communiquez sont moins prudentes.

Pour le moment, vous voudrez peut-être en tenir compte avant d'utiliser ces outils.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 4.0 sous laquelle il est distribué.
Loading...