Emails sécurisés : comment protéger ses emails des usurpations d’identité

En 2016, 37 % des entreprises ont été victimes de phishing. Découvrez les raisons de la vulnérabilité des courriers électroniques aux usurpations d’identités et les moyens de vous en prémunir en déployant 3 normes existantes :

• SPF, Sender Policy Framework : pour indiquer qui est autorisé à émettre des courriers électroniques en son nom (de domaine) ;
• DKIM, DomainKeys Identified Mail pour vérifier l’origine et l’intégrité de ses courriers électroniques ;
• DMARC, Domain-based Message Authentication, Reporting and Conformance : pour indiquer au récepteur quoi faire en cas d’échec SPF et DKIM.

Attaques par phishing en 2016 : une recrudescence

Les attaques basées sur l’envoi d’emails sont de plus en plus nombreuses et de plus en plus ciblées. Selon un rapport de Kaspersky Labs de novembre 2016, basé sur les données de 4 000 entreprises dans 25 pays, 37% ont subi au moins une attaque par phishing en 2016.

Le phishing ou hameçonnage, désigne une technique de piratage qui consiste à envoyer massivement des emails contenant une pièce jointe dont l’ouverture installera un virus de type Locky ou encore un lien vers un formulaire imitant un service officiel (banque, service de messagerie, etc.) afin de dérober les identifiants ou le numéro de carte bancaire de la victime.

Ce type d’attaque exploite une faille humaine en pariant sur le manque de vigilance ou de formation d’une partie des destinataires du message. Un utilisateur bien formé saura identifier les noms de domaine suspects dans les adresses et les liens ou encore les extensions des fichiers envoyés en pièce jointe (« tiens, un point JS »).

Email-spoofing et usurpation d’identité au cœur de spectaculaires attaques

Si le phishing s’apparente à la pêche au filet, le spear-phishing, littéralement « pêche au harpon » désigne une approche où le pirate vise un individu ou une entreprise en particulier. Dans une première étape, l’identité, le rôle et l’adresse email officielle des personnes clés de l’organisation sont obtenues par l’analyse des réseaux sociaux et du site Internet de la société. Dans un second temps, un scénario est construit pour obtenir l’action souhaitée via l’envoi d’un email qui usurpe fréquemment l’adresse email authentique d’un dirigeant de l’entreprise.

Il n’y a pas de profil-type pour les victimes. Ce type d’attaque a été employé contre des PME, pour détourner des fonds, contre des entreprises cotées, comme le groupe Vinci, pour détourner un cours de bourse ou même contre des états, comme en atteste ce rapport du département de sécurité intérieur US, rendu public en décembre 2016. On y apprend qu’un groupe de hackers lié à la Russie a durablement infiltré différentes organisations gouvernementales et des partis politiques, en utilisant notamment l’email spoofing.

Pas de vérification de l’émetteur prévue dans les normes supportant le courrier électronique

Le fonctionnement du courrier électronique est défini dans plusieurs RFC, qui sont des textes normatifs pour les aspects techniques d’Internet. Les plus récentes datent de 2008 et sont la RFC 5321, qui définit SMTP, le protocole d’acheminement des emails et la RFC 5322, qui définit le format des messages.

Ces normes ne prévoient aucune vérification de l’authenticité de l’émetteur, qui apparaitra ensuite dans le champ « De : » ou « From : » du client de messagerie. La situation est plus complexe car l’identité de l’émetteur apparait dans deux endroits différents : dans la commande « MAIL FROM » utilisée lors de la session SMTP et dans l’en-tête « From : » du message.

Pour permettre d’authentifier les courriers électroniques, de nouvelles normes complémentaires ont été définies. Il s’agit du trio SPF (RFC 7208), DKIM (RFC 6376) DMARC (RFC 7489) qui a pour point commun d’utiliser le nom de domaine comme référence et des enregistrements DNS dédiés.

Envoi d’email sécurisé par SPF, DKIM et DMARC en action

