Une vulnérabilité de clickjacking dans WhatsApp permet des attaques de phishing

• Une vulnérabilité de phishing a été découverte dans WhatsApp : un message peut afficher un lien et un aperçu semblant pointer vers un site légitime, alors que le clic réel envoie vers le site de l’attaquant
• La cause tient au fait que le lien dans le corps du message et les données d’aperçu sont envoyés séparément, et qu’en supprimant matchedText, il est possible de créer une discordance d’aperçu
• Le caractère U+202E Right-To-Left Override inverse le sens d’affichage d’une URL, ce qui peut faire ressembler le domaine réel à un domaine légitime
• Un attaquant peut préparer un domaine miroir de la cible usurpée, conserver l’aperçu du site d’origine, puis modifier uniquement la valeur text pour tromper la victime
• Meta a répondu pouvoir ajuster dynamiquement la logique de normalisation des URL ; les utilisateurs devraient copier les liens avant de cliquer afin de vérifier l’adresse réelle

---

Le point où l’aperçu de lien WhatsApp et le lien réel se séparent

• Le chercheur a envoyé un lien webhook.site à un ami afin de vérifier si le destinataire d’un message WhatsApp déclenchait une requête HTTP en rendant l’aperçu du lien
• La requête HTTP ne s’est produite qu’une seule fois côté expéditeur, confirmant que le destinataire ne rendait pas séparément le lien
• En raison de ce comportement, il a supposé que les messages WhatsApp étaient envoyés avec à la fois le lien et les informations d’aperçu, puis a testé s’il était possible de les rendre différents

Issue #1 : discordance de l’aperçu de lien

• Il a tenté de modifier directement un message WhatsApp Web via un proxy, mais l’E2EE de WhatsApp rendait difficile une altération simple avec des outils comme Burp Suite
• À la place, il a placé un point d’arrêt dans le JavaScript juste avant que le message ne soit chiffré et envoyé via WebSocket, afin d’inspecter l’objet du message
• L’objet du message contient le corps du lien et les informations d’aperçu sous forme de propriétés distinctes
  • text : corps du message
  • canonicalURL : domaine affiché en bas de l’aperçu
  • matchedText : semble être une valeur comparée à canonicalURL, et un test vérifie si cette valeur apparaît aussi dans text
• Dans un objet de message pour instagram.com, remplacer text par google.com fait disparaître l’aperçu et ne laisse que le lien Google
• En supprimant la propriété matchedText, il a été possible de créer un message discordant dont le lien réel et l’aperçu diffèrent

Issue #2 : camouflage de l’affichage du lien avec U+202E

• Pour éviter que le corps réel du lien soit visible, il a fuzzé des caractères Unicode afin de voir s’ils modifiaient l’affichage du texte
• U+202E est un caractère Right-To-Left Override, qui force l’affichage du texte en ordre inversé pour l’utilisateur
• Utiliser simplement U+202E donnait un lien d’apparence étrange, avec une faible probabilité de clic ; il fallait donc construire une chaîne inversée qui ressemble à une URL normale

Méthode de construction de l’URL miroir

• L’objectif était de créer une URL qui, une fois inversée, ressemble à https://instagram.com
• La chaîne simplement inversée devient moc.margatsni//:sttph, mais un TLD comme .margatsni ne peut pas être enregistré
• La solution consiste à utiliser un TLD réellement enregistrable comme s’il s’agissait d’un sous-domaine
  • Par exemple, avec le TLD néerlandais .nl, on peut créer une chaîne qui ressemble à ln.instagram.com
• Comme l’URL doit sembler commencer par https://, il faut ajouter à la fin le chemin valide //:sptth
• Au final, https://moc.margatsni.nl//:sptth, combiné à U+202E, peut apparaître comme https://ln.instagram.com//:sptth
• Le chercheur appelle cette méthode 2K2E

Déroulement de l’attaque

• L’attaquant achète un domaine miroir du site qu’il veut usurper
  • Exemple : pour le faire ressembler à ln.instagram.com, il achète moc.margatsni.nl
• Il crée d’abord un message contenant le lien du domaine d’origine afin d’obtenir l’aperçu de ce site
  • Dans l’objet d’exemple, text, matchedText et canonicalUrl valent tous https://instagram.com/
  • Des valeurs liées à l’aperçu, comme description, title, jpegThumbnail et thumbnailDirectPath, sont également incluses
• Ensuite, il supprime matchedText et remplace la valeur text par une forme comme \u202ehttps://moc.margatsni.nl//:sptth
• Le message final affiche l’aperçu d’Instagram, mais au clic il peut rediriger vers le domaine préparé par l’attaquant

Réponse de Meta et comparaison avec d’autres plateformes

