Sécurité des terminaux mobiles – Partie 2/2

2.2 Compromissions

2.2.1 Attaques sur les échanges

Afin de tester la réelle résistance des applications de messagerie, nous montons un système d’interception des communications sécurisées. Celui-ci est composé d’un point d’accès permettant à notre plateforme cible de se connecter, d’un serveur DHCP, d’un serveur DNS (dnsmasq) et d’un proxy HTTPS (mitmproxy).

Fig. 2 : Schéma du dispositif utilisé pour les attaques HTTPS.


Le serveur DHCP envoie l’adresse du serveur DNS lors de la connexion au point d’accès. Les règles de routage permettent d’orienter tout le trafic sur le proxy HTTPS. Selon les besoins, le serveur DNS redirige la requête vers un serveur qui nous appartient.

Grâce à ce dispositif, nous pouvons tester trois attaques :

  • le man-in-the-middle SSL/TLS  : cette attaque consiste à établir une connexion avec le client puis une connexion sécurisée avec le serveur et passer les données de l’un à l’autre en les espionnant ou les modifiant. Le serveur n’utilisant en général aucune authentification du client, cette connexion ne pose aucun problème. Le client cependant, authentifie le serveur. Il est donc nécessaire de générer un certificat au nom du serveur demandé. Ce certificat est donc signé par une autorité elle aussi générée.
  • l’imposture de serveur : l’attaque consiste à rediriger le trafic vers un serveur web nous appartenant. Ce site présente un certificat valide et certifié par une autorité racine reconnue, mais le domaine ne correspond pas à celui demandé. Ce montage permet de savoir si l’application vérifie la bonne adéquation entre le domaine demandé et celui présent sur le certificat présenté.
  • downgrade de connexion : l’attaque redirige le trafic vers un serveur non sécurisé (HTTP) en utilisant la fonction rewrite_url d’Apache. Nous testons ici si l’application requiert bien une connexion sécurisée.

Les deux dernières attaques s’avèrent négatives sur toutes les applications testées. En effet, celles-ci s’appuyant sur le framework commun, elles délèguent la sécurité HTTPS.

La première attaque peut être réalisée avec succès dans certains cas que nous allons détailler.

2.2.2 Compromission par ajout de certificat

Nous ajoutons notre certificat racine dans le magasin de certificat (Android et iOS). Nous notons qu’Android 6.0.1 affiche une alerte permanente qui prévient l’utilisateur que le réseau peut être surveillé.

L’insertion d’un certificat est relativement aisée. Il suffit de le télécharger puis de l’accepter lorsque reçu par mail par exemple. MITMProxy embarque même une interface ergonomique permettant de le faire rapidement et simplement en se connectant sur mitm.it lorsque le proxy est actif.

Même si notre certificat racine est considéré comme fiable, plusieurs applications comme Facebook Messenger ou Snapchat refusent la connexion.

Elles embarquent en effet leur propre magasin de certificats afin de ne pas dépendre du magasin de la plateforme et peuvent donc être plus restrictives.

2.2.3 Compromission de l’application

Pour espionner le trafic, il est donc nécessaire d’ajouter notre certificat aux stores d’applications. Le fichier CACertlist.plist contient par exemple les autorités de confiance de Facebook sur iOS. Signal-Android  embarque des fichiers .store contenant des certificats. L’accès à ce fichier nécessite néanmoins des droits privilégiés et par conséquent une compromission du système ou de l’application elle-même.

Telegram n’accepte toujours pas les connexions. En inspectant les sources, nous trouvons que celles-ci contiennent les clés publiques des serveurs codées en dur.

Fig 3 : Clé publique Telegram : https://github.com/DrKLO/Telegram/blob/master/TmessagesProj/jni/tgnet/Datacenter.cpp.


2.2.4 Compromission de certificats racines

Les applications Telegram ou Signal n’embarquent que quelques certificats de confiance. A contrario, Facebook embarque une bonne centaine de certificats. On peut y retrouver des certificats racines gouvernementaux :

Ces certificats étant considérés comme de confiance, tous les certificats signés par eux seront également considérés comme sûrs. Il devient donc possible de signer un domaine *.google.com, *.facebook.com ou *.whatsapp.com. Ainsi, un proxy SSL disposant d’un tel certificat est capable d’intercepter le trafic sans alerter les parties.

Nous ajoutons dans le magasin de l’application Facebook notre certificat d’autorité racine MITM. L’application accepte désormais les connexions à notre MITMProxy et nous pouvons espionner tout le trafic. Aucune alerte n’est remontée par l’application qui se comporte normalement.

2.2.5 Récupération des tokens d’authentification

Afin de préserver l’expérience utilisateur, les applications ne demandent pas une authentification systématique de l’utilisateur. Le terminal stocke des identifiants de connexion ou plus précisément des tokens d’authentification pour obtenir une reconnexion automatique au service chaque fois que l’utilisateur ouvre l’application.

Ces tokens sont souvent stockés par les applications elle-mêmes, mais de plus en plus de terminaux fournissent des solutions plus sécurisées pour ces données, des keystores. Ces containers sont dans le meilleur des cas chiffrés avec le code utilisateur et avec une clé matérielle afin de prévenir toute récupération sans le passcode. Dans le pire des cas, les tokens voire les identifiants sont stockés en clair dans les keystores ou dans les bases de fonctionnement des applications.

