- L’application BM2, utilisée pour vérifier l’état de la batterie d’un véhicule, collectait non seulement les coordonnées GPS mais aussi les informations sur les réseaux Wi-Fi à proximité et les stations de base cellulaires, puis les transmettait à un serveur distant
- Les données étaient envoyées au serveur
bm2.quicklynks.comdu fabricant du produit/de l’application, Leagend, ainsi qu’aux serveurs d’AMap, éditeur du SDK de service de localisation, hébergés respectivement sur Alibaba Cloud à Hong Kong et à Pékin - L’application totalisait 100K+ téléchargements sur Google Play, mais les mentions initiales de confidentialité dans les stores — « aucun partage de données », « aucune collecte de données », « chiffrement des données en transit » — ne correspondaient pas à son comportement réel
- Sur Android, l’autorisation de localisation est requise pour le scan Bluetooth, ce qui obligeait en pratique l’utilisateur à l’accorder pour utiliser l’appareil ; sur iOS, les fonctions du moniteur de batterie continuaient à fonctionner même si cette autorisation était refusée
- Après la mise à jour du 25 juillet 2023, le SDK AMap a été retiré des versions publiées dans les deux grands app stores, mais les données de localisation GPS continuaient d’être envoyées vers un serveur Alibaba Cloud à Hong Kong, et l’application iPhone transmettait aussi l’adresse postale de l’utilisateur
Les données de localisation envoyées par l’application du moniteur de batterie
- Le produit visé est un moniteur Bluetooth de batterie qui se connecte aux bornes de la batterie de la voiture, s’appaire avec un smartphone, affiche la tension/le pourcentage et exécute un test de démarrage
- L’analyse a été menée à partir d’un produit de marque PowerTech acheté chez le revendeur australien Jaycar Electronics ; il semble s’agir d’un rebranding du Bluetooth 4.0 Battery Monitor de Leagend
- Des produits de la même famille ont aussi été identifiés sous la marque Century de Repco, ou sous des noms comme
ZX-1689etLi Battery Monitor - L’application Android BM2 affiche 100K+ téléchargements et 1.55K avis sur Google Play
- Les vérifications du trafic réseau ont également montré que l’application BM2 pour iPhone transmettait des données de localisation à des serveurs distants
Destinataires des données et périmètre de collecte
- L’application collectait non seulement la tension de la batterie, mais aussi les coordonnées GPS, les données des stations de base cellulaires voisines et les informations sur les points d’accès Wi-Fi à proximité
- Les destinations observées à l’époque pour ces données de localisation relevaient de deux ensembles
- Serveur Leagend / application BM2 :
bm2.quicklynks.com,47.244.125.231, Alibaba Cloud Hong Kong - Serveur du SDK AMap :
dualstack-cgicol.amap.com,106.11.130.194, Alibaba Cloud Pékin
- Serveur Leagend / application BM2 :
- AMap est un fournisseur chinois de cartographie numérique acquis par Alibaba, et son SDK récupérait non seulement le GPS mais aussi d’autres données liées à la localisation que le téléphone peut collecter
- Après la mise à jour du 25 juillet 2023, le SDK AMap a été retiré des applications publiées dans les deux grands app stores
- La collecte de données GPS, Wi-Fi et stations cellulaires à destination des serveurs d’AMap en Chine continentale a cessé
- Les données de position GPS continuaient malgré tout à être envoyées vers un serveur Alibaba Cloud à Hong Kong
- L’application iPhone récupérait et transmettait aussi l’adresse postale de l’utilisateur
Affichage de confidentialité dans les stores et comportement réel
- Au 27 juin 2023, le développeur de l’application BM2 avait mis à jour les fiches de confidentialité sur Google Play et l’Apple App Store pour indiquer la collecte de données de localisation précises
- Avant cela, les mentions affichées sur Google Play ne correspondaient pas au comportement réel de l’application
- « Aucune donnée partagée avec des tiers » : latitude et longitude étaient envoyées aux serveurs
quicklynks.comavec les statistiques de batterie, les analyses de crash àumeng.com, et les données Wi-Fi / stations cellulaires / coordonnées GPS à AMap - « Aucune collecte de données » : des données de localisation et des données liées à la batterie étaient bien collectées
- « Chiffrement des données en transit » : les données envoyées au serveur cloud BM2 transitaient en HTTP non chiffré
- « Aucune donnée partagée avec des tiers » : latitude et longitude étaient envoyées aux serveurs
- Le détail de la politique de confidentialité mentionnait notamment « Hong Kong » et « location information »
Le problème structurel créé par les permissions Android
- L’application Android exigeait l’autorisation de localisation pour fonctionner, et sans cette autorisation il était impossible d’utiliser le matériel
- Depuis Android 6.0, l’accès aux identifiants matériels d’appareils externes à proximité via les scans Bluetooth et Wi-Fi nécessite l’autorisation
ACCESS_FINE_LOCATIONouACCESS_COARSE_LOCATION - BM2 n’avait en réalité besoin que d’un scan BLE, mais cette autorisation de localisation très large permettait aussi l’accès aux données GPS, cellulaires et Wi-Fi, ouvrant la voie aux abus
- À partir d’Android 12, un scan BLE est possible avec la seule autorisation BLUETOOTH_SCAN
- D’après la documentation Google, il est possible de définir
android:usesPermissionFlags="neverForLocation"surACCESS_FINE_LOCATION, mais uniquement si les résultats du scan Bluetooth ne sont pas utilisés pour déduire une position physique
Ce que montrait le trafic réseau
- Le trafic de l’application mobile a été observé avec le mode WireGuard de Mitmproxy
- BM2 n’utilisait pas HTTPS, ce qui a permis de constater sans installation de certificat, sur Android comme sur iOS, l’envoi de la latitude et de la longitude
- Une fois connectée au moniteur de batterie, l’application envoyait une requête
POSTàhttp://bm2.quicklynks.com:8080/api/bm2/userDevice/upload? - La requête contenait les champs latitude et longitude, ainsi que des échantillons de tension de batterie, l’adresse MAC du matériel,
nicknameetserialNo - Au moment de l’analyse, les recherches DNS et IP montraient que
bm2.quicklynks.compointait vers47.244.125.231, une adresse rattachée à un AS Alibaba situé à Sham Shui Po, Hong Kong
Les signaux de localisation traités par le SDK AMap
- Le SDK AMap collectait des données GPS, Wi-Fi et de stations de base cellulaires
- Les données cellulaires incluaient le Cell Global Identity
MCC: Mobile Country CodeMNC: Mobile Network CodeMCC + MNC: PLMN, identifiant de l’opérateur mobileLAC: groupe de stations de base dans une zoneCI: identifiant de l’émetteur-récepteur de station de base dans la zone- En 4G,
TACest utilisé
- Les données Wi-Fi incluaient l’adresse MAC
BSSIDet le nom du point d’accèsSSID - Les données AMap étaient traitées sous forme de blob binaire sérialisé chiffré avant d’être écrites sur disque ou transmises sur Internet
- Les données de localisation étaient chiffrées avec une clé AES temporaire, elle-même rechiffrée avec une clé publique RSA
- Cette méthode ne repose pas sur le certificate pinning
- Sans modification de l’application ou sans la clé privée RSA correspondante, il est difficile d’inspecter le contenu via une interception réseau de type man-in-the-middle
Matériel et environnement de test
- L’intérieur du matériel est simple, centré sur un régulateur de tension et un MCU Bluetooth Low Energy Texas Instruments CC2541
- Le CPU du CC2541 est basé sur un Intel 8051 8 bits ; les séries CC ultérieures utilisent une architecture ARM Cortex
- Les SoC de la série CC prennent en charge une interface de débogage on-chip dédiée, sans JTAG ni SWD visibles
- L’appareil prend en charge les mises à jour OTA, et un endpoint REST renvoyant le firmware est documenté dans la partie 3
- Aucun shunt de mesure de courant ni autre circuit de mesure du courant n’était visible, ce qui souligne la grande simplicité du matériel
- Les tests ont été réalisés avec une petite batterie plomb-acide 12 V, un moniteur de batterie BM2 et un terminal Android rooté
- Comme les données de localisation AMap ne sont consignées de la mémoire vers la base de données que lorsqu’un déplacement physique est détecté, une instrumentation à l’exécution a été effectuée avec Frida et Objection
Procédure d’analyse dynamique et statique
- Les coordonnées GPS peuvent être modifiées avec Frida en hookant
android.location.Location.getLatitudeetgetLongitudepour leur faire renvoyer des valeurs arbitraires - Le plugin Wallbreaker d’Objection a permis d’identifier dans le heap de l’application des instances contenant des données GPS, cellulaires et Wi-Fi
- L’APK a été extrait depuis le terminal après récupération du chemin via
adb shell pm path, puis décompilé avec JADX - Dans
AndroidManifest.xml, en plus deFINE_LOCATION, figuraient aussi des permissions commeCAMERA,IMAGE_CAPTURE,ACTION_VIDEO_CAPTURE,MODIFY_AUDIO_SETTINGSetRECORD_AUDIO, mais leur utilisation réelle nécessite une enquête supplémentaire - Le point d’entrée de l’application est
com.stub.StubApp, avec utilisation du packer commercialqihoo.util - frida-dexdump a servi à extraire depuis la mémoire en cours d’exécution le bytecode Dalvik original, ensuite converti en code Java lisible avec
dex2jaret JADX - L’application BM2 elle-même n’avait pas d’obfuscation supplémentaire, mais le SDK de service de localisation
amapétait obfusqué ; la fonction de désobfuscation de JADX a permis de restaurer une partie des noms de classes
1 commentaires
Avis sur Hacker News
C’est le résultat d’une rétro-ingénierie d’un moniteur de batterie automobile BLE. L’application compte plus de 100 000 téléchargements rien que sur Google Play.
Il s’est avéré qu’elle envoyait en continu des données GPS, des identifiants de cellules d’antennes relais et des données de balises Wi‑Fi vers des serveurs à Hong Kong et en Chine continentale. Les pages de l’application sur Google et l’App Store d’Apple indiquent qu’elle ne collecte pas de données personnelles et ne les transmet pas à des tiers.
J’espère que cela donnera quelques pistes à ceux qui veulent analyser des applications pour appareils connectés.
https://www.amazon.de/dp/B0BLG9Z462
En cliquant sur la troisième image, on obtient un tableau comparatif ; il est intéressant de voir que c’est présenté comme une fonction propre au BM6, alors qu’il s’agit en réalité simplement d’une fonctionnalité de l’application.
Le QR code de l’appareil [0] pointe vers cette application : https://play.google.com/store/apps/details?id=com.dc.bm6
J’ai donc aussi vérifié d’autres URL comme https://link.quicklynks.com/bm3.html et https://link.quicklynks.com/bm4.html ; cette dernière redirige vers https://www.leagend.com/, qui exploite cette chaîne YouTube : https://www.youtube.com/channel/UCqkvyOFP5cXQ02f3h1Ns42Q
[0] http://link.quicklynks.com/bm6.html
Je ne sais pas non plus si cela vaut le coup de vider en permanence la batterie du téléphone pour voir sur son écran une information que le tableau de bord donne déjà. Pour une batterie fixe, un simple voltmètre analogique à cadran ne suffirait-il pas ?
De nos jours, il est vraiment difficile de trouver des appareils autonomes qui fonctionnent sans application. Par exemple, j’ai eu du mal à trouver une lampe LED dont on puisse choisir la couleur avec les boutons de l’appareil, sans application ; j’en ai bien trouvé une, mais même là, faire défiler les couleurs reste impossible sans application.
Si les gens ne préféraient pas ce genre d’absurdités, il serait plus facile de retrouver des produits électroniques normaux.
Je ne comprends pas pourquoi, sur Android, l’utilisateur ne peut pas empêcher une application 1) de s’exécuter au démarrage 2) de s’exécuter en arrière-plan. Au minimum, cela devrait être une autorisation soumise à l’approbation de l’utilisateur.
Cela permettrait de bloquer une bonne partie des applications qui siphonnent les données de cette manière ; à mes yeux, Google est aussi complice.
https://grapheneos.org/
Je sais qu’une application peut demander l’activation des données de localisation, mais j’ai été surpris qu’elle puisse l’activer unilatéralement, et je n’ai trouvé aucun moyen de l’empêcher.
Pour ce genre de raisons, j’ai du mal à faire confiance à quelque téléphone que ce soit.
Des cas comme celui-ci montrent qu’il ne faut pas cesser de se battre pour la vie privée numérique et pour les lois qui la protègent.
Ce n’est pas une question de « je n’ai rien à cacher », mais d’empêcher des tiers de surveiller les gens et de vendre leurs données personnelles sans connaissance ni consentement explicites.
Nous sommes actuellement au beau milieu d’une guerre généralisée des données, et il faut résister fermement.
Ce qui est exaspérant, c’est que ce genre de pratique est devenu la norme alors qu’il n’y a pratiquement aucun coût pour les acteurs malveillants.
En lisant cet article, je me suis senti soulagé d’utiliser GrapheneOS. Je m’en sers au quotidien depuis plusieurs mois, et chaque application doit se voir explicitement accorder ou refuser l’autorisation réseau lors de son installation.
Je n’accorde jamais l’accès réseau à ce type d’application locale, ni aux applications de clavier qui m’ont toujours mis mal à l’aise.
Ce n’est pas seulement ridicule : c’est ouvertement hostile à la vie privée et à la sécurité des utilisateurs.
Les systèmes d’exploitation devraient faire de l’accès à Internet une permission que l’utilisateur peut accorder ou révoquer. Il me semble qu’Android avait quelque chose comme ça autrefois, et qu’iOS n’a rien en dehors des données mobiles.
Si j’achetais un appareil censé utiliser Bluetooth mais qui, en réalité, a besoin d’un accès Internet, je le renverrais.
Si l’on n’acceptait pas, on ne pouvait pas obtenir l’app. Certaines permissions fonctionnent encore ainsi, et beaucoup sont passées au modèle accord/révocation.
L’accès à Internet reste une permission, mais Google Play ne la demande plus, donc toutes les apps peuvent l’avoir. En revanche, si elle n’est pas demandée dans le manifest, cela ne fonctionne pas.
https://netguard.me/
Pour les débutants, on pourrait afficher les domaines, et les marquer en vert si Apple les a placés d’une manière ou d’une autre sur une liste d’autorisation. S’ils ne sont ni sur une liste d’autorisation ni sur une liste de blocage, on pourrait les afficher en jaune, ou simplement montrer le nom si les couleurs prêtent à confusion.
Les apps qui émettent des requêtes vers des domaines sur liste de blocage pourraient être bloquées de l’App Store jusqu’à examen complémentaire.
Pour les utilisateurs avancés, ce serait bien de pouvoir toucher pour voir des détails comme le payload et les en-têtes. Cette fonction est vraiment nécessaire et ne semble pas si difficile à ajouter.
[1]: https://developer.apple.com/documentation/bundleresources/en...
Les fournisseurs d’app stores devraient sans doute supprimer complètement les formulations du type « aucune donnée personnelle n’est collectée ni transmise à des tiers ».
À la place, ils devraient avertir : « Cette app dispose de permissions liées au réseau et peut envoyer les données qu’elle veut où elle veut » ou « Le développeur affirme ne pas transmettre de données à des tiers, mais nous n’avons absolument aucun moyen de le vérifier ».
En pratique, Apple ou Google ne peuvent pas savoir ce qu’est un tiers. Des serveurs en Chine et à Hong Kong peuvent très bien être de première partie ; qui sait ? Personne à part le développeur de l’app.
Le Parti communiste chinois ne s’intéresse peut-être pas beaucoup aux données d’un individu donné, mais il s’intéresse énormément aux données agrégées. Elles deviennent aussi très utiles lorsqu’elles recoupent des cibles spécifiques, comme les données de millions d’employés du gouvernement américain collectées pendant des années [0][1].
La « grande expérience » selon laquelle le libre-échange et les échanges conduiraient la Chine vers la démocratie et la liberté a complètement échoué. Au final, elle n’a fait que renforcer une dictature impitoyable visant une expansion mondiale. Il ne faut pas faire affaire avec la Chine.
[0] https://en.wikipedia.org/wiki/Office_of_Personnel_Management...
[1] https://www.nbcnews.com/tech/security/china-spent-years-coll...
Il faut se rendre compte qu’un dispositif de surveillance finit lui aussi par consommer lentement ce qu’il surveille. On en arrive finalement à devoir surveiller activement le moniteur lui-même.
Cet appareil BLE vide lentement, mais sûrement, la batterie de la voiture. Un jour, lorsqu’il enverra une alerte, il faudra recharger la batterie, puis bientôt il cessera même d’envoyer des alertes.
En plus, il aspirera aussi les données du téléphone pour les envoyer en Chine, et consommera la batterie du téléphone. Difficile d’imaginer pire cadeau pour les fêtes : c’est une rare triple menace pour le consommateur.
Plus sérieusement, l’autodécharge est environ un ordre de grandeur supérieure à celle de ce moniteur.
Android a besoin d’une fonction permettant de fournir de fausses données GPS sur un vrai appareil. Ce serait utile pour les apps qui exigent le GPS sans aucune raison.
Si une app lampe torche a besoin du GPS pour s’allumer, pas de problème : ma position actuelle est le mont Kilimandjaro.
Les développeurs essaient même d’expliquer à l’utilisateur, via une pop-up, quelque chose du genre « appuyez sur Autoriser pour que Bluetooth fonctionne ».
À ce stade, il est raisonnable de supposer que ces appareils collectent de grandes quantités de données et les renvoient au siège. Je ne serais pas surpris que les routeurs TP-Link envoient aussi tout en Chine.
Cela dit, ce n’est pas limité à la Chine : l’iPhone que vous utilisez actuellement pourrait tout aussi bien envoyer toutes vos frappes clavier et vos données de localisation aux États-Unis.
Si vous soupçonnez un routeur TP-Link d’envoyer tout à un serveur distant, il suffit de surveiller le trafic.
Quand des amis se moquent de mon obsession pour la confidentialité et la collecte de données, je leur montre justement ce genre d’exemple
Il n’y a aucune raison de croire que cela soit fait avec des intentions malveillantes, mais en pratique, il n’y a aucun moyen de le savoir. C’est peut-être simplement de l’ignorance ou de l’incompétence
La quantité de données de localisation collectées par les fabricants d’appareils est considérable. S’ils les monétisent, je me demande si cela pourrait être considéré comme malveillant, même sans l’avoir divulgué à l’utilisateur final
Le SDK AMap utilisé par l’application collecte encore beaucoup plus de données de localisation. Ici, j’ai l’impression que l’objectif est plus probablement d’améliorer la précision des services de localisation et des logiciels de cartographie, et je ne considère pas cela comme malveillant en soi
En revanche, si ce comportement n’a pas été communiqué aux utilisateurs et aux développeurs, c’est une autre histoire. Le site est en chinois [1], et je ne sais même pas s’il y aura quelqu’un pour lire les conditions détaillées afin de le vérifier
[1] https://lbs.amap.com/api/lightweight-android-sdk/download
Cela me rappelle l’époque où je pensais que les boutons « Like » de Facebook sur tous les sites web étaient inoffensifs, avant de découvrir à quel point ils permettaient un suivi étendu sans consentement
La méthode typique de la Chine consiste à collecter délibérément des données d’une manière qui semble inoffensive en surface, ou à laisser volontairement grandes ouvertes des failles de sécurité pouvant être exploitées plus tard. Quand ils se font prendre, ils disent : « Désolé, nous allons corriger ça tout de suite »
Le pire, c’est que ce genre de comportement n’a aucune conséquence. Google, l’UE ou la FTC devraient infliger des amendes