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

MISC

n°

mars 2017

Par

Matos Jérémy

Sécurité réseau

Tag(s)

Man-in-the-Middle

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.

private boolean updateContactName(String phone, String newName) {
ArrayList<ContentProviderOperation> ops = new ArrayList<ContentProviderOperation>();

ops.add(ContentProviderOperation.newUpdate(ContactsContract.Data.CONTENT_URI)

.withSelection(ContactsContract.CommonDataKinds.Phone.NUMBER + "=?",

new String[{String.valueOf(phone)})

.withValue(ContactsContract.CommonDataKinds.StructuredName.DISPLAY_NAME, newName)

.build());

try {

getContentResolver().applyBatch(ContactsContract.AUTHORITY, ops);

return true;

} catch(Exception e) {

Log.e("Error", "encountered", e);

}

return false;

}
<uses-permission android:name="android.permission.READ_CONTACTS" />

<uses-permission android:name="android.permission.WRITE_CONTACTS" />

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.

4. Le fond du problème

Nous venons de montrer qu’il est relativement aisé de monter une attaque de type homme du milieu via les contacts et une application complice. Et cela en n’exploitant aucune faille de type 0-day dans le système d’exploitation !

La conversation est toujours parfaitement chiffrée de bout en bout, mais il n’est simplement pas évident de savoir avec qui l’on dialogue vraiment. La problématique de l’authentification de l’interlocuteur est totalement négligée (cf. deuxième hypothèse du paragraphe 1), alors qu’elle est fondamentale pour qui veut avoir un échange de messages sécurisé.

On accorde une confiance bien trop grande aux informations stockées dans le carnet d’adresses, alors qu’elles devraient être fournies ou au moins validées explicitement par l’utilisateur pour rester sous son contrôle.

Le principe du Trust On First Use (TOFU) est utilisé pour accepter automatiquement une nouvelle clé lors du dialogue avec un nouveau contact, alors qu’il s’agit d’un évènement rare nécessitant un regain de vigilance. Le message de WhatsApp expliquant à ce moment-là qu’une conversation sécurisée démarre est très maladroit de ce point de vue.

5. Évaluation du risque

Avant d’aller plus loin, procédons à une rapide évaluation du risque pour être bien d’accord sur la gravité de la situation.

Nous utiliserons une méthodologie élémentaire de calcul du risque selon le tableau ci-dessous. Nous considérons que le risque est le produit de la difficulté de l’attaque par son impact sur les utilisateurs.

Difficulté de l’attaque	Faible impact utilisateur	Impact utilisateur modéré	Fort impact utilisateur
Faible	Faible	Modéré	Très élevé
Moyenne	Faible	Modéré	Élevé
Élevée	Faible	Faible	Modéré

La difficulté de l’attaque peut s’évaluer à travers 2 dimensions :

Difficulté technique : Faible
L’implémentation de l’application Pierre – Feuille – Ciseau est aisée : il suffit de modifier les contacts à travers l’API disponible et de faire des appels type web service vers un serveur.
L’application sera acceptée sans souci pour publication puisque le code malveillant est stocké sur le serveur de l’attaquant.
Difficulté logistique : Moyenne
Un seul numéro de téléphone suffit à Ève pour intercepter des milliers de conversations.
Mais il faut convaincre suffisamment de personnes d’installer l’application Pierre / Feuille / Ciseau. L’accès au carnet d’adresses permet d’accélérer l’adoption en faisant automatiquement la promotion du jeu auprès de tous les contacts.

L’impact utilisateur s’estime plus simplement comme Fort.
En effet, des milliers d’utilisateurs peuvent être espionnés à travers les trois applications de messageries, ce qui brise la promesse d’échanges sécurisés. De plus, à cause des identifiants qu’elles laissent traîner dans le carnet d’adresses, il est possible de savoir quelles applications de messagerie sont installées.

En croisant un fort impact et une difficulté faible à moyenne, nous obtenons un risque élevé à très élevé.

De nombreuses attaques similaires sont imaginables, notamment en ciblant les spécificités d’implémentation de chaque application de messagerie. Des utilisations abusives à des fins de spear phishing sont envisageables, mais aussi de spam étant donné que les serveurs de messagerie ne peuvent plus filtrer le contenu des messages puisqu’ils sont indéchiffrables pour eux.

Nous nommerons désormais Man In The Contacts cette famille d’attaque exploitant l’accès aux contacts des applications mobiles.

6. La responsabilité des éditeurs

6.1 Pourquoi devraient-ils adresser ce point ?

Bien qu’il ne s’agisse pas d’une vulnérabilité purement technique, le risque est malgré tout réel pour les utilisateurs finaux. À aucun moment nous ne pouvons considérer qu’ils ont une mauvaise hygiène sécurité : l’application est téléchargée depuis le magasin officiel et a été approuvée, les mises à jour sont effectuées régulièrement.

À première vue, le système d’exploitation mobile est responsable de la faible segmentation de l’accès aux données de contact. Mais ce n’est pas une raison pour ne pas adresser cette faiblesse. Le principe même du reste de l’application est de construire une solution sécurisée sur des bases avérées fragiles (réseaux hostiles, serveurs perquisitionnés, etc.). Il serait étonnant de ne pas vouloir se soucier de l’authentification des utilisateurs.

Ce protocole cryptographique d’une grande rigueur a été mis en place suite aux révélations de Snowden. Il permet notamment de se dédouaner de toute demande d’accès par les autorités. On pourrait s’interroger, en constatant que l’application mobile est implémentée avec une plus grande légèreté (cf. hypothèse 2 du paragraphe 1), s’il ne s’agit pas là de la motivation principale, en complément d’un argumentaire marketing rassurant.

Dans tous les cas, la confiance de l’utilisateur devrait être respectée. En effet, on lui promet explicitement que sa conversation est sécurisée de bout en bout. Peu importe les limitations de la plateforme, des solutions doivent être trouvées pour tendre vers cet objectif.

6.2 Le retour des éditeurs

Il n’a pas été aisé d’obtenir un retour des éditeurs. Les programmes de Bug Bounty se généralisent, mais ni WhatsApp, ni Telegram, ni Signal n’en faisaient partie en 2016.

Telegram dispose d’un très réactif support de premier niveau à travers son application mobile. Une adresse mail sécurité a été fournie et le descriptif de l’attaque détaillée au paragraphe 3.3 y a été envoyé. Malgré 3 relances et une publication sur Twitter, aucune réponse n’a jamais été reçue.

WhatsApp dispose du programme de remontée de bugs de sa maison mère, Facebook. Malgré un acquittement rapide, une relance a dû être nécessaire pour obtenir la réponse ci-dessous (traduite de l’anglais) :
« Nous apprécions votre rapport. Au final un attaquant avec un malware installé sur son périphérique sera capable d’altérer les données du périphérique lui-même. Dans vos exemples les conversations WhatsApp sont restées correctement liées à leurs numéros de téléphone. De plus, WhatsApp autorise les utilisateurs à définir des alias locaux pour les contacts et à voir le numéro associé à un message spécifique à n’importe quel moment. Cela étant, nous ne considérons pas que ce comportement pose un risque significatif et nous ne prévoyons pas de faire de changement. Veuillez nous informer si vous pensez que nous avons mal interprété quelque chose ! »
Il n’a pas été possible de continuer la conversation, malgré la proposition en dernière ligne.

Signal ne disposant pas d’un processus connu de déclaration d’incident, un rapport de bug dans l’application Android a été soumis, mais non suivi d’effets malgré plusieurs relances. Une publication sur Twitter et un peu d’insistance ont permis d’obtenir successivement le message suivant (traduit de l’anglais) :
« Comme pour toutes les techniques d’interception, les numéros de sécurité ont été conçus pour cela. Les utilisateurs de Signal seront notifiés que les numéros de sécurité pour leurs contacts ont changé, et seront amenés à les vérifier. Une attaque d’homme du milieu réussie nécessiterait de trouver une méthode pour intercepter les communications sans déclencher cet avertissement ».

Après avoir fait remarquer que les numéros de sécurité ne s’appliquent pas à une nouvelle conversation avec un nouveau contact, cette brève réponse a été obtenue :
« Signal n’a pas été conçu pour se protéger des malwares. Merci d’être entré en contact, bonne chance avec tout le reste ».

Il est évident qu’il ne s’agit pas d’une vulnérabilité nécessitant seulement la modification de quelques lignes de code, mais au contraire qui exige de repenser l’expérience utilisateur. Cependant un peu plus de considération était attendue, en tenant compte de ce qui a été discuté au paragraphe 6.1

7. Contremesures

7.1 Utilisateur final

Il s’agira tout d’abord de réduire au maximum le nombre d’applications ayant accès aux contacts, surtout en écriture. Mais en pratique cela n’est guère évident, notamment sur les versions les plus répandues d’Android qui ne demandent les permissions qu’au moment de l’installation.

Ensuite il faut être vigilant quand une nouvelle conversation débute. En cas de suspicion, ne pas hésiter à jeter un coup d’œil dans ses contacts.

Enfin, d’autres applications de messagerie sécurisée existent, comme Threema [8]. Avec un authentifiant décorrélé du numéro de téléphone et une synchronisation optionnelle des contacts, cette solution est bien plus robuste d’un point de vue conception. D’autant plus qu’une réponse technique claire et détaillée a été fournie sous 24 heures par le service de presse.

Un niveau de confiance vert/orange/rouge affiché est aussi clairement affiché à côté du nom de l’interlocuteur, l’utilisateur se rendant aisément compte d’une situation anormale.

7.2 Applications de messagerie mobile

Un identifiant dédié, indépendant du numéro de téléphone, devrait être utilisé. Et une approbation explicite de chaque ajout de contact demandée à l’utilisateur.
Ou a minima gérer le risque en avertissant l’utilisateur lorsqu’il s’agit du tout premier échange avec un nouveau contact.

Afficher le numéro de téléphone peut également aider, même si seulement une minorité des numéros sont connus par cœur par l’utilisateur.

7.3 Systèmes d’exploitation mobile

L’amélioration la plus souhaitable serait de mettre en œuvre un véritable partitionnement des informations de contact, comme c’est le cas pour les accès aux fichiers, pour être capable de gérer une notion de données privées.