Une fois ces tokens récupérés, il est possible de les utiliser via les API fournies par les services d’application soit directement, soit en se faisant passer pour l’application.

3. Interceptions

Les interceptions sont au cœur des polémiques de protection de la vie privée et de sécurité. Sont-elles possibles sur des applications de messagerie chiffrant de bout en bout ?

3.1 Groupes

Une première forme d’interception possible sur ce type de messagerie est les groupes. En effet, Telegram, Whatsapp ou Signal proposent de créer des groupes de conversations en invitant des contacts. Il suffit qu’un membre soit compromis pour que l’ensemble des conversations le soit, car même si le chiffrement est sécurisé, le message sera in fine déchiffré sur le terminal compromis.

3.2 Clone de SIM

La plupart des applications de messagerie demandent un numéro de téléphone comme identifiant principal lors de l’enrôlement. Ceci permet à un utilisateur de pouvoir reconfigurer sa messagerie lorsqu’il change de terminal, ceci sans interruption de service. Cependant, comme le démontre l’attaque de Positive Technologies dans Forbes [1], en usurpant le numéro de téléphone d’une cible, il est possible de configurer l’application pour utiliser le même identifiant et recevoir les messages qui lui sont destinés. Une simple vérification d’un code temporaire par message texte fait office d’authentification.

Le numéro de téléphone est considéré comme sûr, car lié à la carte SIM, elle-même élément de sécurité de l’opérateur. Cette carte, très bien protégée contient des clés secrètes permettant son identification sur le réseau et le chiffrement des échanges avec celui-ci. Son clonage intégral ne peut donc être réalisé que par le fondeur ou l’opérateur. Des attaques permettant l’accès et donc la copie des informations existent, mais elles sont extrêmement coûteuses en temps et en matériel.

Un autre moyen d’accéder à ces informations est de récupérer les clés de chiffrement chez les fondeurs. Une attaque de la NSA et du GCHQ ayant conduit au vol de millions de clés chez Gemalto a été révélée en 2015 [2].

3.3 Attaques sur SS7

Dans l’attaque de Positive Technologies [1], un élément essentiel du réseau est vulnérable. En exploitant cette vulnérabilité, ou en bénéficiant de complicités de personnes y ayant accès, il est possible de rediriger les échanges avec un numéro vers un autre terminal. Une fois cet accès établi, le deuxième terminal peut accéder aux conversations archivées.

3.4 Démo

Faisons un test simple basé sur l’attaque précédente. Prenons un téléphone A (captures supérieures sur la figure 4) sur lequel nous avons configuré notre messagerie Telegram grâce à notre numéro de téléphone et notre carte SIM. Prenons un deuxième terminal B, sur lequel nous installons l’application Telegram (captures supérieures sur la figure 4).

Pour la configuration, il est nécessaire d’entrer le numéro de téléphone de l’utilisateur. Ensuite, le mécanisme d’authentification est lancé. Dans notre cas, un code est envoyé sur l’application Telegram de l’appareil déjà connecté. Si cet appareil n’est pas connecté à Internet, un SMS est envoyé ou un appel est effectué.

Si le code temporaire entré est correct, l’application se connecte et a accès à toutes les conversations disponibles sur l’autre appareil.

Plus encore, tous les messages écrits ou reçus sur appareils sont mis à jour en temps réel sur l’autre appareil connecté, de manière transparente. La faille de sécurité repose donc ici sur la possibilité d’un accès physique ou à distance au terminal original en vue d’intercepter le code temporaire.

Fig. 4 : Exemple de configuration de l’application Telegram.


Conclusion

La sécurité des terminaux mobiles repose à la fois sur la sécurité du système embarqué et sur celle des applications. La cryptographie est largement utilisée pour contrôler l’authenticité et l’intégrité du code ou des serveurs ou pour garantir la confidentialité des données. Une infrastructure à clé publique est embarquée et est largement utilisée par le firmware, le système d’exploitation ou les applications.

Sur les plateformes haut de gamme Apple ou Android, les systèmes sont bien protégés et difficiles à compromettre. Néanmoins, il existe toujours des failles susceptibles de donner un accès super-utilisateur à un attaquant. Une fois le système compromis, il devient possible de compromettre les échanges, même sur des messageries sécurisées.

L’infrastructure à clé publique peut elle-même être une faille, car une autorité de certification racine bénéficie de la confiance pour signer tout certificat. Elle peut ainsi falsifier le certificat d’un domaine particulier et mettre en œuvre une attaque de type man-in-the-middle.

Enfin, les applications de messagerie stockent très souvent les données en ligne et il suffit de s’y connecter avec les bons identifiants pour récupérer voire écouter les conversations. Ces identifiants se résument dans la plupart des cas au numéro de téléphone et à un code temporaire envoyé par SMS. Par conséquent, un accès physique au téléphone de la cible permet de récupérer ce code et connecter un autre appareil sur le compte qui pourra récupérer les archives et recevoir les messages.

Références

[1] http://www.forbes.com/sites/thomasbrewster/2016/06/01/whatsapp-telegram-ss7-hacks/#65c4d43a745e
[2] http://bgr.com/2015/02/20/nsa-sim-card-hacking/

Matthieu REGNERY
Institut de Recherche Criminelle de la Gendarmerie Nationale

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