Des traceurs GPS bien trop indiscrets

L’utilisation de traceurs GPS dans les domaines privés et publics, parfois à la limite de la légalité, a vu une très forte hausse. Avec l’objectif de suivre un bien ou une personne, le traceur GPS a pour fonction de transmettre périodiquement ou à la demande les coordonnées GPS de sa localisation. Un traceur GPS se connecte via le réseau mobile à l’aide d’une carte SIM/USIM (en fonction des modèles) afin de transmettre à intervalle régulier les informations obtenues par son module de réception GPS ainsi que par message texte vers un numéro préenregistré lorsque celui-ci est sollicité par le propriétaire du traceur. Certains traceurs dits « évolués » intègrent en plus en fonction des modèles : une fonction d’enregistrement de l’environnement sonore sur demande, des interfaces radio complémentaires (ex. Wifi) ainsi que des détecteurs de mouvement. La configuration de ces traceurs est réalisée par la transmission de messages texte (SMS) dont les détails sont fournis dans la documentation technique transmise par le constructeur au moment de l’achat. Le propriétaire peut ainsi consulter la position du traceur via une application smartphone, via la transmission de SMS ou directement via l’application web. Les données sont transmises à un serveur distant où une application va traiter et mettre en forme les coordonnées GPS sur une carte géographique afin que l’utilisateur prenne connaissance de la position du boîtier de la plus simple des façons. Les coordonnées GPS peuvent également être envoyées par SMS directement à l’utilisateur au format texte afin de permettre un suivi décentralisé. L’utilisateur peut ensuite utiliser ces coordonnées sur un service tel que Google Maps afin de prendre connaissance du lieu géographique. Il a également été constaté que certains de ces traceurs GPS intègrent des fonctionnalités dites « évoluées » comme par exemple un détecteur de mouvement et/ou un microphone ainsi que des capacités de gestion de mise en fonctionnement et d’arrêt de véhicules à distance.

Le niveau de sécurité de ces équipements de suivi et d’espionnage est donc stratégique afin de ne pas fournir à un tiers malveillant les mêmes accès. Il est logiquement nécessaire d’évaluer le niveau de sécurité avec les outils adéquats et d’estimer le risque introduit par l’usage de ces solutions. Peu d’études ont été consacrées à l’analyse complète des traceurs GPS et des infrastructures. L’étude la plus complète que nous recommandons est l’étude TrackMagedon [1] mettant à jour des problèmes de sécurité dans les interfaces de gestion démontrant que les données des utilisateurs sont stockées et disponibles pour n’importe quel tiers malveillant ayant quelques connaissances en sécurité des technologies web.

Nous proposons dans cette étude une analyse en profondeur des vecteurs d’attaque possibles ainsi que les résultats des tests effectués sur différents boîtiers du commerce. Plusieurs vulnérabilités critiques démontrent que le niveau de sécurité est faible et que des millions de boîtiers aujourd’hui sur le marché mettent en péril la vie privée des personnes équipées du dispositif (avec ou sans consentement) et potentiellement la résilience des véhicules intégrant des dispositifs évolués permettant l’arrêt à distance de leur moteur. Par ailleurs, nous avons pu constater que les informations remontées vers des serveurs distants intègrent également le numéro des stations de base (CellID) en complément permettant donc aux constructeurs de cartographier les réseaux de télécommunications de différents pays.

1. Scénarios d’attaque

Un schéma représentant l’architecture générale et les points d’interaction est proposé. Comme il peut être constaté, les vecteurs d’attaque sont nombreux et la surface d’attaque est assez conséquente : les interfaces radio (GPS, réseaux mobiles), les serveurs distants, les applications pour smartphone ainsi que les protocoles de gestion et de configuration. Par ailleurs, les mécanismes de mise à jour quand ils existent sont également des vecteurs d’attaque intéressants à exploiter. En fonction de l’objectif d’un attaquant, les techniques et outils (majoritairement open source) seront à adapter. Nous proposons dans cette section de traiter les points d’intérêt pour un attaquant en fonction de son objectif sans motiver les lecteurs à réaliser ces différentes attaques du fait de leur illégalité.

1.1 Brouillage et leurre GPS

