Si vous recevez un e-mail de someone@arstechnіca.com, est-ce vraiment de quelqu’un à Ars ? Certainement pas, le domaine de cette adresse e-mail n’est pas le même arstechnica.com que vous connaissez. Le caractère ‘і’ vient de l’écriture cyrillique et non de l’alphabet latin.
Ce n’est pas non plus un problème nouveau. Jusqu’à il y a quelques années (mais plus maintenant), les navigateurs modernes ne faisaient aucune distinction visible lorsque des domaines contenant des jeux de caractères mixtes étaient saisis dans la barre d’adresse.
Et il s’avère que Microsoft Outlook ne fait pas exception, mais le problème n’a fait qu’empirer : les e-mails provenant d’un domaine similaire dans Outlook afficheraient la carte de contact d’une personne réelle, qui est en fait enregistrée sur le domaine légitime, et non l’adresse similaire.
Outlook affiche les informations de contact réelles pour les domaines IDN usurpés
Cette semaine, infosec professionnel et pentester DobbyWanKenobi ont montré comment ils ont réussi à tromper le composant Carnet d’adresses de Microsoft Office pour afficher les coordonnées d’une personne réelle pour une adresse e-mail d’expéditeur falsifiée à l’aide d’IDN. Noms de domaine internationalisés (IDN) sont des domaines constitués d’un jeu de caractères Unicode mixte, tels que des lettres des alphabets latin et cyrillique qui pourraient faire apparaître le domaine identique à un domaine ASCII normal.
Le concept d’IDN a été proposé en 1996 pour étendre l’espace des noms de domaine aux langues non latines et pour faire face à l’ambiguïté susmentionnée des différents caractères qui semblent identiques (« homoglyphes ») aux humains. Les IDN peuvent également être facilement représentés uniquement au format ASCII–la version « punycode » du domaine, qui ne laisse aucune place à l’ambiguïté entre deux domaines similaires.
Par exemple, copier-coller le sosie « arstechnіca.com » dans la barre d’adresse du dernier navigateur Chrome le transformerait immédiatement en sa représentation punycode pour éviter toute ambiguïté : xn--arstechnca-42i.com. Cela ne se produit pas lorsqu’il est réel arstechnica.com–déjà en ASCII et sans le cyrillique ‘і’, est tapé dans la barre d’adresse. Une telle distinction visible est nécessaire pour protéger les utilisateurs finaux qui peuvent atterrir par inadvertance sur des sites Web imposteurs, utilisés dans le cadre de campagnes de phishing.
Mais récemment, DobbyWanKenobi trouvé que ce n’était pas tout à fait évident avec Microsoft Outlook pour Windows. Et la fonction Carnet d’adresses ne ferait aucune distinction lors de l’affichage des coordonnées de la personne.
« J’ai récemment découvert une vulnérabilité qui affecte le composant Carnet d’adresses de Microsoft Office pour Windows qui pourrait permettre à n’importe qui sur Internet d’usurper les coordonnées des employés au sein d’une organisation en utilisant un nom de domaine internationalisé (IDN) similaire externe », a écrit le pentester dans un article de blog. « Cela signifie que si le domaine d’une entreprise est ‘quelqu’un[.]com’, un attaquant qui enregistre un IDN tel que ‘ѕomecompany[.]com’ (xn--omecompany-l2i[.]com) pourrait tirer parti de ce bogue et envoyer des e-mails de phishing convaincants aux employés de ‘somecompany.com’ qui utilisaient Microsoft Outlook pour Windows. »
Par coïncidence, le lendemain, un autre rapport sur le sujet a émergé de Mike Manzotti, consultant senior chez Dionach. Pour un contact créé sur le domaine « onmìcrosoft.com » de Manzotti (notez le je), Outlook affichait les coordonnées valides de la personne dont l’adresse e-mail contenait le véritable domaine « onmicrosoft.com ».
« En d’autres termes, l’e-mail de phishing cible l’utilisateur NestorW@….onmjecrosoft.com, cependant, les détails Active Directory valides et l’image de NestorW@….onmicrosoft.com sont affichés comme si l’e-mail provenait d’une source fiable », explique Manzotti.
Manzotti a retracé la cause du problème dans le fait qu’Outlook ne validait pas correctement les adresses e-mail dans les en-têtes MIME (Multipurpose Internet Mail Extensions).
« Lorsque vous envoyez un e-mail HTML, vous pouvez spécifier l’adresse SMTP « de » et l’adresse Mime « de »», explique Manzotti.
« C’est parce que les en-têtes MIME sont encapsulés dans le protocole SMTP. MIME est utilisé pour étendre des messages texte simples, par exemple lors de l’envoi d’e-mails HTML », a-t-il expliqué avec une illustration :
Mais, selon Manzotti, Microsoft Outlook pour Office 365 ne vérifie pas correctement le domaine punycode, laissant un attaquant usurper l’identité de tout contact valide dans l’organisation cible.
IDN phishing : un vieux problème ressuscité
Le problème des sites Web de phishing basés sur les IDN a attiré l’attention en 2017 lorsque le développeur d’applications Web Xudong Zheng a démontré comment les navigateurs modernes, à l’époque, n’a pas réussi à distinguer le sien apple.com site similaire (un IDN) du vrai apple.com.
Zheng était concerné que les IDN pourraient être abusés par des attaquants à diverses fins néfastes telles que le phishing :
Du point de vue de la sécurité, les domaines Unicode peuvent être problématiques car de nombreux caractères Unicode sont difficiles à distinguer des caractères ASCII courants. Il est possible d’enregistrer des domaines tels que « xn--pple-43d.com », qui équivaut à « apple.com ». Cela n’est peut-être pas évident à première vue, mais « apple.com » utilise le cyrillique « а » (U+0430) plutôt que l’ASCII « a » (U+0061). C’est ce qu’on appelle une attaque par homographe.
Mais le problème dans Outlook est que pour un e-mail de phishing envoyé depuis un IDN, le destinataire peut non seulement ne pas faire la distinction entre l’adresse e-mail usurpée et la vraie, mais aussi voir la carte de contact d’un contact légitime, donc victime de l’attaque .
On ne sait pas si Microsoft est enclin à résoudre le problème dans Outlook pour le moment :
« Nous avons fini d’examiner votre cas, mais dans ce cas, il a été décidé que nous ne corrigerions pas cette vulnérabilité dans la version actuelle », a déclaré un membre du personnel de Microsoft. DobbyWanKenobi dans un e-mail.
« Bien qu’une usurpation d’identité puisse se produire, l’identité de l’expéditeur ne peut pas être fiable sans une signature numérique. Les modifications nécessaires sont susceptibles de provoquer des faux positifs et des problèmes d’autres manières », poursuit l’e-mail vu par Ars :
Microsoft n’a pas répondu à la demande de commentaires d’Ars envoyée à l’avance.
Les chercheurs ont constaté que cette vulnérabilité affectait à la fois les versions 32 bits et 64 bits des dernières versions de Microsoft Outlook pour Microsoft 365, bien qu’il semble que le problème n’était plus reproductible sur la version 16.0.14228.20216 après que Manzotti a informé Microsoft.
Curieusement, la réponse de Microsoft à Manzotti a maintenu que la vulnérabilité ne serait pas corrigée. De plus, Manzotti note que ce type d’attaque de phishing ne réussira pas sur Outlook Web Access (OWA).
Tirer parti des fonctionnalités de sécurité telles que « expéditeur externe » Les avertissements par e-mail et la signature d’e-mails sont quelques étapes que les organisations peuvent suivre pour dissuader les attaques d’usurpation d’identité.