L’illustration suivante présente la chronologie et les composants qui entrent en jeu lors de l’envoi d’un email.

1. joe@football.example.com rédige un courrier électronique à destination de suzie@shopping.example.net.
   Le serveur de courrier de Joe est configuré pour DKIM et contient la clé privée. La zone DNS example.com contient la clé publique DKIM, un enregistrement SPF qui autorise l’IP du serveur de messagerie et un enregistrement DMARC qui préconise la politique « none » et l’envoi des rapports DMARC à admin@example.com.
2. Lors de l’envoi du message, le serveur utilise la clé privée pour calculer et ajouter la signature DKIM dans l’en-tête du message « DKIM Signature ».
3. Le serveur contacte le serveur SMTP smtp.example.net, qui est responsable des adresses @example.net et entame une session SMTP. Il indique dans la commande MAIL FROM qui est l’émetteur, ici joe@football.example.com.
4. La vérification SPF a lieu. Le DNS du nom de domaine de l’émetteur est interrogé pour une entrée SPF (TXT). Celle-ci existe et liste l’IP 221.227.126.130, qui correspond bien au serveur d’envoi. Le test SPF est réussi.
5.  La vérification DKIM a lieu. La signature DKIM du message reçu est recalculée et comparée à la signature envoyée dans l’en-tête. La signature est vérifiée grâce à la clé publique stockée dans l’entrée DNS. Le test DKIM est réussi.
6. Si les 2 tests SPF et DKIM avaient échoué, le serveur aurait cherché le contenu de l’enregistrement DNS _dmarc.example.com pour connaitre la politique à adopter. Ici, « p=none » indiquerait de traiter l’email avec la politique locale.
7. L’enregistrement DMARC indique également l’adresse email où envoyer le rapport d’erreur. Ici, admin@example.com, qui pourra analyser et agir.

Sender Policy Framework (SPF) : pour indiquer qui est autorisé à émettre des courriers électroniques en son nom (de domaine)

Le SPF a vocation à limiter les spams en permettant aux propriétaires de noms de domaine de déclarer les adresses IP autorisées à émettre des courriers électroniques. Cette liste d’adresses IP est publiée dans un enregistrement DNS, de type TXT qui respecte un format dédié. Cette information peut être ensuite récupérée du côté du destinataire, afin de vérifier si le client est autorisé.

L’interprétation du résultat de l’authentification est une décision locale au logiciel qui reçoit le message. L’échec SPF peut être combiné à d’autres indicateurs pour conduire à un marquage en tant que SPAM ou conduire seul à un rejet pur et simple du message. En tout état de cause, la mise en œuvre de l’action finale est variable.

Vérifier l’origine et l’intégrité de ses courriers électroniques avec une Signature DKIM, DomainKeys Identified Mail

DKIM permet de garantir l’intégrité du message transmis. Lors de l’envoi, le logiciel de messagerie calcule une empreinte du corps du message et une empreinte des en-têtes, dont « From :» qui est obligatoire. Ce calcul d’empreinte à deux propriétés importantes :

• L’empreinte est beaucoup plus courte que le texte original
• Deux messages différents ont une probabilité extrêmement faible de conduire à la même empreinte.

Si le texte ou les en-têtes du courrier électroniques changent durant l’acheminement, alors l’empreinte calculée à l’arrivée sera différente de celle calculée au début. Afin de garantir que l’empreinte puisse être calculée uniquement par le propriétaire du nom de domaine, celle-ci est signée avec la clé privée et la signature de l’empreinte est ajoutée à l’en-tête.

L’infrastructure nécessaire à DKIM est simple et préexistante puisqu’elle repose sur un en-tête intitulé « DKIM-Signature » et sur un enregistrement DNS. DKIM utilise l’algorithme de chiffrement RSA, qui met en œuvre une paire de clés pour signer le contenu du courrier électronique au moment de l’envoi et vérifier que la signature du message reçu est toujours valide au moment de la réception. La clé privée n’est connue que des serveurs qui émettent des courriers pour un nom de domaine en particulier. La clé publique est stockée dans un enregistrement DNS de type TXT ; elle est accessible à tous et peut être récupérée lors de la vérification de la signature au moment de la réception.

