Analyser la géolocalisation sur iPhone grâce à un proxy de déchiffrement SSL

1. Les mystères de la géolocalisation sur iPhone

La plupart des smartphones ont une puce GPS, mais cette technologie est lente à démarrer et ne marche pas toujours bien en ville où à l'intérieur de bâtiments. C'est une tout autre approche qui est donc souvent utilisée pour fournir un service de géolocalisation sur ces dispositifs mobiles : la détection de points d'accès Wi-Fi (ou d'antennes GSM). Contrairement au GPS, cette approche nécessite une communication entre le téléphone et un serveur de géolocalisation spécialisé qui détient une base de données recensant la position géographique des points d'accès Wi-Fi. Ceci est possible, car chaque point d'accès Wi-Fi peut être identifié par un numéro unique : son adresse MAC ou « BSSID ».

Cette fonction de géolocalisation offerte par les smartphones entraîne des sentiments ambivalents. Pour beaucoup au quotidien, c'est à la fois un outil fantastique et potentiellement un dispositif de surveillance des déplacements qui inquiète.

Pour en témoigner, il suffit de se rappeler l'énorme buzz qu'avaient créé, fin avril 2011, deux universitaires britanniques [1] en mettant en lumière une base de données de géolocalisation utilisée par les iPhones d’Apple et sauvegardée sur le PC de l’utilisateur. Étrangement, la découverte initiale de ce fichier, attribuée à Sean Morrissey et Alex Levinson [2], datait de 2010 et était passée inaperçue à l’époque.

Cette base de données, appelée consolidated.db, recensait, rappelons-le, plus d'un an d'historique, plus ou moins précis, des déplacements des propriétaires d'iPhone. Apple a depuis corrigé le problème tout en affirmant que le contenu de ce fichier n'était jamais envoyé vers ses propres serveurs.

Une question demeurerait donc : quelles données de géolocalisation sont envoyées vers les serveurs d'Apple et comment ce mystérieux fichier a-t-il été constitué ? Pour tenter de répondre à ces questions, plongeons au cœur des communications de l'iPhone.

2. Déchiffrer des communications SSL/TLS

La première étape de cette expérience consiste à créer un point d'interception des communications entre un iPhone et Internet. Il y a plusieurs canaux pour y parvenir : l'OS de l'iPhone, la 3G/GSM ou le Wi-Fi. L'interception de communications 3G/GSM nécessite un matériel assez lourd, quant à l'installation d'un logiciel d'interception directement sur l'iPhone, cela implique des développements complexes et un « jailbreaking », ce que nous voulions éviter. L'option la plus simple est donc d'exploiter le canal Wi-Fi. Un point d'accès Wi-Fi ordinaire a donc été connecté à une machine Linux, elle-même équipée d'une deuxième carte réseau connectée à Internet par ADSL, comme illustré sur la figure 1.

 

 

Sur cette machine Linux, un proxy HTTP à été mis en place pour pouvoir intercepter les communications de l'iPhone. Premier constat : les requêtes de géolocalisation sont sécurisées par SSL/TLS. Ce proxy a donc dû être modifié pour intercepter ce type de communications. Il existait déjà des proxies qui étaient susceptibles de jouer ce rôle, par exemple mitmproxy [3] ou encore tcpcatcher [4]. Néanmoins, à l'époque de nos premières investigations, ils souffraient tous de certaines limitations qui nous ont amenés à développer notre propre outil dont le code source est disponible [5] sous licence GPL pour les lecteurs qui souhaiteraient répéter les expériences décrites dans cet article.

2.1. Le modèle d'authentification de SSL en question

Dans son utilisation la plus répandue, le protocole SSL/TLS est utilisé pour sécuriser des communications HTTP entre un client et un serveur. Il existe deux grandes familles d'attaques sur SSL/TLS : les attaques qui ciblent les mécanismes assurant la confidentialité des communications et celles qui s'attachent aux problématiques d’authentification des échanges.

Les attaques portant directement sur les mécanismes de confidentialité des communications sont rares, car le protocole SSL/TLS s'appuie sur des primitives cryptographiques éprouvées, même si l'on découvre parfois encore des failles dans la manière dont elles sont mises en œuvre [6]. C'est en jouant avec le modèle d’authentification de SSL/TLS que nous avons mis en place un outil susceptible d'intercepter des communications chiffrées entre un iPhone et les serveurs d'Apple.