Un attaquant dont l’objectif est de bloquer la transmission des coordonnées GPS vers les serveurs distants peut ainsi brouiller le signal à l’aide de dispositifs à bas coût disponibles sur Internet. Cette attaque de faible niveau technique est cependant difficile à couvrir si le système de contrôle vérifie le statut du boîtier et/ou corrèle le manque de données avec des informations tierces comme les CellID. Afin de réduire la détection par le système de contrôle qu’une action malveillante est en cours, l’attaquant peut leurrer une constellation GPS pour modifier ou étendre la zone de couverture du dispositif afin de changer la position géographique. Un article complet sur la méthodologie et les outils portant sur le leurrage GPS est inclus dans ce numéro du MISC et nous renvoyons le lecteur vers celui-ci. Il est cependant à noter ici que la complexité de l’attaque est faible puisque les outils et leurs utilisations sont très bien documentés.

1.2 Attaque du protocole de gestion

Avec l’objectif de reconfigurer et de remonter les données vers sa propre infrastructure, un attaquant peut chercher à changer les adresses des serveurs de gestion et forcer les traceurs à transmettre les coordonnées GPS vers cette infrastructure. Afin d’éviter d’être détecté, il pourra ensuite transmettre les données en les modifiant à la volée vers l’infrastructure légitime. Cette attaque nécessite évidemment de connaître le protocole de management et le numéro de la SIM provisionnée dans le traceur et exploiter des vulnérabilités du protocole de gestion. La complexité de cette attaque est directement liée au niveau de sécurité du protocole de gestion et de son implémentation.

1.3 Attaque des serveurs distants et des applications web et pour smartphone

Un attaquant ayant pour objectif de compromettre l’intégralité des données issues des traceurs GPS pour un constructeur donné pourra directement chercher à attaquer l’infrastructure et les applications de gestion à distance mises à disposition des utilisateurs. En se procurant un traceur, l’attaquant pourra réaliser la rétroconception des protocoles, des firmwares et du matériel. Ensuite, une analyse des mécanismes d’authentification, d’identification et des APIs disponibles permettra de trouver des vecteurs de compromission. La richesse des informations accessibles fera que ce scénario d’attaque est le plus efficace puisqu’il permet potentiellement d’attaquer un très grand nombre de traceurs.

Dans la suite de cette étude, nous proposons les plans expérimentaux et les résultats associés démontrant le faible niveau de sécurité des traceurs GPS et des infrastructures associées. Afin de rendre cette étude la plus large possible, nous nous sommes procuré les traceurs GPS ayant été les plus vendus sur Internet.

2. Évaluation de modules du commerce

2.1 Analyse de la remontée de données

Dans un premier temps, une analyse du trafic réseau a été réalisée afin de comprendre le type de données échangées ainsi que les protocoles de communication. Pour cela, nous nous sommes placés en boite noire et nous avons mis en place une BTS 2G/2.5G (GPRS) sans authentification/chiffrement (configuration de base de la station 2G) utilisant Yatebts. Il faut noter que la majorité des traceurs ne supporte que les cartes SIM (les auteurs se sont arraché les cheveux avec des cartes uSIM).

Pour des contraintes règlementaires, nous plaçons notre dispositif RF dans une cage de Faraday. Chacun de nos traceurs GPS est équipé d’une carte SIM et un numéro unique est attribué. Une fois que la BTS est opérationnelle, nous avons sniffé l’interface GPRS (sgsntun) pour récupérer le trafic réseau de chaque traceur GPS. Finalement, nous avons utilisé les commandes SMS préconisées par le constructeur afin de paramétrer chacun de nos traceurs.

Durant cette phase de configuration, nous avons pu constater les premiers éléments critiques suivants :

• tous les traceurs envoient les coordonnées vers des IPs en Chine ;
• le trafic n’est pas chiffré et est facilement identifiable (noms de domaine spécifiques, IPs spécifiques, ports spécifiques) – une implémentation de DPI est triviale à effectuer pour ce type de protocole ;
• le mot de passe d’une plateforme est véhiculé en clair, les autres plateformes utilisent le numéro de série des traceurs (prédictibles) comme token sans système d’authentification, permettant à un attaquant d’envoyer des informations forgées ;
•  il est possible, via un SMS, d’éditer la configuration du traceur et de spécifier un autre serveur de management (« *reg mon_ip »), permettant à un attaquant d’effectuer un MITM simple via un serveur sur Internet relayant le trafic (UDP ou TCP – selon les traceurs), avec par exemple balance (1) pour du TCP : balance -b ::ffff:mon_ip 8841 203.130.62.29:8841
• il est possible de définir un numéro de téléphone master. En cas d’usurpation de Caller-ID, cette authentification est contournable. De plus, même via un numéro de téléphone master défini, il est possible d’envoyer des commandes via SMS et d’avoir des informations sur le traceur en retour, permettant ainsi de détecter des traceurs sur un ensemble de numéros de téléphone (cette méthode ne sera par contre pas discrète).

