Sécurité des terminaux mobiles

Une des principales préoccupations depuis les révélations de Snowden est le respect de la vie privée et des libertés et par conséquent la confidentialité des échanges. Les écoutes massives mises au jour ont effrayé de nombreux utilisateurs de téléphones mobiles. Pour les reconquérir, les fabricants et les éditeurs d'applications sécurisent de plus en plus les données stockées ainsi que celles échangées sur les réseaux.

Cette sécurité ne doit pas compromettre l'expérience utilisateur et donc la rapidité des échanges et la fluidité de traitement. Quelle sécurité est implémentée et à quel point est-elle fiable ?

1. Sécurité des systèmes

La première des protections réside dans le système lui-même, du firmware au système d'exploitation. Comment est garantie cette sécurité ? Comment la compromettre et quels sont les risques ?

1.1 Chaîne de confiance

Le code exécuté par le processeur du terminal est un des garants du fait que les opérations effectuées sont uniquement celles qui sont prévues par l'éditeur du système d'exploitation ou des applications s'exécutant. Afin de garantir que ce code est intègre, une chaîne de confiance est implémentée au démarrage des terminaux. Apple, par exemple, intègre un certificat dans la mémoire ROM (inaltérable) de ses processeurs. Exemple :

Ce certificat racine permet de vérifier l'intégralité de la chaîne de confiance pour tous les éléments de code signés avec des certificats eux-mêmes signés par celui-ci avant d'être exécutés. Ainsi Apple garantit que le code exécuté est le sien. La plupart des systèmes Android (Google, Samsung, LG, HTC…) ont également intégré une chaîne de confiance garantissant l'intégrité du code exécuté. Ces équipements peuvent néanmoins être facilement personnalisés, mais dès lors, un fusible de garantie anti-compromission est déclenché. Certaines applications sécurisées refusent alors de s'exécuter. C'est le cas par exemple de KNOX (Samsung).

Les mises à jour sont également signées et vérifiées afin qu'elles ne soient pas un vecteur de compromission. Enfin, iOS ou les dernières moutures du système Android (6.0.1 mise à jour postérieure à novembre 2016) empêchent les downgrade de système et par conséquent les attaques sur des vulnérabilités antérieures.

Enfin, les applications disponibles sur les magasins sont elles aussi signées, mais pas par l'éditeur du système d'exploitation. Les développeurs restent responsables des applications diffusées, et malgré les vérifications opérées par Google ou Apple, certaines sont malveillantes. Ce système garantit néanmoins que des applications très grand public comme Facebook, Twitter… ne sont pas compromises.

1.2 Vérification d’intégrité du système

Une fois le code vérifié, il est nécessaire de s'assurer que celui-ci n'est pas altéré au cours de l'exécution. Apple utilise plusieurs mesures de protection. La première, Kernel Patch Protection, vérifie périodiquement l'intégrité du kernel (certaines parties exécutées seulement) et empêche tout kernel modifié de s’exécuter. La deuxième est la signature et la vérification systématique des mises à jour qui empêchent un attaquant de modifier le système par ce biais.

Samsung a déployé un système similaire, TrustZone Integrity Measurement Architecture. Celui-ci réside dans la partie TrustZone, Trusted Execution Environment, permettant une exécution sécurisée au niveau matériel.

1.3 Chiffrement des données

Apple a chiffré son système jusqu'à la version 10 d'iOS. Ceci ralentissait la découverte de vulnérabilités en empêchant les chercheurs d'accéder au code. Le chiffrement garantissait également l'authenticité des données, celles-ci ne pouvant être déchiffrées que par un co-processeur cryptographique spécifique dans lequel la clé a été codée au niveau du silicium. Plusieurs contournements ont été trouvés permettant d'accéder au code déchiffré, en utilisant la fonction cryptographique sur un appareil compromis. Cependant, Apple a choisi de ne plus chiffrer complètement les mises à jour de son système d'exploitation, considérant sa chaîne de vérification suffisamment sûre.

La confidentialité des données utilisateur est également souvent assurée par le chiffrement. Sur les plateformes haut de gamme (Apple, Google ou Samsung), une clé spécifique à chaque appareil, combinée au mot de passe utilisateur permet de chiffrer les données. Pour attaquer le mot de passe, il est par conséquent nécessaire d'utiliser le terminal. Ceci implique un nombre d'essais illimités.

Cependant, sur bon nombre de plateformes Android, le chiffrement des données utilisateurs avec une clé dérivée du mot de passe n'est pas fait par défaut. Si Android Marshmallow impose le chiffrement par défaut, celui-ci est réalisé avec le mot de passe « default_password ». Le pin, pattern ou de mot de passe ne servant qu'à accéder à l'interface graphique. Samsung propose une option « Secure boot » permettant d'activer la fonctionnalité de chiffrement par dérivation du mot de passe.

Évidemment, sur les plateformes sécurisées, un accès système à l'insu de l'utilisateur permet d'accéder à l'ensemble des données lorsque le terminal est déverrouillé.