Rappelons de manière simplifiée les principes d'authentification utilisés par SSL/TLS. Lorsqu'un client se connecte à un serveur www.serveur.com en SSL, le serveur lui présente sa clé publique, qui sert alors à initier une communication sécurisée. En effet, si une donnée envoyée par le client est chiffrée avec la clé publique du serveur, seul celui-ci pourra la déchiffrer. Bien sûr, ceci ne fonctionne que si le client est certain que la clé publique appartient bien au serveur www.serveur.com et non à un usurpateur. Cette assurance est fournie par un certificat envoyé également par le serveur. Ce certificat contient un lien entre la clé publique du serveur et son identité « www.serveur.com », le tout signé par une autorité de certification. Si le navigateur du client possède lui-même la clé publique de l'autorité de certification, il pourra vérifier la validité de la signature du certificat et par conséquent valider la clé publique du serveur.

Dans ce modèle, la confiance est donc déportée intégralement sur une autorité de certification. Si celle-ci est défaillante, la sécurité des communications n'est plus garantie. Ce fut le cas très récemment lorsque des hackers iraniens ont réussi à obtenir des certificats pour de nombreux sites, dont Google, auprès de l'autorité de certification Diginotar [7]. En effet, si l'on peut fabriquer un vrai-faux certificat, alors il est possible de réaliser une interception de type Man In The Middle. Nous reprenons ici cette idée : notre proxy intercepte les communications entre le client et le serveur, faisant croire d'une part au client qu'il est le serveur et d'autre part au serveur qu'il est le client. Le client et le serveur n'y verront que du feu !

2.2. Un « Man In The Middle »

Dans notre expérience, nous avons donc créé notre propre autorité de certification appelée « Proxy Certs Master » à l'aide d'OpenSSL[8] et nous avons installé son certificat racine dans le gestionnaire de profil de l'iPhone, comme le montre la figure 2. Nous avons également créé une bi-clé RSA serveur distincte pour le proxy lui-même, destinée à sécuriser ses échanges avec l'iPhone.

 

 

Ensuite, nous avons modifié notre proxy pour intercepter les demandes de connexion SSL entre clients et serveurs [9]. Typiquement, si un client souhaite se connecter à l'adresse https://www.serveur.com/, sa demande sera traitée selon les étapes suivantes par notre proxy :

- Étape 1 : Le client se connecte au proxy – on appellera cette connexion « CONNECTION A ». Le client transmet au proxy une demande de connexion au serveur SSL distant, à l'aide de la requête HTTP CONNECT www.serveur.com:443 HTTP/1.1. Le proxy répond à cette requête avec un code HTTP/1.1 200 Connection established, après avoir vérifié qu'une connexion TCP/IP avec le serveur distant était possible sur le port 443 (pas de SSL à ce stade).

- Étape 2 : Le proxy crée une seconde connexion SSL indépendante vers le serveur comme s'il était lui-même un navigateur : on appellera cette connexion « CONNECTION B ». Le proxy récupère et modifie alors le certificat X509 de www.serveur.com pour en créer un nouveau en réalisant les manipulations suivantes :

 1) Le descripteur de l'autorité de certification est remplacé par celui de « Proxy Certs Master ».

 2) La clé publique du serveur est remplacée par la clé publique du proxy.

 3) Certaines extensions X509 V3 sont supprimées ou modifiées par souci de cohérence si nécessaire.

 4) Le certificat est reconstruit et signé par la clé privée de l'autorité « Proxy Certs Master ».

- Étape 3 : Le client envoie alors une séquence d'initialisation SSL sur la CONNECTION A. Le proxy y répond en présentant sa propre clé publique et le certificat modifié créé à l'étape précédente. Le client peut vérifier la chaîne de certification à l'aide du certificat racine de notre autorité « Proxy Certs Master » et croit donc dialoguer avec le serveur authentique (et non le proxy).

- Étape 4 : Le client envoie sa requête HTTPS sur la CONNECTION A : GET / HTTP/1.1. Le proxy la lit et la renvoie sur la CONNECTION B.

- Étape 5 : Le serveur reçoit la requête HTTPS sur la CONNECTION B et renvoie sa réponse HTTP/1.1 200 OK avec le contenu de la page demandée. Le proxy lit cette réponse et la renvoie vers la CONNECTION Aà destination du client.

Les CONNECTION A et B sont alors fermées : l'interception Man-In-The-Middle a été un succès.

2.3. Exemple de modification de certificat

À titre d'illustration, examinons les transformations qui sont réalisées sur un certificat lors d'une requête vers https://www.facebook.com, en comparant le certificat original avec celui obtenu après transformation. Tout d'abord, examinons le certificat présenté par www.facebook.com :

Puis examinons le certificat obtenu après transformation :

