Détectez les pisteurs sur Android avec exodus-standalone

Des bibliothèques tierces appelées pisteurs sont souvent présentes dans les applications mobiles, parfois au dépit des législations en vigueur, de la sécurité de ces applications ou des droits des personnes les utilisant.

Voyons ensemble ces problématiques plus en détails et comment s’en prémunir, en particulier sur Android.

Qu’est-ce qu’un pisteur et quels problèmes posent-ils ?

“Pisteur”, “traceur”, “traqueur”, plusieurs termes peuvent être utilisés pour parler de la même chose. Commençons par définir ce que nous allons appeler un pisteur dans le reste de cet article. Nous nous baserons sur la définition de l’association française à but non-lucratif Exodus Privacy. Un pisteur est une librairie de code, ou kit de développement (Software Development Kit ou SDK en anglais), chargée de collecter des informations sur la personne qui utilise une application, ou bien sur les usages ou l’environnement de cette personne. Nous pouvons citer parmi les plus fréquents : Google Analytics, Facebook Ads ou Twitter MoPub.

Ces librairies sont très largement utilisées dans le monde du développement d’applications (mais pas seulement) car elles permettent de gagner du temps et d’éviter de réinventer la roue à chaque projet. Elles se divisent en plusieurs catégories : analytique, rapports de crash, profilage, identification, publicité, localisation, etc.

Bien que pratiques et pouvant dans certains cas s’avérer légitimes, ces pisteurs peuvent poser des problèmes sur plusieurs aspects : la conformité réglementaire, la sécurité de votre application ou même son empreinte écologique.

La CNIL y dédie un chapitre entier de son “guide RGPD du développeur” sorti en janvier 2020, sous le nom “Maîtriser vos bibliothèques et vos SDK”. Afin de respecter le RGPD, elle considère nécessaire de réaliser les actions suivantes :

  • s’assurer que les parties tierces ayant développé ces bibliothèques respectent les législations en matière de données personnelles (par exemple pour le recueil du consentement des utilisateurs) ;
  • lire la documentation et changer la configuration par défaut, qui peut souvent engendrer des actions non désirées ;
  • auditer les bibliothèques intégrées pour vérifier ce qu’elles font : quelles données sont envoyées et à quels destinataires ;
  • auditer leur code afin de pouvoir les cartographier (certaines bibliothèques peuvent également intégrer d’autres composants).

Toutes ces actions représentent un coût significatif s’il doit être effectué pour chaque bibliothèque intégrée à une application. La CNIL recommande d’ailleurs tout simplement d’évaluer l’intérêt de l’ajout de chaque dépendance.

L’impact environnemental de votre application peut être aussi accentué par toutes les fonctionnalités (et donc lignes de code) supplémentaires ajoutées par ces pisteurs, ainsi que les appels réseaux et envois de données impliqués par celles-ci. La présence de pisteurs va potentiellement impacter le score remonté par des outils tels que GreenSpector (similaires à l’Ecoindex pour mobile). Ce dernier utilise d’ailleurs le nombre de pisteurs dans l’application comme un des critères de notation de l’empreinte écologique de celle-ci.

Les raisons évoquées précédemment peuvent enfin entraîner un impact en termes d’image auprès des personnes utilisatrices (et potentiellement du grand public) si votre application contient des pisteurs considérés comme non justifiés.

Maintenant que l’on est conscient des problèmes engendrés par la présence de ces bibliothèques, intéressons-nous à la manière de les détecter afin de s’assurer qu’il n’y a aucun pisteur non désiré ou non justifié dans votre application.

Comment détecter les pisteurs ?

L’association Exodus Privacy a développé une plateforme appelée εxodus permettant de détecter les pisteurs dans les applications Android. A noter que si l’association ne propose pas d’outil pour détecter les pisteurs sur iOS, à cause des DRM mis en place par Apple, elle explique que le problème est similaire sur les deux systèmes.

Le cœur de la plateforme εxodus, le module python exodus-core, va examiner la liste des librairies présentes dans une application et la comparer avec des signatures issues d’une base de connaissances, contenant la liste des pisteurs connus.

Si une des classes présentes dans l’application correspond à une signature, l’outil considère que le pisteur est embarqué.

Illustration de l'analyse statique

source : Exodus Privacy

