- Un cas où un attaquant a réussi à envoyer un e-mail de phishing en se faisant passer pour Google à l’aide d’une attaque par rejeu DKIM
- L’adresse d’expéditeur et les résultats d’authentification de l’e-mail semblent identiques à ceux d’un véritable message officiel de Google, ce qui peut facilement tromper les utilisateurs
- L’attaquant a utilisé Google Sites pour créer un site ressemblant à une page d’assistance officielle afin de renforcer sa crédibilité
- SPF, DMARC et DKIM passent tous l’authentification, mais le point clé est la réexpédition de l’e-mail sans modification du corps ni des en-têtes signés
- Comme mesures concrètes, il est recommandé de faire tourner régulièrement les clés DKIM et de renforcer la sensibilisation des utilisateurs
Début : un e-mail de phishing qui paraît normal
- Un proche a reçu un matin un e-mail indiquant une demande de documents juridiques concernant un compte Google
- L’expéditeur s’affichait comme une adresse officielle no-reply de Google, le message étant rédigé avec soin, sans fautes, sans lien suspect ni domaine anormal
- Le destinataire ayant du mal à en vérifier l’authenticité, il a demandé l’avis d’un expert
Analyse détaillée de l’e-mail
- Les en-têtes de l’e-mail et l’aperçu des liens ont été examinés dans un environnement sandbox
- Adresse d’expéditeur, branding, qualité de la langue, présence ou non de pièces jointes : tout paraissait normal
- Cependant, des signes anormaux ont été détectés lors de la vérification des résultats d’authentification SPF, DKIM et DMARC
Précautions face aux e-mails de phishing
- Il est fortement rappelé de ne pas cliquer sur les liens ni exécuter les instructions d’un e-mail suspect
- Répondre à cet e-mail ou ouvrir une pièce jointe en dehors d’un environnement sandbox expose à des risques de fuite d’informations, compromission de la messagerie d’entreprise, prise de contrôle de compte et intrusion réseau
- En cas de doute, il faut immédiatement demander une analyse spécialisée et signaler le message à l’équipe sécurité
Déroulement de l’attaque : utilisation de Google Sites
- Le lien contenu dans l’e-mail malveillant redirige directement vers Google Sites si l’utilisateur est déjà connecté
- Google Sites est un sous-domaine officiel de google.com que tout le monde peut créer gratuitement, mais le contenu en question n’était pas une véritable page d’assistance officielle
- Le service est utilisé pour des wikis internes, des tableaux de bord de projet, de la documentation, des sites d’événements, etc., et peut aussi être détourné comme dans cette attaque
Quand la confiance dans l’infrastructure devient une menace
- Google Sites, lancé en 2008, s’intègre à Google Workspace et permet une création et une mise en ligne faciles, avec SSL et une forte confiance de marque
- Un attaquant peut ainsi monter facilement et à faible coût un site de phishing à l’apparence officielle, sans domaine ni hébergement distincts
Détail du déroulement de l’attaque par rejeu DKIM
Étape 1 : obtenir un véritable e-mail de Google
- L’attaquant reçoit d’abord un e-mail légitime depuis le compte no-reply@accounts.google.com, puis conserve le corps et les en-têtes d’origine
Étape 2 : préparer la réexpédition du message signé
- DKIM applique une signature numérique à une partie du corps du message ainsi qu’à certains en-têtes
- Si le message d’origine et les en-têtes signés sont conservés, l’authentification reste valide lors de la réexpédition
Étape 3 : réexpédition via Outlook
- L’attaquant envoie l’e-mail d’attaque depuis un compte Outlook
- Certaines informations sur l’origine et le trajet changent, mais la signature DKIM reste valide
Étape 4 : utilisation du relais SMTP Jellyfish
- Microsoft fait transiter l’e-mail via le système Jellyfish pour le routage, ce qui crée une distance avec le serveur d’origine
Étape 5 : envoi via Namecheap PrivateEmail
- Le service PrivateEmail de Namecheap reçoit ensuite l’e-mail et joue un rôle de relais supplémentaire
- Une nouvelle signature DKIM est ajoutée à cette étape, mais elle ne satisfait pas aux critères DMARC
- La signature DKIM d’origine de Google restant valide et alignée, la vérification DMARC est tout de même réussie
Étape 6 : livraison finale dans Gmail
- Au final, le destinataire reçoit un e-mail qui semble être un message officiel de Google
- Résultat : SPF, DKIM et DMARC passent tous l’authentification
Pourquoi le faux e-mail de convocation est dangereux
- Un e-mail de « convocation » provoque chez le destinataire peur, urgence et confusion
- Il diffère des véritables procédures d’émission ou de remise d’une convocation, qui passent normalement par une remise physique ou des canaux officiels
- Ce type de phishing est très convaincant, au point de pouvoir tromper même des utilisateurs techniquement expérimentés
Conclusion et réponse à apporter
- Plus un e-mail urgent et inattendu semble sérieux, plus il est essentiel d’en vérifier l’authenticité et de demander l’intervention d’un expert
- Ne cliquez sur aucun lien, ne répondez pas et n’exécutez rien
- Il est recommandé de demander une analyse à l’équipe sécurité ou à des spécialistes de l’investigation
En complément : reproduction de l’attaque
- L’attaquant enregistre un domaine chez Namecheap et obtient le service gratuit PrivateEmail
- Il s’inscrit à Google Workspace via l’essai gratuit, vérifie le domaine, puis crée une application Google OAuth malveillante
- Le champ App Name permet de définir le nom souhaité, par exemple
Google Support
- Les notifications de compte envoyées par Google sont transmises vers PrivateEmail, ce qui permet de manipuler l’adresse d’expéditeur et l’adresse de réponse
- Au final, l’e-mail malveillant est livré à la cible visée
Questions fréquentes
- Attaque par rejeu DKIM : l’attaquant capture un e-mail légitime comportant une signature DKIM valide, puis le réexpédie avec le même contenu et les mêmes en-têtes
- Limites du blocage SPF et DMARC : SPF ne vérifie que le serveur/IP d’envoi ; en cas de rejeu, DMARC peut aussi être contourné si l’alignement DKIM reste valide
- Pourquoi la détection est difficile : sans modification du corps ni des en-têtes, il est difficile de l’identifier par la seule vérification de signature
- Contournement via Google OAuth : l’attaquant crée une application OAuth malveillante et réexpédie une notification officielle envoyée par Google pour renforcer la confiance
- Contremesures : il est important de faire tourner régulièrement les clés DKIM (cycle de 30 jours maximum) et de former les utilisateurs (prudence face aux liens suspects, vérification des URL, culture du signalement)
1 commentaires
Avis Hacker News
Je travaille sur une solution à ce problème (avec des co-auteurs venant de Google et Yahoo, c’est un projet crédible)
Voir le document Draft: DKIM2 Motivation
Cette approche n’empêche pas qu’un texte saisi par l’utilisateur soit effectivement envoyé par Google, mais elle empêche au moins qu’un tel message soit retransmis sans intention réelle de Google
Parce que les champs SMTP FROM/TO sont protégés
Le brouillon de motivation ne contient pas les détails techniques, mais on peut consulter les brouillons dans les documents associés
Voir le lien DKIM Working Group Documents
Le site Datatracker affiche mal les documents candidats, donc je mets les liens directs
Draft: dkim2-dns
Draft: dkim2-header
Draft: dkim2-modification-algebra
Draft: dkim2-bounce-processing
Draft: dkim2-message-examples
Je me demande comment cela fonctionnerait pour les mailing lists ou les groupes
Par exemple, il est fréquent qu’un mail externe envoyé à accounts-payable@example.com soit automatiquement transféré aux membres de l’équipe
Je me demande si, côté système du destinataire final, il faudra configurer une confiance envers le forwarder de la mailing list, ou bien une logique interne pour suivre l’appartenance à certaines listes
Il doit être possible de vérifier que le destinataire initial, accounts-payable, était bien un destinataire valide
Il m’est réellement arrivé que le FBI saisisse l’intégralité des données de mon compte Google après ma condamnation pour piratage informatique
Ils ont récupéré des données une fois en 2016, puis à nouveau en 2018
En pratique, ils ne procèdent pas comme dans cet article
D’après mon expérience, la communication officielle passe par un e-mail adressé à un service spécifique chez Google
Les forces de l’ordre agissent avec le plus de discrétion possible pour éviter que la personne visée par l’enquête ne s’en rende compte
On reçoit un e-mail de usernotice@google.com disant ceci :
Dans le cas d’une Federal Grand Jury subpoena, il est généralement demandé qu’un prestataire de service (comme Google) ne vous en informe pas avant 1 à 2 ans, via une notification différée
Une subpoena ne donne accès qu’à des données générales de type registres (informations de facturation, historiques de connexion, etc.), pas au contenu lui-même (e-mails, etc.)
Pour obtenir les données réelles comme les e-mails, il faut un mandat de perquisition distinct, et Google ne notifie généralement pas séparément l’exécution de ce type de mandat
On est vendredi, et ce commentaire vient de me réveiller à 10 %
Je veux vraiment connaître toute l’histoire
Intéressant
Je me demande si ce type de demande apparaît, avec une trace ou un tag, dans l’archive complète de données du compte lorsqu’on fait une demande GDPR du type « donnez-moi toutes les données liées à mon compte »
Je suppose qu’un mandat de perquisition a dû être obtenu pour violation du CFAA, fraude électronique, ou conspiration, quelque chose comme ça
J’espère que vous avez eu un bon avocat et que cela s’est bien terminé
J’ai récemment reçu une attaque similaire
L’attaquant envoie un e-mail depuis yourgoogleaccount@google.com (et non gmail.com), puis fait suivre vers yourgoogleaccount@gmail.com le message d’erreur de remise (bounce) émis par les serveurs de Google, en y ajoutant à la fin un message de spam
Le tout passe tous les contrôles de sécurité
Le mélange entre erreur postmaster et campagne de phishing est vraiment inhabituel
Quelqu’un de non technique pourrait facilement se faire avoir
Dans mon cas, le contenu du phishing disait que j’avais gagné des outils de chantier
J’ai l’impression que Google a désormais abandonné le mail
J’étais très confus en lisant l’article
Il décrit en détail une situation qui donne l’impression que l’attaquant a modifié le corps de l’e-mail pour y insérer un lien de phishing, alors qu’il n’y avait en fait ni preuve ni manipulation de ce type
Une signature DKIM inclut le hash du corps du message
Techniquement, on peut limiter la portée du hash avec le champ I=, mais j’ai vérifié que Google n’utilise pas cette option pour les e-mails courts (en examinant directement un e-mail de no-reply@accounts.google.com)
Autrement dit, pour que les vérifications DKIM et DMARC passent, le corps ne doit pas être modifié, donc le lien de phishing faisait lui aussi partie du contenu envoyé à l’origine par Google (simplement à un autre destinataire prévu)
Du coup, il s’agit surtout d’un « e-mail inquiétant transféré au mauvais endroit », et le titre « DKIM replay attack » peut sembler bien plus grave à ceux qui ne connaissent pas le sujet
Édition : en voyant « The Takeaway? » dans l’article, j’ai cru qu’il se terminait là, mais la mise à jour située dessous explique que le lien avait en réalité été injecté dans le nom d’une application Google OAuth puis inclus dans le template d’e-mail de Google
C’est le point le plus important de cette attaque, mais la structure de l’article est si mauvaise qu’il se retrouve enfoui, et cela donne l’impression trompeuse qu’il est possible d’envoyer du contenu arbitraire
Ajout : un autre commentaire souligne aussi que la capture d’écran de l’e-mail a été tronquée au milieu, de manière à masquer la partie fixe du template Google
L’attaque elle-même est bien plus bancale qu’elle n’en a l’air
Cet article semble rédigé d’une manière délibérément trompeuse
Il présente la partie visible dans la capture comme si c’était l’intégralité de l’e-mail, alors qu’il y avait vraisemblablement du texte supplémentaire qui aurait dû alerter
Si j’ai bien compris, la raison pour laquelle DKIM est valide est que l’attaquant transfère tel quel un e-mail réellement reçu de Google
Le véritable vecteur d’attaque, c’est que Google peut être amené à envoyer un e-mail dont l’attaquant contrôle une partie du texte
À mes yeux, la vraie vulnérabilité ici est surtout qu’on peut mettre une URL dans le nom d’une application Google OAuth, et que celle-ci est rendue sans discernement dans des e-mails no-reply depuis le domaine racine de Google vers une adresse arbitraire
Même si le lien n’est pas cliquable, si le texte autour est suffisamment alarmant, la victime a de fortes chances d’y aller manuellement
Le fait que des services de transfert préservant l’intégrité DKIM puissent ensuite s’empiler en plusieurs couches est surtout un aspect secondaire mais instructif
Il faudrait tout simplement interdire les URL dans les noms d’applications OAuth, en particulier celles contenant google.com
Enfin !
J’ai reçu il y a quelques mois un e-mail presque identique (adressé à un administrateur Google Domains)
Clairement, il m’a glacé le sang aussi
Moi non plus, je n’ai pas cliqué trop vite ; j’ai attendu et cherché d’autres références sur cette arnaque
Ce qui m’a paru étrange, c’est que toutes les adresses e-mail étaient masquées, et que le schéma de masquage ne correspondait à aucun des e-mails que j’administre
L’e-mail lui-même était legit, et en cherchant sur Google, j’ai vu que le texte du corps correspondait aussi
Dans mon cas, il s’agissait d’un e-mail concernant le compte d’une personne décédée, ce qui ne correspondait pas à la réalité
Mais j’ai vraiment soupçonné, à presque 100 %, que quelqu’un essayait de convaincre Google que j’étais mort afin de prendre le contrôle total de mon compte Google
C’était une expérience extrêmement angoissante
Étape 3 : l’attaquant envoie l’e-mail depuis Outlook
À ma connaissance, il est impossible de falsifier le chemin dans les en-têtes Received:
Chaque serveur ajoute lui-même les informations de son propre passage
C’est pour cela que je regarde toujours ces informations quand je veux vérifier la provenance d’un e-mail
Un e-mail venant de Google n’a aucune raison de transiter par des serveurs Microsoft
Les en-têtes du dernier serveur « de confiance » ne peuvent pas être falsifiés, le reste du trajet, lui, peut l’être
Je me demande si vous vérifiez manuellement les en-têtes de chaque e-mail
Ou si vous utilisez un outil qui les met en évidence ou les visualise
C’est vraiment une situation effrayante
Imaginez devoir expliquer la leçon de cet article à un proche
C’est décourageant de devoir dire qu’il faut toujours se méfier, même si l’e-mail vient d’un domaine de confiance et que dkim/dmarc/spf passent tous correctement
Cela dit, cette attaque reste assez limitée dans ce qu’elle permet réellement
Par exemple, elle ne permet pas d’usurper des messages depuis le compte Gmail de quelqu’un d’autre
« Lorsqu’un message est transféré, la signature DKIM est préservée tant que le corps et les en-têtes signés ne sont pas modifiés »
Ce qui surprend, c’est que l’en-tête To: ne soit pas inclus dans ce qui est signé par DKIM
Je pense qu’il faudrait soit changer la façon dont la signature est configurée, soit ajouter aux clients mail une alerte lorsque le message est valide mais que le To a été modifié
Imaginez expliquer la leçon de cet article à vos proches : leur dire de toujours se méfier
Le plus embarrassant, c’est qu’il faut déjà commencer par expliquer ce que sont dkim/dmarc/spf
En réalité, ce sont des technologies de back-end que l’utilisateur n’est pas censé connaître
Cette attaque est moins effrayante qu’elle n’en a l’air
Le texte a aussi un côté exagéré, comme s’il cherchait à vendre un produit
Le fait que l’en-tête To ne soit pas signé n’a en réalité pas beaucoup d’importance
Dans la pratique, le champ To d’un e-mail n’est pas forcément le destinataire final
Le fait de toujours se méfier des e-mails est depuis longtemps l’état par défaut
Le mieux est de ne jamais faire confiance au champ From en lui-même
Vous disiez être surpris que To: ne soit pas inclus dans la signature DKIM, mais en réalité il l’est bien
C’est pourquoi la valeur To: d’origine devait être conservée
La capture d’écran de la section de reproduction montre l’adresse To: d’origine
Cela ne veut pas dire que le message a été distribué à cette adresse
En pratique, on peut livrer un e-mail à n’importe quelle adresse avec n’importe quelle valeur de To:
Mon conseil par défaut, c’est que si un e-mail vous pousse à agir, allez directement sur le site concerné
Ne cliquez sur aucun lien
C’est moins pratique, mais au final cela permet d’éviter les problèmes
Surtout pour les banques ou les systèmes importants, cette contrainte vaut largement le coup
Dans mon entreprise, cette posture face à la menace est déjà devenue une politique
Sur Internet, il est bon usage de tout considérer avec suspicion
Beaucoup de petites entreprises et de freelances n’utilisent toujours pas la MFA, et même quand ils l’utilisent, ils se font facilement voler leurs jetons
Quand ce genre de compte est compromis, on se met à recevoir des e-mails malveillants qui ressemblent vraiment à ceux d’un utilisateur interne
Pour l’utilisateur, cela paraît totalement legit
C’est pourquoi il faut toujours traiter les e-mails avec méfiance
L’auteur écrit
« Here is the URL from that email [...] https://sites.google.com[...] »
Ce lien est précisément le premier signal d’alerte
À mon avis, l’auteur aurait dû mettre ce point en avant dès le début plutôt que trois paragraphes plus loin
Tout le monde ne connaît pas tous les sous-domaines de google.com
Le vrai problème, au-delà de la question des champs valides en SSO, c’est que Google héberge du contenu utilisateur sur des sous-domaines de son domaine principal
D’autres services comme Drive peuvent faire la même chose
C’est peut-être un drapeau rouge pour vous, mais pas forcément pour mes parents
Globalement, je pense que c’est un bon exemple de la fragilité du système de sécurité des e-mails
Il y a tant de gens intelligents sur ce forum qu’on pourrait croire qu’ils seraient capables de proposer une alternative qui règle tout ça d’un coup
Je pense aussi que Google devrait servir ce type de sites sur un domaine séparé, comme hostedbygoogle.com, et non sur le domaine principal
Je me demande pourquoi ce n’est toujours pas séparé
En pratique, toutes les alternatives réellement possibles finissent par remettre l’ensemble du contrôle à une seule entreprise
On perdrait alors ce qui reste de la principale valeur de l’e-mail : un système qui n’est pas entièrement contrôlé par qui que ce soit
Les problèmes techniques sont solvables, mais les problèmes humains et d’intérêts le sont bien moins
Les acteurs qui ont les ressources pour régler le problème n’ont généralement aucune motivation à construire une plateforme totalement ouverte
Ils ne feront pas cet effort à moins de récupérer pour eux-mêmes tout l’argent et tout le contrôle
À l’inverse, tout le monde n’a pas envie de céder l’ensemble du contrôle à une seule entreprise
C’est précisément pourquoi ce n’est pas un problème technique, mais un problème business
(C’est exactement la même raison pour laquelle il est pratiquement impossible que tous les services du métavers partagent avatars et objets
Ce n’est pas tant une impossibilité technique qu’une question que les ayants droit n’accepteront jamais)
Annonce de Shadowfax, la nouvelle startup financée par Thiel !
Notre service monopolistique sûr et centralisé, enrichi d’une couche IA et blockchain, va remplacer l’antique système de l’e-mail
Nous avons déjà décroché des contrats avec le département de la Défense américain, et il est en bonne voie pour devenir d’ici 2027 le standard de toutes les communications fédérales, internes comme externes.