• Meta a répondu que, comme l’entreprise prend en charge plusieurs plateformes et environnements, la normalisation des URL propre à chaque plateforme peut différer de la logique côté serveur
• Elle a indiqué disposer d’un système capable d’ajuster dynamiquement la logique de normalisation des URL lorsque du spam et des abus réels se produisent
• Le chercheur estime que Meta semble vouloir réagir seulement lorsque son système détecte du spam, plutôt que de résoudre activement ce problème de sécurité
• X, TikTok et Pinterest appliquent un nettoyage du caractère U+202E, contrairement à WhatsApp

Mesures d’atténuation vérifiables par l’utilisateur

• Les liens WhatsApp sont difficiles à considérer comme fiables sur la seule base de leur apparence affichée
• Pour éviter le phishing 2K2E, il faut copier le lien avant de cliquer et vérifier l’adresse réelle dans l’aperçu du presse-papiers
• L’aperçu du presse-papiers peut afficher l’adresse du lien après nettoyage du caractère U+202E
• Le chercheur a ensuite découvert d’autres services vulnérables à 2K2E faute de nettoyage approprié

[GN⁺]

Avis sur Hacker News

• C’est une combinaison assez astucieuse de détournements de fonctionnalités, mais je considérerais que l’impact global sur la sécurité reste faible
  Dans le meilleur des cas, cela revient à pousser le destinataire à ouvrir un lien dans son navigateur ; à moins que l’attaquant ne soit la police ou un service de renseignement, il faut généralement une attaque de suivi exploitant un logiciel non corrigé sur l’appareil
  Techniquement, il est difficile d’appeler cela du clickjacking. Le clickjacking désigne d’ordinaire une technique très précise qui consiste à superposer une frame HTML invisible au-dessus d’un autre contenu
  https://owasp.org/www-community/attacks/Clickjacking
  https://portswigger.net/web-security/clickjacking

  • Moi non plus, je n’appellerais pas ça du clickjacking. Le vrai clickjacking consiste à faire effectuer à la victime, à son insu, une action liée à son compte ; le simple fait d’ouvrir un lien non prévu n’est pas aussi grave
  • Si ce lien affiche un écran de connexion identique à celui d’Instagram, quel pourcentage d’utilisateurs, après avoir été trompés une première fois par l’aperçu WhatsApp, ira vraiment revérifier l’URL ?

• Tout le monde se focalise sur les caractères UTF de droite à gauche, mais Meta aurait au minimum dû reconnaître le problème : l’URL de l’aperçu peut différer de l’URL du message
  Je comprends que ce comportement serve à déplier les URL raccourcies, mais Meta et WhatsApp pourraient sûrement implémenter une parade intelligente

  • Non. Avec le chiffrement de bout en bout, l’aperçu doit être généré côté expéditeur ou côté destinataire. Si c’est le destinataire qui le génère, son IP fuit. Au final, il faudrait supprimer la fonction d’aperçu

• Le clickjacking, c’est quand on pense cliquer sur un élément mais qu’en réalité un autre élément, généralement transparent et superposé, intercepte l’événement de clic
  Si l’on donne le focus à la couche visible du dessous et qu’on détecte le déclenchement de l’événement onblur, l’attaquant peut savoir qu’il y a eu un clic même si l’utilisateur ne reçoit pas l’événement
  Ce qu’a trouvé l’OP est excellent, mais ce n’est pas du clickjacking. Moi aussi, autrefois, j’ai utilisé des caractères RTL pour faire passer un fichier d’écran de veille — autrement dit, sous Windows, un exécutable ordinaire avec une autre extension — pour un document Word. C’était sans doute pour faire une blague à des amis ou à des profs, mais je ne me souviens plus très bien pourquoi
  L’OP est allé plus loin en trouvant un moyen de faire varier l’affichage selon le système. Il ne s’agit pas de faire croire à l’utilisateur qu’il clique sur un autre élément, mais de lui faire croire que le lien mènera ailleurs ; ce n’est donc pas du clickjacking, et la page Wikipedia citée au début de l’article le confirme aussi
  Je n’ai jamais vraiment vu le clickjacking exploité en pratique, mais je pense que la méthode trouvée par l’OP pourrait l’être
  Honnêtement, j’ai renoncé depuis longtemps à l’idée que les utilisateurs puissent distinguer le domaine final quand ils cliquent sur un lien. La grande majorité ne comprend même pas le concept, et pour les autres c’est aussi difficile
  Même ceux qui pensent savoir faire finissent découragés quand tous les liens pointent vers des choses du genre sendgrid.tld/j3ovi3bfogobbledypoop93jnri2o. Nous entraînons chaque jour les gens à cliquer sur des liens louches, obscurcis pour le tracking, et personne ne s’en soucie

