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
|
Domaines


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-mailsdemeure 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


Sur le même sujet

Un œil technique sur les sanctions de la CNIL

Magazine
Marque
MISC
Numéro
108
|
Mois de parution
mars 2020
|
Domaines
Résumé

Près de trois quarts des sanctions prononcées par la Commission Nationale de l’Informatique et des Libertés (CNIL) ont parmi leurs causes des vulnérabilités techniques de sécurité. À partir de ce constat, et au prisme de notre expérience à la fois en cybersécurité technique et en protection des données à caractère personnel, nous avons analysé les sanctions de la CNIL publiées sur le site https://www.legifrance.gouv.fr/. Nous avons notamment établi une correspondance avec les catégories de vulnérabilités techniques identifiées dans la nomenclature du top 10 de l'OWASP 2017 (Open Web Application Security Project). Nous avons également étudié les fuites de données majeures survenues en Europe et dans le monde. Il en ressort que les vulnérabilités les plus communes sont liées à l’authentification, au contrôle d’accès et à la protection des données au repos et en transit.

De l’audit de code pendant un Red Team ?

Magazine
Marque
MISC
Numéro
108
|
Mois de parution
mars 2020
|
Domaines
Résumé

Pendant un Red Team, l’exhaustivité des découvertes est mise de côté pour privilégier l’efficacité en se concentrant sur l’identification des vulnérabilités à fort impact permettant de mettre rapidement un pied dans le système d’information ciblé.

Tomoyo, le contrôle d’accès facile

Magazine
Marque
GNU/Linux Magazine
Numéro
235
|
Mois de parution
mars 2020
|
Domaines
Résumé

Par un contrôle fin des accès aux fichiers, les logiciels de type Mandatory Access Control (MAC) permettent de lutter efficacement contre le piratage et le vol de données. Tomoyo-linux propose une alternative simple d’utilisation à SELinux.

KeeRest : mettez du DevOps dans votre KeePass

Magazine
Marque
MISC
Numéro
108
|
Mois de parution
mars 2020
|
Domaines
Résumé

Nous avions vu dans MISC n°103 comment déployer une base KeePass en mode SaaS ciblant les particuliers ou de petits périmètres professionnels. Dans un autre monde, les pratiques DevOps se démocratisent et demandent d’augmenter l’agilité des développements tout en réduisant les délais de mise en production. Cet article est le fruit d’une collaboration entre un DevOps et un ingénieur SSI pour voir de quelle manière il est possible de tirer profit de KeePass dans ces environnements.

JsItBad : détecter du JavaScript malveillant sans l’exécuter

Magazine
Marque
MISC
Numéro
108
|
Mois de parution
mars 2020
|
Domaines
Résumé

C’est théoriquement impossible, et pourtant c’est faisable en pratique. En s’inspirant d’une technique d’apprentissage statistique (Machine Learning) habituellement réservée au traitement du langage naturel, il est possible de déterminer avec une très grande précision si un bout de code en JavaScript est malveillant. Ces résultats s’étendent naturellement à tout langage interprété, mais sont mis en défaut par l’arrivée du WebAssembly.

Par le même auteur

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
|
Domaines
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.