L'absence de déclaration SPF est une faille (et un vilain défaut)

Bien que l'usurpation d'identité constitue un risque majeur pour leur réputation, les entreprises négligent souvent la plus élémentaire des protections. Une simple déclaration SPF permet de désigner explicitement les serveurs qui sont autorisés à envoyer des emails au nom de votre nom de domaine. Il ne faut cependant pas oublier de faire cette déclaration également pour les domaines qui n'envoient pas d'emails.

Pourquoi une entreprise est-elle plus exposée à l'usurpation si elle ne protège pas ses noms de domaine par SPF ?

Le taux de succès d'un phishing dépend avant tout de sa vraisemblance et de sa cohérence. Il a donc plus de chance d'aboutir s'il est envoyé en utilisant un vrai nom de domaine de l'entreprise usurpée. Si vous ne protégez pas vos domaines légitimes, alors ils constituent une cible de choix pour les pirates.

Voici à titre d'exemple un courriel falsifié reçu hier. Il usurpe le domaine et l'identité de SystemPay, solution de paiement en ligne utilisée par Banque Populaire

Voici la conclusion de l'examen d'authenticité opéré par Gmail à la réception de ce phishing

Gmail ne peut déterminer si l'adresse 174.138.59.80 est légitime ou non car le domaine systempay.fr ne comporte pas de déclaration SPF

En fait, les vrais emails envoyés par la solution systempay aux clients ayant fait un paiement par carte bancaire ne sont pas envoyés par le domaine systempay.fr mais par le sous-domaine mail.systempay.fr. Ce sous-domaine n'était pas protégé par SPF jusqu'à une époque récente comme le montre cet entête d'un email reçu en mars dernier

Il est désormais protégé par une déclaration se terminant par -all. Les usurpateurs qui tenteraient désormais de passer par la voie normale mail.systempay.fr trouveraient donc cette porte close et fermement verrouillée, comme le montre le test ci-dessous :

C'est pourquoi le pirate est passé par une autre porte laissée ouverte et sans surveillance : le domaine principal systempay.fr. Le fait que SystemPay lui-même n'envoie normalement pas d'email par cette voie n'a aucune incidence sur le succès de l'attaque car les internautes ciblés par le phishing ignorent que systempay.fr n'est pas la voie normale.

Le domaine systempay.fr est-il intensivement usurpé ?

Le serveur 174.138.59.80 à l'origine du phishing que j'ai reçu est tracé depuis quelques jours par le service Sender Score de la société Return Path comme émetteur pour le domaine systempay.fr. Un serveur n'apparaît dans le Sender Score que s'il émet beaucoup de messages quotidiennement, donc ce phishing est intensif. (le volume noté ci-dessous Very Low correspond tout de même à des centaines de messages quotidiens, le score de 70/100 en hausse montre que ce flux malveillant traverse actuellement plutôt bien les défenses des opérateurs de messagerie).

L'examen de cette adresse IP montre qu'elle émet au nom de systempay.fr depuis quelques jours (courbe orange)

Le verrouillage par SPF récemment mis en place par mail.systempay.fr est-il efficace contre l'usurpation ?

Probablement car ce sous-domaine ne montre pas quant à lui de signe d'usurpation dans les données de SenderScore, les deux serveurs en tête de liste sont ceux qu'on trouve dans son SPF et les autres sont des forwarders plausibles.

Pourquoi systempay.fr n'est-il pas protégé par SPF ?

Il est vraisemblable que les administrateurs de ce domaine n'y aient tout simplement pas pensé car normalement ce domaine n'est pas censé émettre quoi que ce soit semble-t-il. D'un point de vue administrateur on pense souvent qu'un domaine qui n'émet pas est un domaine qui n'a pas besoin d'authentification. On ne s'imagine pas que les pirates peuvent facilement par usurpation faire émettre n'importe quel domaine ou sous-domaine et qu'il convient donc de tous les protéger.

Comment protéger des usurpations un domaine qui n'émet pas ?

"v=spf1 -all"

ou encore "v=spf1 a -all" si le serveur envoie des emails techniques au nom du domaine.

Le pirate peut-il utiliser un sous-domaine qui n'existe pas ?

Oui, bien sûr, et les internautes ciblés ne s'en méfieront pas plus que si le sous-domaine existait. Par exemple si vous recevez un email envoyé par secure.systempay.fr, il y a peu de chance que cela éveille spontanément votre méfiance. Pourtant ce sous-domaine n'existe pas et bien entendu il n'est pas protégé. Voilà pourquoi je recommande de sécuriser également tous les sous-domaines inexistants par une déclaration DNS wildcard.

Comment le pirate a-t-il procédé pour émettre à grande échelle au nom de systempay.fr ?

