Malheureusement, les incidents de délivrabilité email ne vienne pas toujours de là où nous pensons les voir arriver ! Durant le mois de mai 2024, une vieille faille de sécurité liée à l’authentification DKIM a mis à mal pendant un temps la norme BIMI (cf. Brand Indicators for Message Identification) ! Pour preuve, Google a désactivé BIMI sur les applications desktop et mobiles entre le 26 et 31 mai (j’ai pu le constater) et conseille fortement de ne pas utiliser la balise l= dans vos signatures DKIM. Je vous propose de voir l’origine de cette faille et de vérifier si vous ne l’utilisez pas dans vos emails.
DKIM : D’où vient la faille de sécurité ?
Le 17 mai dernier, des analystes de Zone.eu (un registrar et hébergeur estonien) ont publié un article sur une faille de sécurité qui concernait la signature DKIM. Cette vulnérabilité, qui existe déjà depuis plus de 10 ans, permet à un attaquant (cf. un hacker mal intentionné) de créer et d’envoyer de faux emails (cf. phishing) avec une validation de DKIM, DMARC et donc BIMI !
DKIM kesako ? DKIM - ou DomainKeys Identified Mail – est une norme d'authentification emails utilisant un système de signature cryptographique permettant de garantir l'intégrité du message lors de son envoi jusqu'à sa réception chez un destinataire.
Cette validation de DMARC sur un email de phishing serait tout à fait valide puisque si la clé DKIM est validée et alignée, l’email sera donc conforme à DMARC (seul SPF ou DKIM suffit pour valider DMARC) et le serveur distant distribuera le faux email comme un email légitime.
Pour en revenir à cette vulnérabilité de DKIM, elle concerne la balise optionnelle l= (l pour length, sa valeur étant un nombre entier) et correspond au nombre d’octets de l’email qui seront signés par DKIM. Cela signifie qu’un hacker pourrait très bien exploiter la partie non vérifiée de l’email pour y insérer son propre code malveillant !
À quoi sert-elle ? À l'origine, cette balise l= permettait de faire survivre la clé DKIM lors d'une redirection d'un email en cas de modification de son contenu pendant son transfert.
Même si cette faille est ancienne, Google l’a prise au sérieux et conseille fortement de ne pas utiliser cette balise sur sa clé DKIM.
Do not use the DKIM length tag (l=) in message headers. This tag makes messages vulnerable to spoofing.
Comment vérifier si vous utilisez la balise l= sur votre clé DKIM ?
La meilleure façon de savoir si vous pouvez être concernés par cette vulnérabilité est de vérifier l’entête d’un de vos emails et de regarder la signature DKIM pour voir si elle possède (ou non) la balise l=.
Signature DKIM sans la balise l=
DKIM-Signature : v=1; a=rsa-sha256; s=mail; t=1718359739; c=relaxed/relaxed; d=badsender.com; q=dns/txt; bh=UAAZMuYNBKK…;
Signature DKIM avec la balise l=
DKIM-Signature : v=1; a=rsa-sha256; s=mail; t=1718359739; l=1000; c=relaxed/relaxed; d=badsender.com; q=dns/txt; bh=UAAZMuYNBKK…;
Dans ce deuxième exemple, la valeur de la balise l= (l=1000) indique que ce sont les 1000 premiers octets de l’email qui seront donc signés avec DKIM et vérifiés par le serveur distant. Le reste du contenu ne sera pas pris en compte.
Suite à cette annonce, j’ai commencé à vérifier sur les domaines de nos clients et sur différents emails reçus de différents routeurs si je trouvais cette fameuse balise l= dans un entête… Et malheureusement, je n’ai trouvé aucune signature comportant la balise (ce qui est une bonne chose finalement). Par contre, Al Iverson (cf. fondateur du célèbre blog Spamresources) a trouvé un email où la signature DKIM avait la balise l=. Comme quoi, il y a de quoi s’alarmer sur les configurations de certains annonceurs !
Sources de cette article
— Zone.eu : https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/
— Valimail : https://www.valimail.com/blog/l-tag-dkim-vulnerability/
— Spamresources : https://www.spamresource.com/2024/05/be-aware-dkim-ltag-exploit.html