On voit clairement le changement d'autorité de certification et de clé publique. Dans les deux cas, les résultats ont été tronqués par souci de simplicité, sinon on pourrait également voir certains changements opérés dans les extensions de ce certificat X509 V3.

3. Analyse des résultats

À l'aide de notre dispositif, nous avons placé un iPhone 3GS sous surveillance. Premier test : nous utilisons une application nécessitant un appel aux services de géolocalisation d'Apple (exemple : la Boussole ou Maps). Le téléphone contacte immédiatement le serveur de géolocalisation d'Apple en SSL à l'adresse gs-loc.apple.com. Voici une présentation « brute » de ce premier message :

Une analyse visuelle rapide fait apparaître la version de l'OS de notre iPhone cobaye (4.3.2.8H7) et ce qui semble être des adresses MAC (BSSID), par exemple : c:60:76:e:b8:c3. La réponse fournie par le serveur d'Apple est beaucoup plus longue et nous ne la reproduirons pas ici. Elle semble avoir un format similaire, mais elle contient en revanche pas moins de 405 occurrences d'adresses MAC (ce nombre peut varier selon les cas). Reste donc à décoder plus précisément le format de ces échanges.

3.1. Jouer aux devinettes avec le format « protocol buffer »

Lors d'une de nos enquêtes précédentes, nous avions été confrontés à des données encodées dans un format ouvert inventé par Google : les « protocol buffers ». Sans trop croire qu'Apple utiliserait ce type de format, nous faisons tout de même des tests. Bonne pioche : à notre surprise, les requêtes de géolocalisation d'Apple sont presque intégralement encodées dans ce format.

Le format « protocol buffers » (ou simplement « protobuf ») est un mécanisme de sérialisation de données, comme peut l'être ASN.1 [10] ou même JSON [11]. La meilleure manière de comprendre ce format est de lire la documentation de Google [12]. Brièvement, son principe est le suivant :

- Chaque donnée est définie par deux composantes : une clé et une valeur.

- La clé est elle-même composée de deux parties :

 1) un descripteur générique de format (seulement 6 valeurs possibles) ;

 2) un identifiant unique de la donnée.

- La donnée elle-même est encodée de manière variable selon son usage.

Contrairement à un format comme XML qui contient des « tags » textuels normalement destinés à permettre à un humain de deviner le sens des données encodées, le format protobuf nécessite de jouer aux devinettes. En premier lieu, le descripteur générique de format est très vague : par exemple, s'il indique une valeur 32 bits, il reste à savoir s'il s'agit d'un entier signé, d'un entier non signé ou d'un nombre à virgule flottante. De plus, l'identifiant unique de la donnée dépend totalement du contexte.

C'est finalement en recoupant les données collectées avec le contenu de la base de données consolidated.db [1] dont nous parlions en introduction que nous avons construit une interprétation plausible des requêtes de géolocalisation envoyées vers les serveurs d'Apple, à l'aide d'outils supplémentaires que nous avons également développés.

3.2. Les demandes de géolocalisation

Nous sommes donc en mesure de revisiter la requête de géolocalisation précédente :

Cette requête est très simple : elle contient uniquement les adresses MAC de 5 points d'accès Wi-Fi détectés à proximité du téléphone. On notera deux choses intéressantes. Tout d'abord, la requête ne contient aucun numéro identifiant le téléphone de manière unique (comme l'IMEI ou l'UDID). Certes, le serveur d'Apple collecte l'adresse IP de notre connexion ADSL, mais c'est une information plus difficile à exploiter dans ce contexte pour identifier un dispositif mobile comme l'iPhone, car il est susceptible de varier ses méthodes de connexion à Internet pendant une même journée, cela contrairement à un PC fixe. Ensuite, on remarquera que les BSSID sont transmis sans information relative à la force des signaux des points d'accès détectés. Apple ne reçoit donc pas d'information très précise pour géolocaliser le téléphone. On va vite comprendre pourquoi : en effet, ce n'est pas Apple qui géolocalise le téléphone, mais le téléphone qui se géolocalise lui-même...

En effet, voici maintenant la réponse du serveur d'Apple, que nous avons tronquée par souci de simplicité :

La réponse contient en tout une liste de 405 points d'accès Wi-Fi. Chacun de ces points est associé à une position géographique précise et ce que nous pensons être une estimation du niveau de confiance que l'on peut accorder à cette information. Si on place ces points sur une carte à l'aide d'un fichier KML [13], on obtient le résultat présenté à la figure 3.

 

 