En général les pirates utilisent des serveurs mal protégés et/ou peu surveillés qu'ils ont préalablement infectés un peu partout sur la planète, mais cette méthode demande un temps de préparation long et pose un problème d'efficacité car ces serveurs ne sont généralement pas autorisés par leurs hébergeurs à envoyer de gros volumes d'emails en peu de temps. Or la fulgurance de l'attaque est un facteur clé puisqu'une fois le phishing identifié il est bloqué par les opérateurs de messagerie, par les antispams et par les navigateurs. Le must pour un pirate est donc d'utiliser un serveur capable d'envoyer en masse. Plusieurs indices montrent qu'en l'occurrence l'attaquant a utilisé un service d'emailing légal de la plateforme DirectResponse (solution DirectTrack) appartenant à la société Digital River :

Ce nom apparaît dans l'identifiant du message et dans le lien de désinscription

L'adresse IP 174.138.59.80 qui a émis le phishing héberge bien le site www.directresponse.com.hk

Ce domaine correspond bien à un service d'emailing en ligne

Une plateforme d'emailing légale peut-elle envoyer des phishings usurpant des noms de domaine ?

En principe non, car son mécanisme vérifie systématiquement que la personne qui paramètre les envois est bien légitime, soit en attendant une réponse à un email qu'elle lui envoie sur le nom de domaine concerné, soit en lui demandant de créer un enregistrement dans sa zone DNS.

Il y a donc deux hypothèses :

1. soit la plateforme de Digital River a une faille de sécurité
2. soit le pirate connaît les identifiants d'un vrai compte de SystemPay chez Digital River

Comment protéger un nom de domaine avec SPF ?

Voici la procédure que j'emploie habituellement :

1. déclarer dans sa zone DNS un enregistrement SPF listant ses sources légitimes connues, au début utiliser la terminaison "softfail" (~all)
2. déclarer un enregistrement DMARC en mode observation (p=none) pour recevoir les rapports sur les sources qui émettent au nom du domaine. Repérer dans ces rapports les sources légitimes que vous avez pu oublier à la première étape
3. ajouter dans l'enregistrement SPF les sources découvertes à l'étape 2 puis passer le réglage à "hardfail" (-all)
4. continuer à consulter les rapports DMARC pour vérifier que les sources légitimes sont autorisées (une source peut changer d'adresse IP au cours du temps) et surveiller les sources usurpatrices

Pour aller plus loin

Mettre en place le protocole DKIM et passer la déclaration DMARC en mode "reject" de façon à bloquer les usurpations dès leur arrivée sur les serveurs SMTP.

Je peux vous aider à faire cela :-)

Vos domaines ont tous un enregistrement SPF, donc tout va bien ?

C'est bien en effet, mais assurez-vous qu'aucun ne comporte d'erreur. De très nombreuses sociétés présentent des failles dues à des déclarations erronées. A titre d'exemple et pour rester dans le contexte, le domaine bpce.fr (Banque Populaire et Caisse d'Epargne) a bien un enregistrement SPF et son rédacteur avait bien l'intention d'interdire fermement les serveurs hors de la liste à émettre en son nom comme le montre la terminaison -all

L'auteur de cette déclaration croyait probablement protéger ainsi des usurpations le domaine bpce.fr, mais en réalité cette déclaration SPF ne protège de rien. En voici la raison :

Le nombre de requêtes DNS nécessaires à l'évaluation d'une source illégitime vis à vis de cette déclaration dépasse systématiquement les limites définies par le protocole. Voici ce qui se passe sur n'importe quel serveur SMTP qui contrôle un email illégitime émis au nom de bpce.fr :

Le statut "permerror" ne permet de conclure ni à la légitimité, ni à l'illégitimité, dans un tel cas le mail frauduleux passe.

BPCE a également fait une erreur dans sa déclaration DMARC

La personne qui a fait cette déclaration a demandé à recevoir les rapports sur l'adresse dmarc-rua@bpce-it.fr mais le domaine bpce-it.fr ne l'y autorise pas. Donc cette adresse ne reçoit rien. Par ailleurs, des rapports sont également envoyés à toolbox.dmarc-report.com mais il est fort probable que personne ne les analyse, sans quoi les statuts SPF "permerror" auraient déjà attiré l'attention et déjà été corrigés.

J'ai cité SystemPay et BPCE et je les prie de bien vouloir m'excuser de cette publicité car ils sont loin d'être un cas isolé. Les erreurs ou absences de déclaration SPF et/ou DMARC affectent des milliers d'entreprises et font le bonheur des pirates. Ne serait-il pas temps de protéger sérieusement les noms de domaines en commençant par appliquer correctement les protocoles standards d'authentification ?