Les traceurs utilisant un module GPS U-BLOX se connectent à un service TCP sur le port 56447/tcp. Par défaut, le client envoie son login, password, latitude, longitude et altitude en clair au début de la session TCP :

Le serveur répond en spécifiant un blob propriétaire :

Le client envoie ensuite régulièrement des informations à un deuxième serveur (8011/tcp) en indiquant sa position :

On peut détecter différentes commandes suivant le numéro de série (17000XXXXX). 2240.8116 correspond à la latitude 22.408116, 11408.8108 à la latitude 11.4088108. Il n’y a pas d’authentification, ce qui nous a permis de créer notre propre client GPS envoyant des coordonnées GPS sous contrôle. On peut voir ici que notre traceur GPS se trouve actuellement à Pyongyang en Corée du Nord :

Un second traceur (le plus économique) ne possède aucun élément d’authentification permettant au serveur de vérifier la provenance des données collectées (en SMS ou sur les données émises en 2G). Les données envoyées vers la plateforme de management sont toujours de la forme :

Un point intéressant est qu’il envoie en Chine l’intégralité des SMS reçus sur son interface radio – permettant au gestionnaire de la plateforme de savoir exactement ce que veut faire l’utilisateur :

Suite à l’envoi d’un SMS « Status » vers le traceur GPS, celui-ci envoie un paquet TCP vers 203.130.62.29:8841/tcp, IP géolocalisée en Chine, mais se trouvant en réalité aux Émirats Arabes Unis et annoncée par l’opérateur Etisalat, contenant le message « Status », avec d’autres informations : 690217122612463 correspondant au S/N du traceur GPS et +440025239 étant le numéro de l'émetteur du SMS. Cela marche pour tout message SMS, même s’il ne correspond pas à un mot-clé spécifique permettant la gestion du traceur. Une utilisation détournée du traceur permet, via la redéfinition du serveur de management, d’avoir un système relais de SMS à bas coût (< 15 euros), solution idéale pour les expats recevant des SMS de validation vers un numéro français.

De manière générale, la sécurité réseau des traceurs GPS est très mauvaise, le trafic est en clair et est facilement compréhensible. Un attaquant peut envoyer de fausses informations sur l’infrastructure de management GPS à condition de posséder le numéro de série du traceur.

2.2 Rétroconception du matériel

L’ouverture des traceurs a permis de mettre en évidence la simplicité de l’électronique utilisée. On trouve principalement de vieux chipsets MediaTek (MT6261 ARM) et des chipsets GPS (par exemple U-BLOX). Des interfaces de debug sont disponibles permettant l’extraction des firmwares et des éléments de configurations par défaut. On notera la simplicité de cette partie puisqu’aucune protection contre les attaques physiques n’est intégrée.

Une analyse a été effectuée sur le dump d’un des firmwares. Pour celui-ci, le système embarqué est Nucleus RTOS et la taille de l’OS est conséquente pour du matériel embarqué (4Mo). Le reverse de ce même dump a permis de révéler la présence de codes SMS backdoors dans différents traceurs GPS. Ces codes SMS ne semblent pas être tous fonctionnels – le firmware est visiblement utilisé sur de nombreux traceurs GPS aux fonctionnalités variables.

L’analyse du firmware n’a pas révélé de fonctionnalités cachées majeures, mais a plutôt permis de voir que le développement semble avoir été fait rapidement et que de nombreuses commandes ne fonctionnent pas. Nous n’avons pas non plus identifié de fonctionnalités de mise à jour du firmware – il s’agit donc de matériel jetable.

2.3 Analyse sécurité des applications mobiles

Le constructeur fournit des applications pour smartphones iOS/Android, permettant d’avoir accès aux informations remontées par le traceur via l’intermédiaire d’une carte mondiale. Une rétro-ingénierie statique et dynamique a été effectuée sur le client Android. Par ailleurs, l’analyse statique via l’utilitaire jadx [2] a permis de trouver un système d’échange d’informations via une API accessible en http.

