Présentation de l’attaque Man In The Contacts pour piéger les utilisateurs de WhatsApp, Signal et Telegram – Partie 1/2

L’année 2016 a marqué l’essor du chiffrement de bout en bout pour les messageries mobiles, avec notamment l’activation d’un tel protocole pour WhatsApp en avril. Mais aussi avec l’engouement autour de l’application Signal suite aux recommandations d’Edward Snowden [1]. Véritable progrès pour la vie privée de ses utilisateurs, c’est son utilisation supposée par des groupes terroristes qui a fait les grands titres des médias. C’est ainsi que Bernard Cazeneuve a mentionné l’application Telegram lors d’un déplacement à Berlin le 23 août 2016, en déclarant vouloir « armer véritablement nos démocraties sur la question du chiffrement » [2].

1. Un chiffrement inviolable ?

Vouloir légiférer sur ce sujet laisse entendre qu’il n’y a pas de moyen de contournement technique connu et que ce chiffrement est inviolable. C’est ce que conclut un papier académique publié en octobre 2016 et intitulé « Une analyse formelle de la sécurité du protocole de messagerie Signal » [3]. Il est utile de noter que ce protocole est utilisé à la fois par les applications Signal et WhatsApp, Telegram ne communiquant strictement aucun détail d’architecture ou d’implémentation.

Mais il est primordial de mettre en exergue deux hypothèses de cette démonstration formelle :

  • « Signal, qui est désormais le nom à la fois d’une application de messagerie instantanée et du protocole cryptographique. Dans le reste de ce papier, nous discuterons du protocole cryptographique seulement » ;
  • « Les hypothèses de confiance sur le canal d’enregistrement ne sont pas définies ; Signal spécifie une méthode obligatoire pour les participants afin qu’ils vérifient les clés d’identification les uns des autres à travers un canal auxiliaire, mais la plupart des implémentations n’exigent pas une telle vérification avant que l’échange de messages puisse commencer. Sans cela, un serveur de distribution de clés indigne de confiance peut évidemment se faire passer pour n’importe quel agent. ».

Le modèle de menaces qui en résulte se concentre alors uniquement sur des scénarios considérant le réseau et/ou les serveurs de communication comme malveillants. Alors que les nombreuses révélations d’Edward Snowden prouvent que la NSA n’hésite pas à s’attaquer aux autres éléments plus faibles du système d’informations, la cryptographie est rarement le talon d’Achille. Sortir ces éléments du cadre de l’étude est une simplification théorique à des fins académiques, mais la conclusion obtenue ne peut dès lors plus s’appliquer à l’utilisation en pratique de ces applications de messagerie.

2. L’implémentation de l’application mobile est le maillon faible

2.1 Un processus d’enregistrement implicite peu robuste

Historiquement, WhatsApp a bouleversé le processus d’enregistrement pour une messagerie instantanée : il n’est plus nécessaire de créer un identifiant et un mot de passe pour se connecter, une authentification implicite via le numéro de téléphone est mise en place. Cela permet également de récupérer les contacts depuis le carnet d’adresses plutôt que de devoir ajouter les différents identifiants à la main. Telegram et Signal s’en sont ensuite inspirés, cette expérience utilisateur ayant convaincu les foules.

Mais la première implémentation a vite été reconnue en 2012 comme très peu sécurisée : les identifiants générés étaient hautement prévisibles [4]. Que de chemin parcouru en quatre ans avec le déploiement du chiffrement de bout en bout. Ou pas …

Cette mécanique a évidemment été améliorée et l’appartenance du numéro de téléphone est désormais vérifiée via l’envoi d’un SMS. Mais c’est un canal connu pour être vulnérable et en particulier pour un processus d’une telle sensibilité [5].

À aucun moment WhatsApp ne vérifie l’identité de l’utilisateur final. Elle se contente de mettre en relation des numéros de téléphone, ce qui permet d’utiliser des pseudonymes si on le souhaite. Cela veut donc dire qu’in fine WhatsApp délègue la responsabilité à l’utilisateur d’authentifier ses interlocuteurs.

2.2 Nécessité d’un modèle de menaces centré sur le smartphone

