Un faux message de mise à jour vise les utilisateurs de la messagerie sécurisée Proton Mail. Prudence si vous recevez un tel mail dans votre boîte aux lettres.

Vous voulez envoyer des emails chiffrés de bout en bout avec votre client mail favori, mais sans vous prendre la tête ? J’ai ce qu’il vous faut les amis : le projet open source ProtonMail Bridge pour Docker de mon gars sûr DaTux, un fidèle lecteur de Korben.info que je croise souvent sur mon live Twitch.

Ce mec a passé plus de temps à rédiger le README.md de son projet qu’à le coder, mais le résultat est là : une version dockerisée de l’interface en ligne de commande de ProtonMail Bridge qui crée un serveur SMTP local. Comme ça, vos autres conteneurs Docker peuvent envoyer des mails via votre compte ProtonMail. La classe, non ?

Bon par contre, petit bémol : pour l’instant, il faut un compte payant (Mail Plus, Proton Unlimited ou Proton Business) pour se connecter. Ça marchera pas avec les comptes gratuits. Mais vu le niveau de confidentialité et de sécurité que ça apporte à vos échanges d’emails pro, ça les vaut !

Pour commencer, récupérez la dernière image Docker avec :

docker pull ghcr.io/videocurio/proton-mail-bridge:latest

Ou la version allégée basée sur Alpine Linux :

docker pull ghcr.io/videocurio/proton-mail-bridge-alpine:latest

Ensuite, lancez le conteneur en exposant les ports TCP 12025 pour SMTP et 12143 pour IMAP sur votre interface réseau locale.

docker run -d --name=protonmail_bridge -v /path/to/your/volume/storage:/root -p 127.0.0.1:12025:25/tcp -p 127.0.0.1:12143:143/tcp --network network20 --restart=unless-stopped ghcr.io/videocurio/proton-mail-bridge:latest

N’oubliez pas de fournir un volume pour la persistance des données (mkdir /path/to/your/volume/storage).

Maintenant, ouvrez un terminal dans le conteneur en cours d’exécution et utilisez l’interface de commande interactive de ProtonMail Bridge :

docker exec -it protonmail_bridge /bin/bash

À l’intérieur, killez d’abord l’instance de bridge par défaut car une seule peut tourner à la fois :

pkill bridge

Puis connectez-vous à votre compte ProtonMail (rappel : faut un compte payant) :

/app/bridge --cli

Suivez les instructions à l’écran, renseignez votre nom d’utilisateur, mot de passe et code 2FA. Une synchro de votre compte va commencer. Prenez un café en attendant ! Si vous utilisez plusieurs domaines ou adresses email, passez en mode « split » qui va vous permettre de définir des identifiants pour chaque adresse du compte.

Ensuite re-faite ceci pour resynchroniser encore un petit coup :

change mode 0

Quand c’est fini, tapez info pour récupérer les infos de connexion SMTP/IMAP générées par ProtonMail Bridge. Copiez bien l’username ET le mot de passe (différent de celui de votre compte ProtonMail !!). Vous pouvez maintenant configurer votre client mail favori avec ces identifiants, en précisant les ports SMTP 12025 et IMAP 12143 qu’on a exposés au lancement du conteneur Docker.

Et voilà, vous pouvez envoyer des emails chiffrés de bout en bout dans la plus grande des discrétion ! Évidemment, le destinataire devra aussi avoir un compte ProtonMail pour les déchiffrer de son côté.

Pour aller plus loin, j’vous conseille de jeter un œil au README hyper complet de DaTux, avec tous les détails d’install et d’utilisation. Il a même prévu une version optimisée pour tourner sur un serveur TrueNAS Scale, le bienheureux.

En soutien, n’hésitez pas à lui mettre une petite étoile sur son repo GitHub et à partager ce tuto autour de vous !

A la prochaine !

Les emails HTML, c’est vraiment la plaie. Les clients mails ne les gèrent pas forcement bien et en plus, ils peuvent carrément être dangereux pour votre sécurité.

Histoire de vous expliquer ça plus clairement, on va prendre un exemple assez courant en entreprise. Votre chef reçoit un email tout a fait anodin, du style qu’il n’y a plus d’encre dans l’imprimante et vous le transfère pour que vous vous en occupiez. Vous recevez son mail, il est bien envoyé depuis la boite mail de ce dernier, et il est même signé cryptographiquement… Tout va bien. Sauf qu’une fois qu’il arrive dans votre boite mail, le contenu inoffensif disparait pour laisser place à un bon vieux mail de phishing, genre demande de changement de mot de passe sur un serveur, un certificat à installer, voire une demande de virement… On peut tout imaginer.

Cette mauvais surprise est possible grâce au CSS contenu dans les emails HTML. Ainsi, quand un mail est transféré, sa position dans le DOM change, ce qui permet d’appliquer des règles CSS spécifiques. Un petit malin peut alors planquer dedans des éléments qui n’apparaitrons que dans certaines conditions. C’est ce qu’on appelle des « kobold letters« , en référence à ces bestioles mythologiques fourbes et insaisissables.

Malheureusement, quasiment tous les clients mails qui supportent le HTML sont vulnérables à ce genre de coup fourré. Par exemple, Thunderbird se fait avoir en beauté. Il suffit de jouer avec les sélecteurs CSS en fonction de la position de l’email dans le DOM après transfert. Hop, l’attaquant planque le kobold letter avec un display: none, et quand le mail est transféré, il le fait apparaître à nouveau avec un display: block !important.

Et voilà, le piège est tendu !

<!DOCTYPE html>
<html>

<head>
    <style>
        .kobold-letter {
            display: none;
        }

        .moz-text-html>div>.kobold-letter {
            display: block !important;
        }
    </style>
</head>

<body>
    <p>This text is always visible.</p>
    <p class="kobold-letter">This text will only appear after forwarding.</p>
</body>

</html>

Côté Outlook en version web app (OWA), c’est un poil plus tordu vu que c’est un webmail. Mais en bricolant un peu les sélecteurs CSS en fonction des classes ajoutées par OWA, on arrive à nos fins de la même manière. Comme pour Thunderbird, le kobold letter ne se pointera alors qu’après un transfert d’email, ni vu ni connu je t’embrouille !

Gmail, quand à lui, a une parade intéressante : il vire tout le CSS quand on transfère un mail. Donc techniquement, pas de kobold letters possibles. Enfin presque… on peut quand même planquer un kobold letter en CSS, et il apparaîtra directement après transfert vu que le style sera dégagé. Par contre, impossible de faire l’inverse, càd afficher un truc dans le mail original et le planquer après transfert. C’est déjà ça de pris !

Voilà… ce genre de failles n’est pas nouveau puisque des trucs similaires ont déjà été signalés mais l’idée des kobold letters, c’est de se concentrer sur un scénario d’attaque spécifique en observant plusieurs clients mails qui pourraient laisser passer ce type de phishing.

Alors, que faire ? Bah déjà, si vous pouvez vous passer complètement des emails HTML ou les afficher dans un mode restreint, foncez ! Sinon, les clients mails pourraient faire des compromis à la Gmail comme virer le CSS au transfert. Ça casserait pas mal de trucs niveau mise en page mais ça limiterait bien les risques.

Voilà, y’a pas vraiment de remède miracle tant que les clients mail n’auront pas évolué. Donc soyez extrêmement vigilant car ce genre d’attaque de phishing ciblée n’arrive pas qu’aux autres.

Source

Microsoft va apporter une modification modeste en apparence, mais grande dans sa praticité. L'entreprise prévoit de faciliter le copier-coller des mails dans Outlook grâce aux raccourcis de copier-coller.