En vérifiant avec l’analyse dynamique, il est apparu que les échanges entre le smartphone et le serveur distant se font bien via http à travers un système d’API propriétaire (http://m.999gps.net/OpenAPIV2.asmx) – on peut voir l’identifiant 82383 – correspondant au traceur – dans la requête :

Il est aussi possible d’accéder au WSDL (Web Services Description Language) de l’API en rajoutant ?WSDL à l’adresse afin de récupérer un descriptif complet du service. Finalement, le constructeur fournit une interface de debug en ligne :

En analysant le trafic, il est apparu que l’authentification est inexistante et que rejouer la requête analysée précédemment par Wireshark en changeant l’identifiant permet de récupérer les coordonnées d’un autre traceur. Cette vulnérabilité avait été déjà signalée par l’équipe de Trackmaggedon [1] en janvier 2018, mais n’a jamais été corrigée par le constructeur.

2.4 Sécurité des sites web de gestion des traceurs et attaques avancées

Lors de l’achat d’un traceur, il est fourni un identifiant et un mot de passe pour un site web permettant d’accéder aux informations remontées par le traceur. En analysant ces sites web, il est apparu de nombreux problèmes :

• Par défaut, le nom d’utilisateur et le mot de passe sont les 7 derniers caractères du numéro de série du traceur GPS. Les utilisateurs ne semblent pas être au courant et ne changent pas forcément les mots de passe. Il est ainsi possible pour un attaquant de provisionner l’ensemble des comptes disponibles.
• Il a été possible, depuis un compte d’un traceur GPS, d’accéder aux coordonnées d’un autre traceur GPS en notre possession en indiquant l’ID de notre traceur dans la requête http – il s’agit d’une vulnérabilité de type insecure direct object reference, à condition de posséder une session valide (c’est-à-dire de posséder juste un compte sur la plateforme). De plus, il est aussi possible d’ajouter une geofence à d’autres traceurs, provoquant une alerte si le véhicule sort de la zone ou permettant d’aller jusqu’à l’arrêt du moteur.

L’interface permet d’avoir accès à l’intégralité de l’historique des déplacements des traceurs.

Conclusion

Dans le cadre de cette étude, nous nous sommes intéressés à la sécurité de traceurs GPS dont la popularité est grandissante. Nous avons pu constater que les différents scénarios d’attaque peuvent être facilement exploités afin d’obtenir les informations de localisation des traceurs GPS de façon illégitime et que la protection des échanges de données était pour l’intégralité des traceurs quasiment inexistante. Les interfaces de configuration via SMS dont l’authentification est soit inexistante, soit contournable via l’usurpation du CallerID exposent les utilisateurs à une atteinte à leur vie privée, mais aussi à des problèmes du fait des fonctionnalités avancées de certains modèles comme l’arrêt du véhicule à distance. De nombreux problèmes de sécurité ont été trouvés dans les APIs et les sites web.

Évidemment, les différentes vulnérabilités ne permettent pas un unique type d’exploitation. Les informations étant extrêmement complètes, comportant les informations du réseau de télécommunications environnant et les coordonnées GPS, celles-ci permettent pour un attaquant de cartographier de façon efficace les infrastructures critiques de téléphonie mobile d’un pays. Les trajets et les lieux sont également des informations stratégiques puisque corrélés aux horaires de travail, un attaquant est capable de connaître quand et où une cible travaille ainsi que son lieu de résidence. L’intégralité des données est déjà présente sur des serveurs de pays tiers rappelant le bug logiciel du transfert des coordonnées GPS des CelI-IDs dans iOS [3].

Enfin, nous avons pu constater que la protection des données est très faible et la notion de GDPR est inexistante pour les fournisseurs de traceurs GPS. Finalement, des résultats complémentaires seront présentés durant la conférence Hack In Paris 2019.

Remerciements

Ce travail a été effectué durant notre temps personnel de recherche. Nous souhaitons remercier DARKMATTER LLC de nous permettre de publier nos travaux portant sur la sécurité des objets connectés. Les opinions et les résultats présentés dans cet article n'engagent que leurs auteurs. Nous souhaitons aussi remercier Eiman Al Shehhi, Mobile & Telecom Lab, DARKMATTER LLC, pour son soutien durant l’analyse technique.

Références

[1] https://0x0.li/trackmageddon/

[2] https://github.com/skylot/jadx

[3] https://www.apple.com/newsroom/2011/04/27Apple-Q-A-on-Location-Data/