Une analyse de sécurité réaliste d’un point de vue de l’utilisateur exige donc de prendre ce point en considération et de centrer le modèle de menaces autour du smartphone.

Le diagramme en Figure 1 n’a pas vocation à être un modèle complet, mais à faire ressortir les briques fondamentales sur lesquelles s’appuient nos trois applications de messagerie instantanée.

Fig. 1 : Modèle de menaces centré sur le smartphone.

Le SMS est en dehors du cadre de notre étude, puisque déjà évoqué [5]. Nous ne discuterons pas non plus des sauvegardes.

Les échanges réseau chiffrés de bout en bout sont considérés comme robustes [3].

Les systèmes d’exploitation mobiles étant relativement modernes, ils ont introduit des fonctionnalités de bac à sable de plus en plus fiables. Chaque application est exécutée avec des droits restreints et ne peut accéder qu’à sa zone de stockage ou contrôler uniquement ses appels réseau.

Mais les contacts ne sont pas partitionnés sur ce modèle et une API officielle est disponible pour lire et modifier ces informations. Il suffit que l’application obtienne les permissions correspondantes. Voici un exemple de code permettant de modifier un nom de contact sous Android et les permissions nécessaires.

2.3 L’utilisation des informations de contact est plus subtile qu’il n’y paraît

En fonction de l’expéditeur ou du destinataire, un numéro de téléphone n’est pas forcément associé au même nom. Il n’y a donc pas de source fiable pour déterminer la correspondance entre les deux. D’autant plus qu’un des deux interlocuteurs est libre de changer la dénomination à tout moment dans son carnet d’adresses. Il est donc loin d’être évident pour le serveur de messagerie de savoir quel nom mettre dans la notification, le seul invariant étant le numéro de téléphone.

Certaines applications de messageries contournent partiellement le problème en stockant des identifiants supplémentaires dans les contacts à des fins de réconciliation, ce qui au passage nécessite les permissions en lecture et écriture.

Mais cela ne résout en rien la problématique de la confiance : le serveur ne peut à aucun moment considérer les informations de contact comme légitimes puisque l’utilisateur ou une de ses applications peut les modifier (contrairement au numéro de téléphone).

3. Présentation d’une nouvelle famille d’attaque : Man In The Contacts

Une étude a alors été menée sur la résilience de ces trois applications de messageries sécurisées face aux modifications intempestives de contacts. Avec comme point de vue central celui de l’utilisateur final.

Les premiers résultats ont été présentés au Crypto Village de la DEFCON en août 2016, puis en novembre 2016 à la CyberSecurity Conference d’Yverdon. De nombreuses captures d’écran sont disponibles à l’adresse [6] pour rendre plus visuels les trois scénarios décrits ci-dessous.

Pour simplifier l’étude, nous nous concentrerons sur l’échange de messages écrits entre deux interlocuteurs. Mais l’approche est généralisable à des conversations de groupe (en général plus délicates à gérer d’un point de vue distribution de clé) et éventuellement aux appels VOIP.

3.1 Permutation de deux contacts existants

La première étape consiste à observer le comportement des trois applications quand deux contacts sont permutés. Par exemple, une idée à retenir pour le 1er avril est d’intervertir sur le téléphone d’un ami le numéro de téléphone de sa compagne (Alice) et de sa mère (Ève).

Les captures d’écran en Figure 2 montrent qu’il n’est pas évident pour l’utilisateur final de détecter une si grossière supercherie.

Fig. 2 : Rendu visuel pour l’utilisateur victime d’une permutation de contacts.


Une nouvelle notification arrive avec un nom qui a l’air légitime, mais qui pourtant correspond au mauvais contact. En cliquant dessus, l’utilisateur est cependant redirigé vers une nouvelle conversation. Cependant le message de WhatsApp lui indiquant que la discussion est maintenant sécurisée de bout en bout peut lui octroyer un faux sentiment de confiance.

La conversation existante voit son identifiant changer (mais à des vitesses différentes en fonction des applications), ce qui n’est pas très discret. De plus, contrairement à WhatsApp et Telegram, Signal affiche le numéro de téléphone sous le nom de contact. Mais seulement sur la version Android, et pas iOS… La blague ne durera de toute façon pas très longtemps, au moindre coup de téléphone la voix ne correspondra pas.

