Signé, validé : c'est du phishing !
Dans notre boîte, nous avons reçu un email qui semble tout à fait légitime. Il est d’ailleurs arrivé directement dans la boîte principale de notre Gmail. Problème, il contenait un lien, qui semblait lui aussi légitime, mais qui ne l’était pas. Cette affaire rappelle une fois encore l’importance d’être prudent face aux messages reçus, que ce soit par email, via les réseaux sociaux, et même par courrier.
Il va falloir apprendre aux utilisateurs à se méfier d’une forme redoutable de phishing, et surtout à oublier la bonne vieille règle qui dit qu’il suffit de vérifier les liens présents dans vos mails, de les survoler pour connaître la véritable adresse de destination : les attaquants utilisent désormais des techniques qui vont vous induire en erreur !
Le principe : envoyer de vrais mails avec de vrais liens !
Tout est parti d’un mail reçu de l’entreprise Onelogin, spécialisée dans la gestion des accès et des identités. Un mail d’apparence et même de contenu légitime sous toutes ses formes (nous ne sommes pas les seuls à avoir reçu un tel email) :
Ce qui nous a mis la puce à l’oreille ? L’adresse mail de réception, qui n’est qu’un alias peu utilisé sauf… pour un portefeuille Ledger, dont les données clients ont fuité en 2020. Donc, dans un accès tout aussi légitime de paranoïa, nous n’avons bien sûr pas cliqué sur le lien.
Mais le seul élément de suspicion, à ce stade, est la certitude de n’avoir jamais réalisé cette action d’octroyer des droits mirobolants à ChatGPT.
Que disent les caractéristiques techniques de ce mail ?
Déjà, ce mail a terminé dans notre boîte de réception, et non dans le dossier « courrier indésirable ». Ce n’est pas une protection absolue, il peut y avoir de faux négatifs. Donc jetons un œil de plus près aux headers et autres informations liées à cet envoi.
Surprise : tout va bien ! Le mail est signé et semble légitime ! On voit que les vérifications DKIM et DMARC (effectuées ici par Gmail) sont en statut « pass », ce qui signifie que l’expéditeur et le contenu semblent valides. Le mail a été légitimement émis au nom de onelogin.com, mais cela ne garantit en rien que son contenu est légitime, ni même qu’il a été envoyé par l’entreprise et pas par une tierce personne qui a pris le contrôle du compte.
- Emails avec SPF, DKIM, DMARC, ARC et BIMI : à quoi ça sert, comment en profiter ?
- Les emails : analyse technique et enjeux de souveraineté
Une ligne toutefois peut susciter un doute : le véritable émetteur est sendgrid.net et non onelogin. Alors pourquoi le mail passe les vérifications ?
Pourquoi est-ce crédible ?
L’entreprise Twilio Sendgrid est spécialisée dans l’envoi de mailing pour le compte de ses clients. En effet, l’envoi en masse est une technique délicate, qui demande pas mal de précautions techniques, autant en termes de volume que de lutte contre le phishing.
Ces entreprises ont donc pignon sur rue, et prennent les dispositions nécessaires pour réguler le volume des envois et pour donner suffisamment d’éléments indiquant une activité commerciale licite. Et comme tout ceci demande pas mal de précautions, beaucoup d’entreprises passent par des prestataires spécialisés tels que Sendgrid.
Ici, comme le binôme DMARC et DKIM est valide, il est très probable que Onelogin utilise Sendgrid pour ses communications en masse, ce qui n’a rien de surprenant. Il suffit de souscrire un contrat et, techniquement, ça peut passer sous plein de formes mais l’API reste la plus pratique.
Si je suis Onelogin, il me suffit alors de disposer d’un token API pour envoyer des contenus à diffuser en masse à Sendgrid via cette API. Les mails seront donc envoyés par Sendgrid, mais sur le domaine choisi (par exemple onelogin.com ou des sous-domaines de onelogin.com, selon les options retenues).
On peut voir dans notre email que la signature DKIM utilise le sélecteur s1 avec le domaine onelogin.com. Avec une commande « dig CNAME s1._domainkey.onelogin.com +short » on remonte à la clé DKIM de Onelogin qui est chez Sendgrid : s1.domainkey.u5239.wl240.sendgrid.net. En conséquence, OneLogin autorise SendGrid à signer en son nom.
Avec la commande « dig CNAME email.onelogin.com +short » nous vérifions le domaine de rebond, qui répond : u5239.wl240.sendgrid.net. De nouveau sendgrid, avec le même identifiant u5239, preuve que Onelogin a aussi délégué son domaine de rebond et donc son SPF (Sender Policy Framework), ce que Gmail peut vérifier (avec succès dans le cas présent).
Là où ça devient intéressant : Sendgrid propose aussi du link branding, pratique qui consiste à proposer des liens sur le nom de domaine (ou sous-domaine) au nom du client. Dans notre mail, le bouton « Remove this token » renvoie vers ce lien, qui s’affiche d’ailleurs normalement quand on passe la souris dessus :
https://admin.onelogin.com/ls/click?upn=u001.NWnFFu-...Le lien n’est pas donné en entier, mais l’analyse de ce lien permet d’affirmer qu’il s’agit bien d’un lien vers le sous-domaine admin.onelogin.com.
Donc tout va bien ?
Non. Le link branding intervient justement ici : sendgrid propose un lien sur le nom de domaine de onelogin, mais il s’agit en réalité d’une redirection ! Ce service est paramétrable par le client.
Or si on suit les liens (avec un curl, par exemple), on arrive sur la chaîne de redirection suivante :
admin.onelogin.com/ls/click → asdfadsfadsfadfsjj[.]com → login-msftportal[.]com/?email=<recipient>Notre mail a été reçu le 7 novembre à 18h29, le premier domaine asdfadsfadsfadfsjj[.]com a été créé le 7 novembre à 17h19, mais il fait passe-plat vers le moins anonyme login-msftportal[.]com qui évoque clairement un portail Microsoft. Ce nom de domaine a, lui, été créé à 17h12 le même jour. Des noms de domaine créés juste avant l’envoi du mail : la tactique est classique, car les détections vont vite classer ces sites comme phishing, ils sont donc utilisés dans la foulée.
La redirection a changé entre temps pour un domaine en msft-mainlogin[.]com, toujours avec notre email comme paramètre dans l’URL. Site désormais signalé comme phishing par Microsoft Smart Defender.
Pourquoi un premier domaine abscons ? Pour détourner l’attention d’analyseurs de liens qui, s’ils s’arrêtent à la première redirection, ne verront qu’un nom de domaine sans aucun sens. Car le suivant est lui beaucoup plus évocateur d’un phishing, avec un nom Microsoft-like. Ce n’est pas la première fois que nous voyons ce genre de pratique, parfois avec des redirections différentes en fonction de l’user agent (un robot ou un « humain »).
- Sur les réseaux sociaux, une redirection peut en cacher une autre
- URL avec @ : attention aux arnaques et aux redirections frauduleuses
Comment est-ce possible ?
Le support Onelogin a confirmé, dans une réponse à notre signalement, qu’il avait eu plusieurs remontées similaires.
Une piste possible est le vol d’un jeton API permettant l’envoi de mails via Twilio Sendgrid : l’attaquant a pu s’en emparer et envoyer des mails d’apparence parfaitement légitimes, avec DMARC et DKIM vérifiés, et surtout avec un lien sur un domaine légitime grâce au service de link branding !
Et là patatras : on ne peut même plus se fier au domaine affiché, puisqu’on a un domaine tout ce qu’il y a de plus respectable, aussi bien dans le champ expéditeur (avec validation SPF, DKIM et DMARC) que dans le contenu du message.
À qui la faute ?
Ça n’est pas encore établi, mais le jeton a pu être dérobé soit chez Onelogin, soit chez Twilio Sendgrid, soit chez une tierce partie supplémentaire. Le compte en lui-même pourrait avoir été piraté ; les pistes sont nombreuses. Pour le moment, aucune des deux entreprises n’a réagi publiquement au-delà de la réponse du support. Cette histoire est, quoi qu’il en soit, la démonstration qu’un email signé et validé n’est pas une sécurité absolue.
On pouvait s’en douter, mais le piratage d’un compte ou la récupération d’un token permet de faire passer des vessies pour des lanternes, c’est-à-dire d’envoyer des emails « légitimes » avec un lien piégé. Survoler le lien pour regarder le domaine reste une pratique saine, mais elle n’est pas toujours suffisante comme nous venons de le démontrer.