DKIM permet donc de garantir l’intégrité du message transmis et également d’authentifier le message comme émanant du nom de domaine qui stocke la clé publique de vérification. Cependant, ce nom de domaine est différent de celui utilisé dans l’en-tête « From ». Enfin, comme pour SPF, DKIM n’indique pas comment traiter un échec de la vérification et laisse le choix au récepteur du message.

Domain-based Message Authentication, Reporting and Conformance (DMARC) : pour indiquer au récepteur quoi faire en cas d’échec SPF et DKIM

SPF et DKIM ne spécifient pas l’action à appliquer en cas d’échec de la vérification. Cette décision dépend de la politique choisie localement par chaque destinataire. SPF authentifie le nom de domaine utilisé dans la commande MAIL FROM, qui peut différer de l’en-tête « From ». DKIM authentifie le nom de domaine qui présente une clé publique valide pour la signature du message, ce nom de domaine peut lui aussi différer de ce qui est affiché dans le champs « From ».

DMARC définit la politique à appliquer en cas d’échec de SPF et DKIM. Ce dispositif  est présenté dans la RFC informative 7489, et permet d’appliquer la politique retenue via un enregistrement DNS dédié. Cette méthode requiert une correspondance entre les noms de domaine SPF et DKIM et l’en-tête « From ». DMARC permet ensuite de choisir parmi 3 politiques à appliquer en cas de non-correspondance :

• none : aucune action, appliquer la politique locale ;
• quarantine : marquage comme spam ;
• reject : rejet du message.

Sécuriser vos emails en pratique : un déploiement progressif pour préserver leur délivrabilité

Il est tentant d’appliquer d’emblée une politique DMARC drastique (p=reject) afin de minimiser la livraison d’email usurpés. Cependant, il faut s’entourer de précautions afin d’éviter que le remède soit pire que le mal. Si vous effectuez des campagnes d’emailing marketing ou si vos services envoient des emails transactionnels, la délivrabilité de ceux-ci est stratégique. Il est primordial de procéder avec méthode et de suivre les étapes suivantes :

1. Faites réaliser un audit de votre portefeuille de noms de domaine  afin de différencier les noms de domaine associés à vos emails officiels de ceux qui ne doivent pas être associés à des emails. Sur ces noms « secondaires », qui correspondent à des noms de produits ou à des dépôts défensifs, appliquer un réglages SPF et DMARC stricts pour indiquer que vous n’envoyez jamais d’emails avec ces noms. Vous vous prémunissez explicitement ainsi d’une éventuelle usurpation d’identité sur ces noms de domaine.
2. Pour vos emails officiels, adoptez un déploiement progressif :
   • Déployez SPF et DKIM
   • Assurez-vous que vos logiciels de messagerie effectuent correctement les vérifications SPF et DKIM sur les messages entrants
   • Publiez un enregistrement DMARC avec une politique adaptée et une adresse de collecte des rapports d’échecs
   • Analysez les rapports et ajustez les réglages. Par exemple, en ajoutant les IPs légitimes à votre enregistrement SPF ou en déployant DKIM auprès de vos prestataires externes (plateformes d’emailing ou envois transactionnels).
   • Modifiez la politique DMARC et passez progressivement à une politique de rejets. Contrôlez la délivrabilité de vos mails au fur et à mesure de ces ajustements.
3. Surveillez les noms de domaine dont les écritures sont proches des vôtres afin de détecter au plus tôt les « bons candidats » pour une usurpation d’identité. Dans le cas de manipulation du cours de bourse du groupe Vinci, c’est un nom de domaine déposé par un tiers qui est à l’origine de la fraude.

Solidnames vous accompagne sur l’ensemble de ces étapes, contactez-nous pour réaliser un diagnostic gratuit de risque d’usurpation d’identité par email (DRUIDE).