3.2 Création d’un contact avec un nom très similaire

Pour rendre le scénario précédent plus crédible, nous allons étudier ce qu’il se passe lorsque l’on crée un nouveau contact avec un nom très similaire, par exemple « Alice» avec un espace devant le A majuscule. Quand la véritable Alice appellera, il n’y aura plus de problème de voix, car elle sera toujours associée au contact d’origine.

Les captures d’écran en Figure 3 montrent qu’il est impossible de distinguer l’espace préfixant le nom de contact.

Fig. 3 : Rendu visuel pour l’utilisateur victime d’un contact cloné avec un nom très similaire.

Même en utilisant une police différente, il serait très délicat de compter sur l’utilisateur pour remarquer une si subtile différence. Et filtrer certains caractères spéciaux ne suffirait pas, Unicode nous offrant un large éventail de possibilités pour produire un nom différent ressemblant comme deux gouttes d’eau à celui original. Le monde du Web a en fait la douloureuse expérience il y a une dizaine d’années avec des noms de domaine exotiques [7].

Il faut toujours convaincre l’utilisateur final de basculer dans une nouvelle conversation, ce qui correspond uniquement à cliquer sur la notification s’il n’a pas l’application de messagerie en plein écran. À partir de ce moment-là, il conversera avec la fausse personne, mais pourra continuer à recevoir des coups de téléphone et des SMS du contact légitime. Toutefois, le cerveau humain se rendra compte tôt ou tard d’une incohérence dans la conversation avec « Alice » ou de différences dans le style rédactionnel.

3.3 Attaque de type homme du milieu avec un nom de contact très similaire

Pour être le plus discret possible, l’idéal serait qu’Alice et Bob discutent réellement entre eux, mais à travers un contact relai pour monter une attaque du type homme du milieu (via Ève). Pour cela, il suffit comme précédemment chez Bob de créer « Alice » avec le numéro d’Ève, et de manière symétrique « Bob » chez Alice avec le numéro d’Ève. Ève s’emploiera ensuite à transférer les messages entre les vrais Alice et Bob, à travers les faux contacts « Alice » et « Bob » qui renvoient en fait chez elle.

La version web de ces trois applications de messagerie permet de mettre en œuvre plus facilement ce scénario, avec par exemple une extension de navigateur qui permettra avec un effort de développement raisonnable de transférer automatiquement les messages reçus de Bob à Alice et vice versa.

La figure 4 est une illustration obtenue avec WhatsApp, les résultats sont parfaitement similaires avec Telegram ou Signal.

Fig. 4 : Mise en œuvre d’une attaque Man In The Middle en créant un contact de nom similaire chez les deux victimes Alice et Bob.


Dans ces conditions, il est possible d’écouter du contenu en toute discrétion. Mais aussi de changer ou injecter certains messages avec parcimonie pour ne pas éveiller les soupçons. Et en somme de briser la raison d’être du chiffrement de bout en bout : faire que personne d’autre que les interlocuteurs ne puisse savoir ce qui est échangé.

Encore faut-il être capable de créer à distance des faux contacts et synchroniser les opérations. Avec ce qui a été évoqué au paragraphe 2.2, une application légitime peut se charger de ces deux actions sans grande difficulté.

Créons un jeu à dimension sociale comme prétexte à l’accès aux contacts – par exemple une version moderne de Pierre / Feuille / Ciseau. Cette application peut à sa guise appeler les APIs du carnet d’adresses et dialoguer avec un serveur pour planifier une attaque si elle voit qu’Alice et Bob sont liés. Il suffit qu’elle soit assez populaire pour être installée par Alice et Bob. La seule subtilité est de commencer une nouvelle conversation avec un sujet plausible pour les deux parties.

Jérémy Matos
Expert en sécurité applicative chez Securing Apps – jeremy.matos@securingapps.com

La seconde partie de cet article sera publiée prochainement sur le blog, restez connectés 😉

Retrouvez cet article (et bien d’autres) dans MISC n°90, disponible sur la boutique et sur la plateforme de lecture en ligne Connect !

Laisser un commentaire