Cette méthode d’analyse statique (c’est-à-dire sans exécuter l’application) a certaines limites (impossible de savoir si le code est réellement exécuté) mais a pour avantage d’être rapide et automatisable facilement.

Un exemple de rapport sur la plateforme εxodus

Un exemple de rapport sur la plateforme εxodus

Le module exodus-core est aussi présent dans un autre outil proposé par l’association, qui peut être utilisé dans le cadre d’audits de sécurité ou de conformité (pour vérifier l’application livrée par un prestataire par exemple) ou bien dans une pipeline de déploiement. Nous allons nous concentrer sur ce deuxième cas d’usage et voir comment détecter au plus tôt les pisteurs dans son application.

Détecter les pisteurs dans la pipeline de son application Android

Pour permettre à tout le monde de faire ses propres analyses, par exemple avant la publication d’une application sur un store, l’association propose donc l’outil intitulé exodus-standalone.

Cet outil simple, disponible sous la forme de scripts python ou packagé dans une image Docker, nous permet d’effectuer cette analyse de manière rapide (de l’ordre de quelques secondes). Cette dernière peut donc être effectuée après chaque build de votre application Android et avant son déploiement.

Ci-dessous un exemple d’intégration de l’outil dans GitLab CI/CD :

---
stages:
  - build
  - audit
  - deploy

build_apk:
  stage: build
  image: <votre image de build>
  script:
    - <votre script de build>
  artifacts:
    paths:
      -  my_app.apk

check_trackers:
  stage: audit
  image:
    name: exodusprivacy/exodus-standalone:1.2.1
    entrypoint: [""]
  script:
    - python /exodus_analyze.py my_app.apk

...

L’outil vous retournera un résultat similaire à celui-ci :

Le retour du script exodus-standalone

Si au moins un pisteur est détecté lors de l’analyse, la tâche sera alors considérée comme un échec.

L’outil répond donc à notre problématique via les critères suivants :

  • Il rapporte le nombre de pisteurs ainsi que les permissions demandées ;
  • L’analyse est rapide et facile à intégrer dans une pipeline de déploiement ;
  • Le format JSON est supporté pour permettre d’exploiter la sortie de l’outil ;
  • Le code est libre et open source (l’outil exodus-standalone, le module exodus-core mais aussi la base de connaissance de pisteurs).

A noter que l’outil a été ajouté en 2020 au Socle Interministériel de Logiciels Libres (catalogue de référence pour les administrations françaises), au statut “en observation”.

On peut néanmoins noter les limitations suivantes :

  • L’outil ne propose pas de règles fines sur les pisteurs “attendus”, c’est tout blanc ou tout noir ;
  • La liste des pisteurs connus étant amenée à évoluer, sans présence de cache votre pipeline peut casser sans modification dans votre code ;
  • L’image Docker est seulement disponible sur le DockerHub, ce qui peut être limitant suite à leurs nouvelles restrictions.

Conclusion

La réduction du nombre de pisteurs dans ses applications est amenée à se généraliser pour différentes raisons : risque en termes d’image, risque de non-conformité aux législations en vigueur, risque de sécurité, réduction de l’empreinte écologique, raisons éthiques.

L’outil exodus-standalone vous permet d’intégrer cette analyse dans vos processus de développement ou de déploiement pour un coût réduit afin de les détecter au plus tôt et de ne conserver que ceux que vous considérez comme essentiels.

Aller plus loin

L’outil exodus-standalone reste limité dans les informations qu’il remonte. Dans le cas où l’on voudrait aller plus loin dans l’audit d’une application Android, il existe d’autres outils tels que Mobile Security Framework (MobSF). Outil open-source proposé par OpenSecurity, celui-ci intègre un scan exodus pour lister les pisteurs présents dans l’application mais fait aussi de la décompilation et de l’analyse dynamique de l’application. Il est donc plus coûteux à mettre en place, mais propose davantage de fonctionnalités de sécurité (par exemple la détection de malware).

Enfin, pour les personnes se sentant concernées à titre personnel par le problème de la présence des pisteurs dans les applications, Exodus Privacy met à disposition une liste de quelques outils et pratiques pour mieux maîtriser sa vie privée sur mobile.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *


Ce formulaire est protégé par Google Recaptcha