Le spam d’e-mails a constitué pas moins de 69.6% du trafic e-mail en 2013, et 3.2% de l’ensemble des e-mails contenaient des malwares en pièce jointe [1]. Pour répondre aux attaques ciblées d'usurpation d'adresses e-mail, il est possible d'utiliser la sonde suricata avec un plugin spécifique pour loguer ou bloquer les spams ciblés.
1. Introduction
Le spam d’e-mails est un véritable fléau, largement amplifié par les possibilités d’usurpation d’adresses e-mail dans le protocole SMTP.
Aujourd’hui, des contre-mesures existent, pour interdire certains spams ou pour garantir l’identité de l’émetteur qui apparaît au destinataire d’un e-mail.
Toutefois, l’usurpation d’e-mails demeure toujours possible. Cette attaque continue d’être utilisée massivement pour s’introduire illégalement dans un système d’information, avec bien souvent l’usurpation de l’identité de l’un des collaborateurs de la personne ciblée.
Pour renforcer la protection contre ces menaces, l'utilisation d'une sonde de détection - en l’espèce le logiciel suricata [2] -, légèrement personnalisée et ciblant l’usurpation d’e-mails internes à l’organisation qui se défend, se révèle être pertinente.
2. Description de l’attaque
2.1 Usurpation d’un e-mail interne à l’organisation ciblée
L’attaque considérée consiste typiquement à envoyer un e-mail à l’employé d’une certaine organisation, en usurpant l’adresse e-mail de l’un de ses collaborateurs, et en invitant l’employé à cliquer sur un lien Internet ou à ouvrir une pièce jointe.
Ce mode opératoire, parfois précédé d'une phase de « social engineering », fait partie de la famille des attaques de « phishing », ou « de spear-phishing ». L’intérêt d’usurper une adresse e-mail de l’organisation ciblée, est d’avoir plus de chances de solliciter l’action souhaitée de la part de l’employé qui reçoit l’e-mail.
2.2 Exécution de l’attaque
L’envoi d’e-mails se fait par le biais du protocole SMTP [3], lequel n’a pas été initialement conçu pour garantir l'origine d'un e-mail, c'est-à-dire pour assurer que l’émetteur annoncé à la réception du message soit bien l’émetteur réel.
L’attaque réside donc essentiellement dans la possibilité de personnaliser les champs du protocole qui indiquent l’origine de l’e-mail.
2.3 Modification de l’adresse e-mail de l’émetteur
Avant toute chose, il convient de faire un bref rappel sur le protocole SMTP. L’envoi d’un e-mail se fait par le biais de plusieurs échanges. Il y a en fait deux temps dans l’envoi : une série de commandes, puis l’e-mail proprement dit, lequel contient des entêtes.
Fig. 1 : Commandes SMTP préalables à l'envoi d'un e-mail.
Fig. 2 : Envoi effectif d'un e-mail avec les headers SMTP.
L’adresse e-mail de l’émetteur se trouve, pour des raisons historiques liées notamment au routage des e-mails, à la fois dans une commande (MAIL FROM) et dans un entête à l’intérieur même de l’e-mail (From). Lors de l’envoi d’un e-mail par le biais d’une messagerie, ces deux champs sont automatiquement spécifiés. Mais on peut les modifier manuellement (configuration messagerie, utilisation de netcat, écriture d’un script avec une connexion TCP…).
Par ailleurs, si l’entête Fromn’est pas présent dans l’e-mail, c’est l’adresse e-mail de la commande MAILFROM qui va s’afficher dans la messagerie du destinataire.
Fig. 3 : Modification de l'adresse e-mail de l'émetteur.
3. Contre-mesures existantes
3.1 Utilisation d’une black-list
Des proxy SMTP existent et permettent de contrôler les flux SMTP. On peut en particulier interdire certains noms de domaine et certains e-mails répondant à des signatures. Par exemple, le récent proxy « anti-spam SMTP proxy server » (ASSP) [4], parmi ses nombreuses fonctionnalités - qui vont jusqu'à de l'analyse statistique -, peut être utilisé dans le principe simple de black-list.
Une bonne illustration de l’utilisation d’une black-list, et dans ce cas de noms de domaine exclusivement, est aussi la configuration du serveur SMTP lui-même. En pratique, le nom de domaine à rejeter est celui du serveur SMTP, car il n’y a aucune raison pour qu’un e-mail arrivant de l’extérieur du réseau comporte le nom de domaine du serveur SMTP dans l’adresse d’émission. Pour opérer, le serveur SMTP se base sur les noms de domaine apparaissant à la fois après la commande EHLO et après la commande MAIL FROM.
Ainsi, on peut en particulier interdire que des e-mails venant de l’extérieur soient « enveloppés » par les commandes EHLO et MAIL FROM comportant le nom de l’organisation.
Pour un serveur Postfix [5], la configuration se fait par le biais de l’instruction REJECT ANTI-SPOOFING.
Création du fichier /etc/postfix/anti-spoofing (blacklist à 2 entrées ici) :
# Black-list dans le fichier anti-spoofing
<le nom de domaine de l'organisation> REJECT ANTI-SPOOFING
<un autre nom de domaine> REJECT ANTI-SPOOFING
Et dans le fichier de configuration etc/postfix/master.cf :
# Lignes a rajouter dans le fichier master.cf
25 inet n – n - - smtpd
-o smtpd_sender_restrictions=hash:/etc/postfix/anti-spoofing
-o smtpd_helo_restrictions=hash:/etc/postfix/anti-spoofing
On peut remarquer que dans ce type de configuration, il est toujours possible de modifier le header From à l’intérieur de l’e-mail, et donc l’attaque d’usurpation d’e-mail n’est que partiellement contrée. Un proxy SMTP permet d’inspecter l’entête From de l’e-mail, mais ces deux solutions sont à conjuguer avec une architecture du système d'information adéquate (interfaces SMTP multiples), pour distinguer le trafic e-mail extérieur du trafic interne.
3.2 Pretty Good Privacy (PGP) et Secure Mime (S/MIME)
OpenPGP [6] et S/MIME [7] sont des standards assez similaires, qui permettent de protéger cryptographiquement un e-mail, et en particulier de le signer. Ainsi, l’identité du destinataire est connue, et elle peut être comparée aux champs From et MAIL FROM.
La différence principale entre les deux standards réside dans le fait que PGP ne retient pas le principe d’autorité de certification, la confiance des clefs reposant sur la reconnaissance par des pairs (sous la forme de signature également). S/MIME s’inscrit quant à lui dans le schéma classique de la PKI avec des certificats signés par des autorités de certification.
Les deux standards sont toujours utilisés aujourd’hui. Toutefois, pour des raisons de simplicité d’architecture, des standards réutilisés plus récemment et reposant sur la confiance du protocole DNS, sont assez largement déployés.
3.3 Technologies orientées DNS
Il convient tout d'abord de préciser que les trois technologies détaillées ci-après réutilisent le protocole DNS, et donc il est bien évidemment recommandé que les échanges se fassent suivant le protocole standardisé DNSSEC [8].
3.3.1 Standard Sender Policy Framework (SPF)
Le standard SPF [9] retient en quelque sorte le principe de white-list sur l’origine d’un e-mail, en utilisant comme éléments de comparaison uniquement les noms de domaine des commandes EHLOet MAIL FROM qui précèdent l’e-mail, et l’adresse IP source. L’objectif est de permettre aux propriétaires d’un nom de domaine de se protéger contre l’usurpation de leur nom de domaine dans l’envoi des e-mails. Ils peuvent donc publier, sous la forme d’une entrée DNS (ressource record TXT) - la spécification précédente prévoyait un record SPF -, les adresses IP ou les serveurs susceptibles d’envoyer ou de relayer des e-mails. Et lorsqu’un e-mail est reçu, l’adresse IP source est comparée aux adresses IP ou aux serveurs énumérés dans l’entrée DNS. Deux possibilités se présentent alors. Soit l’adresse IP est bien annoncée par le propriétaire du nom de domaine comme pouvant émettre des e-mails à son nom, et dans ce cas la vérification SPF réussit. Ou bien l’adresse IP n’est pas référencée dans l’entrée DNS, et la vérification SPF échoue.
Fig. 4 : Vérification SPF lors de la réception d'un e-mail.
3.3.2 Standard DomainKeys Identified Mail (DKIM)
Le standard DKIM [10] a pour objet de permettre de signer un ou plusieurs headers (et en particulier le header From) de l’e-mail. Ainsi, le destinataire peut connaître l’origine (réelle) de l’e-mail. À l’instar de PGP ou de S/MIME, la cryptographie asymétrique est utilisée selon les mêmes principes (signature). Cependant, l’architecture est différente, puisqu’elle repose, comme pour le SPF, sur des entrées DNS (ressource record TXT), qui référencent les clefs publiques et les noms de domaine (ou les utilisateurs d’un nom de domaine) associés. De plus, la signature se fait au niveau d'un module de signature DKIM dédié (en général le serveur SMTP d’émission), et non de la messagerie client.
La signature apparaît discrètement dans les headers, ce qui rend les choses transparentes. Un serveur SMTP ne vérifiant pas les signatures DKIM traitera l’e-mail indistinctement.
Fig. 5 : Cas d'une vérification DKIM positive lors de la réception d'un e-mail.
3.3.3 Specification Domain-Based Message Authentication, Reporting and Conformance (DMARC)
La spécification DMARC [11] a été mise en place pour que le propriétaire d’un nom de domaine puisse indiquer la politique (ou conduite à tenir) lorsque les tests SPF et DKIM réussissent ou non. La spécification introduit par ailleurs le principe d’alignement.
Pour SPF, cela impose que le nom de domaine du From soit le même que celui du EHLO et du MAIL FROM, voire un sous-domaine (il y a en effet deux types d’alignement, strict et relatif).
Pour DKIM, on impose dans ce cas que le signataire des headers de l’e-mail soit aussi aligné sur le nom de domaine apparaissant dans le from.
Ainsi, c’est bien la spécification DMARC qui permet, en s’appuyant sur les standards SPF et DKIM, de lutter efficacement contre l’usurpation d’e-mails, notamment grâce à la notion d’alignement. Dans la politique à suivre, publiée sous la forme d’une entrée DNS (ressource record TXT), elle peut consister en une action de rejet pur et simple, une mise en quarantaine ou alors une simple notification au propriétaire du nom de domaine. C’est ensuite à la messagerie de tenir compte de cette politique (rejet, classement en spam).
Aujourd’hui, plus de 80 000 noms de domaine ont publié des entrées (ressource records) DNS DMARC [11]. Cette spécification est néanmoins très jeune et certains serveurs mail répandus ne la supportent pas encore.
Fig. 6 : Cas d'une vérification DMARC positive lors de la réception d'un e-mail.
4. Utilisation d’une sonde de détection (suricata) pour déjouer l’attaque
La sonde de détection suricata est un logiciel open source de la famille des IDS/IPS (Intrusion Detection System/Intrusion Prevention System).
À partir de signatures qui définissent des paquets ou des séquences d'échanges suspects, ce logiciel peut créer des alertes (mode IDS) ou bloquer des paquets (mode IPS). Ce logiciel permet donc d’accéder au contenu des paquets, et en particulier au contenu des e-mails ainsi que des commandes qui les précèdent.
En définissant un type de signature ad hoc pour les attaques d’usurpation d’e-mails comportant le nom de domaine de l’organisation qui souhaite se défendre, il devient alors possible de prévenir ces attaques ciblées.
4.1 Inspection des traces des serveurs relais
4.1.1 Étiquetage d’un e-mail par les serveurs relais
Lorsqu’un serveur SMTP reçoit un e-mail qui ne lui est pas destiné, il peut le transférer, si sa configuration le prévoit, vers le serveur SMTP concerné. Cette fonctionnalité est appelée le relaying.
Ainsi, en pratique, un e-mail transite par plusieurs serveurs relais avant d’arriver au serveur SMTP de destination. Et à chaque fois qu’un serveur SMTP traite un message, il lui applique son étiquette, dans un certain header à l’intérieur de l’e-mail (header « Received »).
Ainsi, en inspectant les entêtes d’un e-mail, on peut retracer son itinéraire.
Fig. 7 : Étiquetage de l'e-mail par les serveurs relais.
4.1.2 Comparaison des serveurs relais à une white-list
L’idée de base de l’inspection est donc d’inspecter ces serveurs relais, et de les comparer à une liste blanche définie et connue de l’organisation qui se défend.
La liste blanche correspond à tous les serveurs SMTP utilisables lors de l’envoi d’un e-mail entre employés de l’organisation. Cette liste est connue et paramétrable par la DSI de l’entreprise. Ainsi, si un e-mail comporte dans ses entêtes le nom d’un serveur relais n’appartenant pas à cette liste blanche, c’est qu’il vient de l’extérieur du système d’information.
4.2 Définition d’une signature suricata ad hoc
Le plugin ajouté à suricata permet d’écrire la règle suivante :
# Fichier de signature
alert smtp any any → any any (msg :'email spoofing attack'; header_from_check='@example-organization.org/smtp1.example-organization.org,smtp2.example-organization.org,192.168.1.1');
Entre @ et / : le nom de l’organisation qui souhaite se défendre (ici « example-organization.org »).
Après le / : la liste des serveurs relais pour un routage interne conforme, donc la liste blanche à saisir :
- smtp1.example-organization.org
- smtp2.example-organization.org
- 192.168.1.1
Les sous-branches sont aussi prises en compte, cela signifie qu’un serveur subsmtp1.smtp1.example-organization.org sera considéré comme connu. De même, un échange entre albert.enstein@us.example-organization.orget alan.turing@uk.example-organization.org, sera considéré comme un échange interne de l’organisation.
4.3 Étapes logiques de détection par la sonde
Suivant les précisions précédentes, les étapes logiques de l’inspection sont les suivantes :
- L’e-mail est-il envoyé à un employé de l’organisation ? (Inspection de la commande RCPT TO)
- Quelle adresse e-mail va s’afficher dans la messagerie du destinataire ? S’il y a un entête From dans le corps du message, c’est cette adresse qui va apparaître. S’il n’y a pas d’entête From, c’est l’adresse qui se trouve dans la commande MAIL FROM qui va s’afficher. Il faut donc inspecter ces deux champs dans cet ordre.
- Ensuite, si l’adresse de l’émetteur qui va apparaître au destinataire est aussi du nom de domaine de l’organisation, alors c’est qu’on est dans le cadre d’un échange présumé interne entre employés.
- La question est donc au final : les serveurs relais par lesquels est passé l’e-mail sont-ils bien les serveurs SMTP habituels et connus de l’organisation ?
Fig. 8 : Étapes logiques de la détection de l'usurpation d'e-mail interne.
4.4 Implémentation du plugin
Suricata fournit la marche à suivre pour implémenter un mot clef personnalisé, qui permet l'application d'une fonction d'inspection sur les paquets d'un certain protocole. Ici, le mot clef que nous souhaitons utiliser est « header_from_check ».
Toutefois, afin de pouvoir bénéficier du mécanisme de reconstitution de flux – c'est-à-dire le réassemblage des paquets issus des processus de segmentation puis de fragmentation - du moteur de suricata, il faut appliquer la fonction d'inspection, non pas sur les paquets séparément, mais sur des structures de données particulières, qui sont les transactions, et qui ne sont autres que des couples requête/réponse d'un protocole applicatif. Le protocole SMTP était déjà implémenté dans suricata, mais il a fallu l'enrichir des transactions SMTP, qui contiennent toutes les données relatives à l'envoi d'un e-mail.
Par ailleurs, un mode apprentissage a été mis en place, afin de générer automatiquement la liste blanche et de faciliter le travail de la DSI.
4.5 Tests et résultats
Environ deux cents attaques différentes ont été forgées dans du flux SMTP, de manière à couvrir le spectre des formes possibles d'usurpation d'e-mails. Toutes ont été détectées lors des tests effectués, et aucun faux positif n'a été constaté lorsque le plugin a été utilisé après le mode apprentissage de la liste blanche.
D'autre part, l'impact de performance du plugin n'est pas perceptible sur le fonctionnement courant du moteur de suricata. Toutefois, l'ensemble des entêtes de l'e-mail tenant en général sur 1500 octets, c'est exclusivement la longueur de la liste blanche qui a un impact en O(n) sur les opérations d'inspection et de comparaison du plugin, paramètre qui dépend donc de l'étendue du système d'information protégé.
Conclusion
Face à la personnalisation possible des champs relatifs à l’adresse e-mail de l’émetteur d’un e-mail, la simple utilisation d’une black-list demeure une solution partielle, notamment face au caractère très évolutif de la menace.
La signature cryptographique des e-mails selon les standards OpenPGP et S/MIME est une solution qui n’a pas gagné le caractère universel escompté du fait de la relative lourdeur du déploiement d'une PKI.
La spécification DMARC, basée sur les standards SPF et DKIM, semble être aujourd’hui la réponse la plus précise à l’usurpation d’adresses e-mail, notamment par ses notions d’alignement, qui garantissent bien la cohérence entre les adresses e-mail de l’émetteur et son identité réelle. Sa simplicité de déploiement (réutilisation de l’architecture DNS) lui vaut une bonne diffusion, qui reste toutefois partielle, et la spécification fait encore ses preuves dans la communauté.
Aujourd’hui, l’opportunité de personnaliser une sonde de détection comme suricata, pour comparer les serveurs relais avec une liste blanche connue de l’organisation, apporte une plus-value intéressante dans le paysage des solutions disponibles, puisqu’elle ne nécessite qu’un déploiement local.
Références
[1] Kapersky Security Bulletin. Spam Evolution 2013
[3] SMTP IETF/RFC821, RFC2821, RFC5321
[4] DNSSEC, IETF/RFC4033 et suivants
[5] www.postfix.org/documentation.html
[6] openPGP, IETF/RFC4880
[7] S/MIME, IETF/RFC3851
[8] DNSSEC, IETF/RFC4033 et suivants
[9] Sender policy framework, IETF/RFC7208
[10] DomainKeys Identified Mail, IETF/RFC6376
[11] Domain-Based Message Authentication, Reporting and Conformance, www.dmarc.org