• C’est un hack élégant. Le vrai problème n’est pas WhatsApp ni les caractères Unicode inversant le sens d’écriture, mais le fait que les URL sont difficiles
  Même un exemple simple comme visa.securesite.com trompe beaucoup de monde. Je ne vois pas de bonne solution à court terme

  • Dans ce cas précis, comme l’interface induit activement l’utilisateur en erreur lorsqu’il essaie de comprendre sur quoi il clique, cela relève plutôt d’une mauvaise sanitisation
    La confusion générale autour des noms d’hôtes et des domaines est un problème plus difficile, mais les navigateurs ont essayé de l’atténuer dans une certaine mesure, par exemple en mettant en évidence la partie correspondant au nom de domaine. Comme pour la plupart des techniques de phishing, je pense que les passkeys finiront par y mettre un terme

• Le RTL a été une source énorme de failles de sécurité pendant toute son existence. Je ne comprends pas pourquoi les systèmes d’exploitation ne proposent pas un réglage pour désactiver tout le RTL, afin que les personnes qui ne connaissent pas ces langues ne soient pas exposées à des risques sans aucun bénéfice

  • Indépendamment du système d’exploitation, tous les widgets d’OS qui affichent du texte devraient proposer cette option. Cela inclut le TextView d’Android
    Par défaut, tous les contournements de texte bidirectionnel devraient être désactivés, sauf si le développeur examine et autorise explicitement une plage de texte donnée
    Cela n’a aucun sens de rendre toute la pile de rendu de texte vulnérable par défaut au nom de la prise en compte de moins de 1 % de la population mondiale

• Il est décevant que Meta ne corrige pas ce problème et ait décidé de ne pas verser de bug bounty à ce chercheur

  • J’ai signalé un problème similaire à Google plus tôt cette année, mais ils l’ont rejeté au motif qu’il « ne peut se produire que par ingénierie sociale » et qu’« ils ne pensent pas qu’une correction rendrait les utilisateurs significativement moins vulnérables »
    Je n’entrerai pas dans les détails ici, mais à cause de la manière dont Google Search réécrit parfois les URL, un attaquant peut masquer l’URL réelle
    Il vaut mieux ne jamais faire confiance aux URL affichées par les sites web et les applications
  • Ils sont sans doute trop occupés à envoyer des menaces juridiques à des projets OSS
  • Il est possible que la demande de correction n’ait pas été formulée assez clairement — par exemple, bloquer les caractères RTL — et que Meta l’ait interprétée comme une demande de corriger toutes les URL trompeuses. C’est pratiquement impossible
  • Ils corrigeront le problème. Ils ne récompenseront simplement pas le chasseur de bugs

• Le fait que, « comme prévu, le lien et l’aperçu aient été envoyés séparément ! », est un problème plus large de conception d’UI. Pourquoi un utilisateur ordinaire devrait-il comparer le lien et l’aperçu pour rester en sécurité ?

  • C’est un compromis de sécurité. Pour fournir une fonctionnalité utile comme les aperçus de liens, il existe plusieurs options
    1. Les générer côté expéditeur. Inconvénient : ils peuvent être falsifiés
    2. Les générer côté destinataire. Inconvénient : l’IP du destinataire fuit
    3. Les générer via un tiers. Inconvénient : des informations fuient vers ce tiers
       Globalement, je pense que la première option est la meilleure. L’expéditeur peut de toute façon « falsifier » tous ses propres messages, et inclure l’aperçu comme partie du message n’est pas très différent
       Le problème ici est qu’il n’est pas clair que ce contenu vient de l’expéditeur. Comme il est affiché presque comme une bulle séparée, 99 % des utilisateurs ne se rendront sans doute pas compte que ce contenu est fourni par l’expéditeur
       En plus, l’URL est de toute façon l’élément clé. Si l’utilisateur clique sur une URL contrôlée par l’attaquant, celui-ci peut afficher ce qu’il veut dans l’aperçu. Le bénéfice à rendre l’aperçu « authentique » est donc très faible
       La troisième option peut aussi être acceptable, surtout si elle est implémentée avec une sorte de double aveugle : on contacte une première partie, qui relaie vers une seconde. Ainsi, la première voit l’IP et la seconde voit la destination, mais aucune ne voit les deux à la fois sauf collusion
       Cela dit, le bénéfice est relativement faible par rapport à l’infrastructure nécessaire à mettre en place et à maintenir

• J’aime bien le fait que l’article classe cela tout en bas dans la catégorie rétro-ingénierie

• Ce n’est pas du clickjacking. Le clickjacking consiste, pour un attaquant, à intercepter un clic afin que l’utilisateur clique réellement sur une autre cible que celle qu’il voulait ou pensait viser
  Les points de code RTL qui font circuler le texte de droite à gauche sont une fonctionnalité d’internationalisation, et les utiliser pour semer la confusion n’est pas une nouvelle vulnérabilité