Avec ces informations et avec la force du signal qu'il a mesuré en provenance des points d'accès environnants, l'iPhone est alors en mesure de calculer lui-même sa position par triangulation. Mieux encore, si le téléphone se déplace dans la même zone géographique, il n'a pas besoin de refaire une requête vers les serveurs d'Apple : il peut puiser dans les informations précédemment reçues pour se géolocaliser. Ces informations peuvent alors être stockées dans une base de données et resservir en cas de connexion défaillante, c'est sans doute le rôle du fameux fichier consolidate.db qui avait tant suscité de questions au printemps dernier.

3.3. Des messages nocturnes

Lorsqu'un iPhone est laissé allumé pendant la nuit et connecté à un point d'accès Wi-Fi, il arrive qu'il se connecte à un autre serveur d'Apple : iphone-services.apple.com, et cela, sans la moindre intervention de l'utilisateur. Un travail d'analyse nous a permis de déchiffrer en grande partie cet échange, et de découvrir une autre source d'échanges de données de géolocalisation entre l'iPhone et Apple, comme le montre l'exemple suivant :

Cet exemple montre cette fois-ci des données très précises sur des points d'accès Wi-Fi qui ont été vus pendant la journée par le téléphone : latitude, longitude, canal, force du signal et même un horodatage (en secondes écoulées depuis début 2001). Naturellement, la latitude et la longitude correspondent à la position du téléphone au moment de la mesure et pas à la position des points d'accès. Ici encore, cependant, aucune information ne permet d'identifier le téléphone (à part éventuellement l'adresse IP).

La collecte de ces informations permet certainement à Apple d'enrichir sa base de géolocalisation, notamment pour y ajouter de nouveaux points d'accès Wi-Fi détectés. En recoupant les informations fournies tous les jours par des millions de téléphones, Apple est capable petit à petit de faire évoluer sa base cartographique avec une assez grande précision. C'est ce qu'on appelle le « crowdsourcing » : chaque téléphone travaille donc un peu pour Apple.

Conclusion

Cet article a rappelé qu'il est possible d'intercepter une communication SSL à condition de déposer un certificat racine sur les postes informatiques que l'on souhaite surveiller.

Notre analyse montre qu'Apple a utilisé une approche originale pour construire son mécanisme de géolocalisation : ce n'est pas le serveur d'Apple qui géolocalise le téléphone, mais le téléphone qui se géolocalise lui-même à partir des données envoyées par Apple. Ponctuellement, l'iPhone envoie néanmoins des informations détaillées sur les points d'accès Wi-Fi qu'il a vu pendant les heures passées. Une pratique qui mériterait sans doute une meilleure information d'Apple envers ses utilisateurs.

La méthode retenue par Apple semble être plutôt bonne en termes de protection de la vie privée : les données sont sécurisées par SSL/TLS et aucun numéro d'identification n'est présent dans les requêtes, même s'il reste naturellement une possibilité de traçage à partir de l'adresse IP dans certains cas. N'oublions pas cependant que les applications qui utilisent l'API de géolocalisation de l'iPhone peuvent elles-mêmes tracer les individus, même si Apple ne le fait pas.

Si un même téléphone fait une requête de géolocalisation le matin et le soir à partir de deux endroits différents, les serveurs d'Apple ne sont vraisemblablement pas en mesure de savoir qu'elles viennent du même téléphone. Le risque de pistage des personnes par Apple est donc très réduit. Peut-on en dire autant de leurs concurrents ? Vous avez maintenant tous les outils pour mener l'enquête !

Références

[1] http://radar.oreilly.com/2011/04/apple-location-tracking.html

[2] Sean Morrissey et Alex Levinson, « iOS Forensic Analysis: for iPhone, iPad, and iPod touch », APress, 2010

[3] http://mitmproxy.org/ : un proxy HTTP/SSL

[4] http://www.tcpcatcher.org/ : un proxy HTTP/SSL

[5] http://code.google.com/p/sslmeat/ : un proxy SSL en C++, GPL V3

[6] http://www.schneier.com/blog/archives/2011/09/man-in-the-midd_4.html

[7] http://en.wikipedia.org/wiki/DigiNotar

[8] http://www.openssl.org/

[9] http://tools.ietf.org/id/draft-luotonen-web-proxy-tunneling-01.txt : la requête HTTP CONNECT

[10] http://fr.wikipedia.org/wiki/ASN.1: le format ASN.1

[11] http://www.json.org/: le format JSON

[12] http://code.google.com/intl/fr-FR/apis/protocolbuffers/docs/encoding.html : Google protocol buffers

[13] http://code.google.com/intl/fr-FR/apis/kml/documentation/kmlreference.html : le format KML