Utilisation d’une sonde de détection (suricata) comme contre-mesure à l’usurpation d’e-mails

Magazine
Marque
MISC
Numéro
77
Mois de parution
janvier 2015
Spécialité(s)


Résumé

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.


Body

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.

SMTP_protocol_commands

Fig. 1 : Commandes SMTP préalables à l'envoi d'un e-mail.

SMTP_protocol_headers

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.

from_spoofing

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.

process_spf

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.

process_dkim

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.

process_dmarc

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.

etiquetage_serveurs_relais

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 ?
etapes_logique_detection

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

[2] www.suricata-ids.org

[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



Article rédigé par

Les derniers articles Premiums

Les derniers articles Premium

Quarkus : applications Java pour conteneurs

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Initié par Red Hat, il y a quelques années le projet Quarkus a pris son envol et en est désormais à sa troisième version majeure. Il propose un cadre d’exécution pour une application de Java radicalement différente, où son exécution ultra optimisée en fait un parfait candidat pour le déploiement sur des conteneurs tels que ceux de Docker ou Podman. Quarkus va même encore plus loin, en permettant de transformer l’application Java en un exécutable natif ! Voici une rapide introduction, par la pratique, à cet incroyable framework, qui nous offrira l’opportunité d’illustrer également sa facilité de prise en main.

De la scytale au bit quantique : l’avenir de la cryptographie

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Les listes de lecture

11 article(s) - ajoutée le 01/07/2020
Clé de voûte d'une infrastructure Windows, Active Directory est l'une des cibles les plus appréciées des attaquants. Les articles regroupés dans cette liste vous permettront de découvrir l'état de la menace, les attaques et, bien sûr, les contre-mesures.
8 article(s) - ajoutée le 13/10/2020
Découvrez les méthodologies d'analyse de la sécurité des terminaux mobiles au travers d'exemples concrets sur Android et iOS.
10 article(s) - ajoutée le 13/10/2020
Vous retrouverez ici un ensemble d'articles sur les usages contemporains de la cryptographie (whitebox, courbes elliptiques, embarqué, post-quantique), qu'il s'agisse de rechercher des vulnérabilités ou simplement comprendre les fondamentaux du domaine.
Voir les 66 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous