Dans notre précédent article de blog, Tackling Phishing : The Most Popular Phishing Techniques and What You Can Do About It, nous avons abordé toute une série de techniques utilisées par les cyberpirates (qu’il s’agisse d’un collectif sophistiqué à la solde d’un État ou d’un pirate informatique de bas niveau) pour lancer des campagnes de phishing. L’une des techniques les plus employées était la falsification d’e-mails. Cet article de blog explique plus en détail la falsification d’e-mails. Il propose par ailleurs un guide pratique des mesures à prendre pour protéger votre entreprise et réduire les chances de succès des tentatives de phishing.
Nous avons également publié voici peu un podcast sur le sujet. Vous pouvez le consulter ici.
QU’EST-CE QUE LA FALSIFICATION D’E-MAILS ?
Depuis que les communications électroniques existent (et, en fait, n’importe quel type de communications), des individus ont toujours tenté d’usurper l’identité de l’expéditeur et d’intercepter ou de falsifier le message. Au temps des Romains, la falsification portait sur les sceaux au dos des missives. De nos jours, la technique consiste à falsifier l’adresse de l’expéditeur (« From ») d’un e-mail.
La falsification d’e-mails existe depuis longtemps et reste très répandue, inondant les boîtes de réception et les dossiers de spam de documents malveillants habituels ou de liens vers une page de renvoi clonée à partir d’un service légitime.
La falsification d’un e-mail est un processus relativement simple : il suffit pour le cybercriminel de créer, compromettre ou trouver un serveur SMTP (Simple Mail Transfer Protocol) qui lui permet d’envoyer les e-mails falsifiés.
Pour mieux comprendre la falsification, examinons d’abord la structure d’un e-mail.
ANATOMIE D’UN E-MAIL
Vous pouvez considérer un e-mail comme une lettre normale. Tout comme il est nécessaire d’adresser la lettre à une personne et/ou un lieu spécifique, l’e-mail doit avoir un destinataire.
Lettre postale – Formelle | ||
Enveloppe | MAIL FROM : expéditeur@origine.xyz RCPT TO : destinataire@domaine.xyz | À : destinataire + adresse Adresse de retour : expéditeur + adresse |
Contenu | À : destinataire De : expéditeur Objet : titre du document Date : date de la rédaction Corps : contenu du message, souvent au format texte ou HTML | À : destinataire De : auteur Titre : titre du document Date : date de la rédaction Corps : contenu de la lettre |
Comme vous pouvez le voir, les lettres postales et les e-mails ont des structures très similaires, à l’exception peut-être des adresses de retour.
Lorsqu’un e-mail est envoyé depuis votre client de messagerie préféré, le processus est généralement identique. Vous indiquez le destinataire, l’expéditeur, l’objet et le corps, et l’application cliente s’occupe du reste.
- Une connexion est établie avec le serveur SMTP (Simple Message Transfer Protocol) de votre fournisseur de messagerie.
- Le client se présente avec un simple « hello » (HELO/EHLO) et le nom de domaine complet (FQDN) du client.
- Si le message HELO peut correspondre à pratiquement n’importe quoi, la plupart des serveurs de messagerie vérifient que le nom FQDN existe et qu’il est associé à des enregistrements DNS MX (Mail eXchange). Si ce n’est pas le cas, l’adresse de l’expéditeur de l’e-mail peut être rejetée ou sa réputation affectée.
L’envoi du contenu est simple et exécuté à l’aide de trois commandes.
Les deux premières font partie de l’enveloppe précisant où l’e-mail doit être envoyé.
- MAIL FROM : expéditeur@origine.xyz
- RCPT TO : destinataire@domaine.xyz
- DATA
La commande suivante détaille toutes les informations à insérer dans l’enveloppe (la lettre), notamment les en-têtes To (À), From (De), Subject (Objet), Date, etc. La fin de la section DATA (Données) est identifiée par une ligne contenant un seul point.
De : « Nom de l’expéditeur » <expéditeur@origine.xyz>
À : « Nom du destinataire » <destinataire@domaine.xyz>
Objet : E-mail de test
Date : Mer 2 janv. 2019 10:00:00
Bonjour,
Ceci est un simple test !
Cordialement,
Expéditeur
.
FALSIFICATION DE L’E-MAIL
Pour falsifier un e-mail, rien de plus simple : il suffit de modifier l’adresse e-mail de l’expéditeur (from) sur l’enveloppe. Par exemple, si vous décidez de remplacer la valeur « MAIL FROM » par une autre adresse d’expéditeur et remplacez les commandes et en-têtes nécessaires, vous pouvez facilement falsifier un message.
Les fournisseurs de services de messagerie les plus répandus implémentent des mesures permettant au destinataire de vérifier la véritable origine du domaine MAIL FROM (par exemple, un enregistrement SPF, sur lequel nous reviendrons par la suite).
La falsification des e-mails est aussi simple que cela. Par exemple, les récentes campagnes de sextorsion usurpaient les adresses de messagerie des destinataires pour convaincre ces derniers que l’expéditeur contrôle leur messagerie. Ils lancent aussi très souvent des attaques BEC (piratage de messagerie d’entreprise) ou « fraude au PDG » en usurpant l’adresse e-mail d’un collègue de la victime ou d’un cadre de l’entreprise.
MAIL FROM : PDG@exemple.xyz
RCPT TO : comptes@exemple.xyz
S’il existe de nombreux outils et techniques permettant de créer et distribuer des e-mails de phishing, les outils sont conçus afin de réaliser des évaluations de phishing pour les entreprises (du moins, le plus souvent). Les outils peuvent également servir à créer des pages de renvoi ou des contenus de phishing. Évidemment, cela nécessite un serveur de messagerie, et il existe de nombreuses méthodes pour prendre le contrôle ou mettre en service un tel serveur.
DÉPLOIEMENT DE VOTRE PROPRE INFRASTRUCTURE
Bien que la création de votre propre serveur de messagerie soit assez simple, celle-ci laisse une piste numérique visible afin de permettre la remise d’un message dans les boîtes de réception des destinataires. Si vous ne respectez pas certaines règles, votre message finira dans le dossier de spam ou sera rejeté par le serveur. Configurer des enregistrements DNS (Domain Name System) pour le serveur et vérifier que l’adresse IP de l’hôte n’a pas servi dans des campagnes similaires et n’a pas été placée sur liste noire sont des activités qui peuvent prendre du temps.
COMPROMISSION
De nos jours, la plupart des sites et des serveurs possèdent un serveur SMTP utilisé pour envoyer des alertes ou des e-mails marketing. Le protocole SMTP est conçu pour échanger des e-mails entre serveurs. Toutefois, même s’il est toujours possible de compromettre un site puis de modifier la configuration et le domaine d’envoi pour refléter le domaine usurpé, cela exige du temps, de la pratique et un certain savoir-faire.
Les sites d’e-commerce possèdent souvent une fonctionnalité de messagerie régulièrement exploitée pour falsifier des messages ou envoyer du spam. Mais même les serveurs qui jouissent d’une « protection renforcée » et qui exigent une forme quelconque d’authentification sont continuellement la cible d’attaques en force, conduisant à la compromission des comptes puis à leur vente ou à leur échange en ligne ultérieur.
IDENTIFICATION D’UN SERVEUR PERMETTANT À QUICONQUE D’ENVOYER UN E-MAIL
Si le but de l’escroc est la distribution en masse, il est probable que son choix se portera sur des serveurs à relais ouvert. Dès lors qu’un serveur SMTP est mal configuré, des utilisateurs malveillants peuvent se connecter sans authentification, puis spécifier des adresses « To » et « From », insérer le contenu de leur choix et compléter n’importe quel autre champ.
En consultant le site Shodan, nous pouvons identifier plus de 6 millions de serveurs SMTP. Même si tous n’autorisent pas les relais ouverts, ils restent trop nombreux à le faire. Ces serveurs peuvent par ailleurs être très éphémères. Il arrive souvent de rencontrer des serveurs de test ou de développement déployés avec des configurations des services SMTP par défaut ou peu protégées, ce qui les expose aux compromissions. Les cyberpirates balaient souvent Internet pour identifier ces services à relais ouvert, les valider, puis les partager publiquement ou les vendre sur des forums. Les attaquants ont dès lors à leur disposition une longue liste de serveurs qu’ils peuvent utiliser pour envoyer leurs e-mails falsifiés.
Figure 2 – Serveurs SMTP exécutés sur le port standard (port 25 avec bannière SMTP
LUTTE CONTRE LA FALSIFICATION D’E-MAILS
À présent que nous savons qu’il est possible de falsifier des e-mails et que nous connaissons les méthodes pour ce faire, comment pouvons-nous bloquer ce type de menaces ?
Le SMTP est un protocole très ancien auquel on a rajouté des plug-ins de sécurité. Malheureusement, à l’instar de nombreux protocoles, le modèle de menace a changé depuis l’introduction de cette norme. Cela dit, comme la demande et les besoins ont évolué, plusieurs correctifs ont été publiés pour tenter de renforcer sa sécurité. Passons en revue certains d’entre eux.
- SPF (Sender Policy Framework) :
Le SPF dont nous parlons ici n’a évidemment rien à voir avec un indice de protection solaire. Cette norme a été développée afin de faciliter la détection et le blocage des messages falsifiés, mais sans grand succès.
Le cadre SPF (Sender Policy Framework) est une solution créée pour tenter de valider la source d’un e-mail reçu par un système de messagerie.
Malheureusement, le problème des stratégies SPF est qu’elles exigent du serveur de messagerie qu’il exécute une action. Les stratégies SPF fonctionnent comme suit : elles ajoutent un enregistrement TXT au serveur de noms de domaine (DNS) de votre domaine de messagerie, qui identifie les serveurs de messagerie autorisés à envoyer des e-mails pour ce domaine. Lorsque le serveur de messagerie du destinataire reçoit le message, son filtre antispam, s’il est configuré pour ce faire, vérifie l’existence d’un enregistrement SPF dans les entrées DNS du domaine expéditeur (« From »). S’il le trouve, il vérifie alors si le serveur d’origine correspond à ceux inclus dans l’enregistrement. L’action effectuée ensuite dépend du filtre antispam.
Voici un exemple d’enregistrement :
v=spf1 include:mail.exemple.com -all
Cet exemple très simple identifie d’abord la version de l’enregistrement SPF, puis fournit le nom de domaine complet (FQDN) du serveur de messagerie autorisé pour ce domaine. Le nom FQDN est suivi de l’action à effectuer, ici un « hard fail ». Ce type d’autorisation indique au système de messagerie du destinataire qu’il doit rejeter le message, grâce à l’option « -all ».
Ces enregistrements peuvent également servir à spécifier les plages et adresses IP et l’action à exécuter, parmi les diverses possibilités qui existent. Par exemple, « ~all » est un « soft fail » utilisé lorsque la source des e-mails légitimes est moins certaine ; cette option tend simplement à incrémenter le score de probabilité de spam. « ?all » est quant à lui neutre et est utilisé lorsque vous n’êtes vraiment pas sûr de l’origine des e-mails de votre domaine.
C’est au serveur de messagerie et au filtre antispam des destinataires que revient le choix de l’action à exécuter avec chacune de ces instructions. Les actions de la stratégie SPF (neutral, soft fail et hard fail) sont souvent utilisées, en combinaison avec une série d’autres facteurs, pour déterminer si l’e-mail est un message de spam ou un message légitime.
2. DMARC (Domain Message Authentication Reporting and Conformance) :
Comme nous l’avons vu, le cadre SPF comporte certaines failles que DMARC tente de pallier. Si l’action à effectuer en cas d’échec SPF incombe aux systèmes destinataires dotés d’un mécanisme SPF, DMARC apporte une aide supplémentaire à ces systèmes en leur fournissant des instructions en cas d’échec de la stratégie SPF. D’une part, DMARC conseille au destinataire de rejeter le message ou de le mettre en quarantaine en cas d’échec et, d’autre part, il demande l’envoi d’un rapport sur le message à une adresse donnée. Cette action est très utile dans la mesure où elle fournit des renseignements sur les campagnes de spam/spam malveillant tentant d’usurper l’identité de votre entreprise.
Voici un exemple d’enregistrement :
V=DMARC1; p=none; rua=mailto:report.rua@exemple.com; ruf=mailto:report.ruf@exemple.com;
Ici aussi, l’exemple identifie l’enregistrement TXT _dmarc de l’authentification DMARC à ajouter au serveur DNS du domaine de messagerie. L’enregistrement indique d’abord sa version, suivie de la stratégie, ici définie sur « none » (envoi d’un rapport uniquement). Il est également possible de spécifier la valeur « quarantine » (mise en quarantaine) ou « reject » (rejet). L’envoi d’un rapport vous permet d’avoir une idée plus précise des serveurs de messagerie expéditeurs légitimes que vous pourriez avoir manqué avec les options SPF ou les configurations DKIM. La valeur rua est l’adresse à laquelle envoyer le rapport agrégé (rua), ce qui est utile pour en savoir plus sur tous les messages soi-disant envoyés depuis votre domaine. L’adresse de destination (mailto) ruf est destinée aux rapports d’échec. Par ailleurs, les adresses ruf et rua permettent d’insérer plusieurs adresses de destination pour les rapports, ce qui permet, le cas échéant, de recevoir les informations sur plusieurs systèmes.
En général, la plupart des principaux opérateurs de messagerie envoient les rapports DMARC toutes les 24 heures. Le délai de remise peut être configuré dans les enregistrements TXT, mais ceux-ci sont souvent ignorés.
3. DKIM (DomainKeys Identified Mail) :
DKIM est un peu plus complexe et peut entraîner une défaillance des systèmes de messagerie s’il est mal configuré. En revanche, s’il est correctement configuré, il peut offrir un niveau d’intégrité et d’authenticité aux messages sortants. Il donne aux destinataires l’assurance que l’e-mail est légitime grâce à une signature numérique utilisée pour signer les messages envoyés par le serveur de messagerie d’origine.
Comme dans le cas de SPF et DMARC, vous avez besoin d’un enregistrement DNS TXT. Toutefois, avec DKIM, cet enregistrement permet de publier la clé publique du signataire que le serveur de messagerie de destination utilise ensuite pour vérifier que le contenu signé par la signature numérique est inclus dans les en-têtes e-mail.
Voici un exemple d’enregistrement DKIM :
V=DKIM1; k=rsa; p=PUBLICKEY
Comme pour SPF et DMARC, l’enregistrement commence par la version. Dans un enregistrement DKIM, la version est suivie par l’entrée « k= », qui identifie l’algorithme utilisé pour la clé publique. Vient ensuite la clé publique elle-même, encodée en base64.
Pour DKIM, il existe de nombreux services qui offrent une assistance pour la génération des clés publiques et des entrées pour les enregistrements DKM. La plupart des solutions de messagerie cloud possèdent des fonctionnalités intégrées pour la génération de ces enregistrements. Certaines s’intègrent même directement avec le registraire de domaines afin d’automatiser la configuration de l’enregistrement.
CONCLUSION
Même si ces solutions fonctionnent bien ensemble, c’est aux systèmes de messagerie destinataires qu’il revient de vérifier les enregistrements et d’appliquer les mesures requises. Il est intéressant de noter que certains fournisseurs de services de messagerie cloud, tels qu’Outlook 365, n’appliquent pas SPF et DKIM de façon stricte et ne les utilisent que pour classer les messages dont l’authentification a échoué comme du spam, en les redirigeant vers le dossier Courrier indésirable. Par conséquent, si certaines configurations côté client (par exemple, l’approbation de domaine) sont implémentées, les messages falsifiés contourneront ces stratégies et aboutiront dans la boîte de réception des utilisateurs.
Nous n’avons pas d’autre choix que d’utiliser ces solutions pour protéger les réputations et les marques de nos entreprises. Cela étant, elles ne pourront pas empêcher l’usurpation d’identité de marques par des techniques dites de typosquattage ou cybersquattage, ni les infections par malware distribuant des messages falsifiés via des domaines légitimes.
Comme nous l’avons mentionné précédemment, si vous utilisez des fournisseurs de messagerie cloud, vous avez généralement besoin d’un support et de l’automatisation pour configurer correctement les enregistrements destinés à ce type de déploiements. Toutefois, souvenez-vous qu’utiliser les rapports DMARC sans implémenter une quelconque action est un bon point de départ. En effet, vous avez ainsi l’assurance de ne pas donner aux solutions de messagerie une instruction qui entraînera le rejet des messages que votre équipe marketing a envoyés via un tiers ou encore via le pool d’adresses IP des serveurs de messagerie de votre solution.
En implémentant des mesures de sécurité supplémentaires telles que SPF, DMARC et DKIM, vous réduisez non seulement les risques auxquels sont exposés vos collaborateurs (en compliquant la falsification de votre domaine), mais vous diminuez aussi d’une certaine façon le risque pour vos clients et l’éventuelle utilisation abusive de votre marque, ainsi que les atteintes à la réputation qui en résultent.