De même, certains mécanismes implémentés pour l'expérience utilisateur permettent de récupérer certaines données même si le terminal est verrouillé. C'est le cas des sauvegardes pour les iPhones par exemple si l'ordinateur sur lequel a été connecté le terminal est récupéré.

Enfin, beaucoup de données sont également sauvegardées dans le cloud. Il est alors uniquement nécessaire d'obtenir les identifiants de connexion afin d'y accéder. Ceci relève d'autres stratégies de pénétration.

1.4 Compromission

Malgré les mesures de protection décrites auparavant, des hackers ou des chercheurs ont réussi à compromettre les systèmes qui les implémentent.

Sur Apple, les jailbreaks permettent d'en contourner un certain nombre. La plupart des solutions publiques requièrent des actions explicites de la part de l'utilisateur, ce qui limite le risque de compromission de type Evil Maid.

Les applications sont exécutées dans des sandboxes, permettant d'isoler leurs données d'exécution et de stockage. Ainsi, une application ne peut en théorie pas agir sur les données d'une autre ou compromettre le système. Néanmoins certaines vulnérabilités ont permis de s'échapper de cette sandbox.

Certains éditeurs de solutions ont implémenté des attaques utilisant des remote exploits. Des traces de tels programmes ont par exemple été trouvées dans la fuite de données de Hacking Team en juillet 2015.

Une fois le système compromis, beaucoup d'attaques deviennent possibles, notamment l'exfiltration des données personnelles stockées sur l'appareil. Néanmoins, selon le niveau de compromission, les données exposées ne sont pas les mêmes. Un accès complet au système permet la modification d'applications ou leur remplacement ainsi que l'interception complète des flux réseaux. Dans ce cas, plus aucune donnée ne peut être considérée comme sûre, notamment les échanges sur les messageries dites sécurisées, comme expliqué ci-dessous.

2. Sécurité des communications de données

Les différentes messageries sécurisées dépendent à la fois de la sécurité du système sur lequel elles sont installées, mais également de la chaîne de confiance qu'elles implémentent. Nous allons voir que cette chaîne est souvent de bonne qualité, mais certaines applications sont plus paranoïaques que d'autres.

2.1 Chiffrement et authentification des communications

2.1.1 Public Key Infrastructure

L'infrastructure à clé publique est la base de la chaîne de confiance des communications sécurisées. Pour rappel, une telle infrastructure fonctionne de la manière suivante :

 

 

Une autorité racine émet un certificat qu'elle signe elle-même. Elle peut ensuite signer des certificats pour des entités subordonnées ou authentifier des données. La vérification s'effectue en vérifiant les signatures à chaque échelon. La sécurité repose par conséquent sur la confiance accordée à l'autorité racine et à la confidentialité de sa clé privée. En cas de fuite ou de vol, une autorité peut répudier les certificats qu'elle a signés, à condition que cette information puisse être diffusée et les certificats remplacés ou supprimés. Si c'est le certificat racine qui est compromis, alors c'est à l'utilisateur ou à l'éditeur qui l'embarque de le supprimer.

L'exemple le plus parlant d'une telle infrastructure est le magasin de certificats embarqué dans les navigateurs internet. Celui-ci contient les certificats des autorités racines qui permettent d'authentifier les sites web et sécuriser les échanges.

Cette infrastructure est appliquée de la même manière dans la sécurité mobile à la différence qu'elle s'étend à l'ensemble de la plateforme. En effet, chacune embarque également un magasin de certificats permettant l'authentification des échanges. L'authentification de code reste vérifiée par les seuls certificats des éditeurs de système d'exploitation.

Chaque application s'appuyant sur le protocole HTTPS et les communications standards fournies par les frameworks iOS ou Android utilise le magasin de certificat de la plateforme.

Un magasin de certificat est livré avec le système d'exploitation (exemple https://support.apple.com/en-us/HT204132). Cependant, des certificats peuvent également y être ajoutés. Certaines plateformes permettent également à l'utilisateur de ne plus faire confiance à un certificat livré par défaut.

2.1.2 Protocoles utilisés par les applications mobiles

Au-delà des protocoles de chiffrement spécifiques à chaque application, le transport est quasi-exclusivement assuré par HTTPS.

Les applications comme Facebook Messenger, Snapchat, WhatsApp ou Viber utilisent cette couche de transport. Elles utilisent le framework commun de la plateforme qui est régulièrement mis à jour. Les attaques par downgrade de connexion par imposture de serveur ne sont par conséquent plus possibles. Facebook lèvera par exemple une exception « Certificate Unknown » et Snapchat ne répondra qu'un « Close notify » sans détailler l'erreur.

Deux autres protocoles de communication sécurisés on fait leur apparition MTProto pour Telegram et Double Ratchet pour Signal. Ces deux protocoles utilisent des clés éphémères pour le chiffrement des messages et garantissent ainsi la Perfect Forward Secrecy. L'échange des clés est basé sur un échange Diffie-Hellman qui permet d'éliminer les attaques de l'homme du milieu.

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).

 

 

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.

 

 

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.

 

 

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/