Pithus : un projet pour analyser les dangers des applications Android

Pithus est le nouveau projet d'Esther, déjà à l’origine d’ExodusPrivacy. Son objectif est de réunir les outils dont elle se sert au quotidien pour fournir un ensemble cohérent capable de « débroussailler » le terrain sur la sécurité d’une application Android et en faciliter l'accès.

Esther, membre très active de la communauté de la sécurité, a récemment ouvert les vannes d’un projet développé sur son temps personnel : Pithus. Un nom choisi en référence au pithos (jarre) de Pandore.

Où Exodus Privacy cherchait à analyser le comportement des applications dans le domaine des données personnelles, avec un accent fort mis sur les outils de pistage et le respect de la vie privée, Pithus se concentre sur un autre aspect tout aussi important, en tentant d'y trouver d’éventuels comportements malveillants.

Il réunit divers outils comme SSdeep et Dexofuzzy pour plonger dans les fichiers APK, format des applications Android. Il ne s’agit pas d’un outil livrant clé en main un verdict sur la sécurité d’une application, mais d’un moyen de déblayer le terrain pour donner des pistes, qui peuvent aboutir à un faisceau d’indices.

Comme Esther nous l’a indiqué, Pithus s’adresse à un public « plus technique que celui d’Exodus ».

• Accéder à Pithus

Les motivations derrière Pithus

Pour elle, « le marché des applications mobiles est très opaque [...] font-elles ce qu’elles annoncent ? En font-elles plus ? Si oui, quoi ? ». « J’ai développé Pithus comme un projet personnel, en réutilisant des outils dont je me sers régulièrement quand je travaille. L’idée était de les rassembler dans un même endroit et de fournir une interface web pour les résultats », nous explique la chercheuse à l'occasion d'un entretien.

Elle a en fait lancé Pithus le 31 décembre à 23h00 : « Parce que je voulais vraiment qu’il sorte en 2020 ». Le temps d’effectuer quelques derniers tours de vis, elle l'a officialisé début février, en en expliquant les grandes lignes. Le projet étant personnel, il a été développé sur son temps et ses fonds propres. L’hébergement est à sa charge, mais est pour l’instant couvert par des dons (réalisés via LiberaPay).

Esther indique se servir de Pithus désormais pour son propre travail, lorsqu’elle est mandatée par exemple par une entreprise pour faire une analyse de son application (tests de robustesse, conformité au RGPD, etc.). Elle ne se sert cependant pas de l’instance mise à disposition, « car tous les rapports générés sont publics », avec liens uniques pour les partager. Pas question donc que les résultats de ses missions rémunérées soient disponibles à tous.

Le projet est open source (licence AGPL), Esther encourageant les intéressés à en reprendre le code pour le manipuler, l’améliorer, etc. Elle se dit intéressée par les retours, quelques suggestions ayant déjà été faites. Il n’y a pas de feuille de route à proprement parler, le développement dépendra de son temps libre et des contributions.

Comment fonctionne Pithus ?

La page d’accueil de Pithus propose deux fonctions : chercher dans la base des rapports ou importer un fichier APK, dont la taille ne doit pas dépasser 65,3 Mo. Après envoi du fichier, Pithus le traite puis génère une page globale de résultats contenant diverses rubriques. L’ensemble est en anglais.

Durant notre entretien, Esther nous a fourni l’exemple d’une application nommée TeaTV, de son nom unique bahamas.serietv3. Une brève recherche nous apprend qu’elle sert simplement à tenir un catalogue des séries, en marquant les épisodes vus, etc. Le rapport généré ressemble à ceci :

Les premières informations données sont d’ordre très général. En haut à gauche, on peut voir « Threat 1/63 », qui signifie que sur l’ensemble des 63 antivirus de VirusTotal, un seul a reconnu l’application comme malveillante. Un faux positif ? « Pas forcément. Il peut aussi s’agir d’un élément nouveau ».

Les grandes cases donnent plusieurs renseignements techniques : l’application peut demander un total de 32 permissions, possède 60 activités, 21 services (tâches de fond), 9 receivers (détecteurs d’évènements extérieurs) et peut contacter jusqu’à 79 domaines. Une vue de synthèse technique qui n’a pas réellement de signification en soi.

Les informations de la deuxième ligne, sous la forme d'onglets, sont beaucoup plus complètes.Fingerprints fournit ainsi les sommes de contrôle MD5, SHA1 et SHA256 de l’APK. On y trouve juste en dessous sa taille exacte : 16,68 Mo. APKiD fournit ensuite une liste d’éléments que l’application peut contrôler. Dans le cas présent, elle peut ainsi demander à vérifier le modèle de smartphone, le constructeur, la référence produit, le numéro de série, etc.

Comme nous l’explique Esther, la présence de lignes « anti_vm » est un indicateur que l’application va chercher à identifier que l’environnement est bien un smartphone, et pas un émulateur quelconque. Un point important pour les chercheurs, car les simulations passent souvent par des machines virtuelles.

Entrent ensuite en piste SSdeep et Dexofuzzy, qui vont fournir des empreintes (hash) localement sensibles. Elles sont fournies pour l’APK et ses principaux constituants. Esther nous explique qu’elles peuvent servir à retrouver d’autres APK ayant un certain pourcentage de similarité au niveau binaire. Si l’on trouve un tel pourcentage avec une application déjà identifiée comme contenant un malware, il y a clairement suspicion.

Prenons un exemple avec l’application org.xmlpush.v3, qui contient le malware Android.Trojan.Belesak. L’analyse Dexofuzzy renvoie vers une empreinte présentant un taux de similarité de 32 % avec une autre application. Si l’on clique sur le hash, on tombe sur un élément intégrant le spyware Android.Spyware.TechFu. Il s’agit en fait de la même famille de spywares, FinSpy, développée par une société allemande. Esther en avait fourni une analyse à Amnesty International qui voulait en savoir plus sur son fonctionnement.

Des analyses en pagaille

La section Threat intelligence va puiser dans les informations de la base MalwareBazaar pour donner les éventuels renseignements déjà connus. Dans la première fiche, on ne retrouve que le score VirusTotal. Dans la deuxième, on peut voir les détails de Belesak et son identification le 12 octobre 2019. Pour cette deuxième application, 29 antivirus ont reconnu son comportement malveillant.

APK analysis fournit bon nombre d’informations détaillées sur l’APK proprement dit. On retrouve les informations techniques comme le nom de l’application, sa version ou encore les versions utilisées du SDK Android.

Un peu plus bas, Pithus affiche les informations sur le certificat, notamment les empreintes et la personne l’ayant demandé. Des données fournies par AndroGuard. En dessous, on trouve l’une des parties les plus intéressantes de Pithus : l’analyse du manifeste. Vont y être pointés des comportements potentiellement problématiques.

Dans le cas qui nous intéresse, on y trouve des communications en clair (HTTP) ainsi que bon nombre de services et de receivers partagés avec d’autres applications, des activités pouvant obtenir des droits root ou encore la permission d’installer d’autres paquets.

Viennent ensuite les listes complètes des activités, receivers et services présents dans l’application.

Plus loin dans les comportements problématiques

Avec l’analyse de code, on plonge un peu plus en profondeur. L’analyse NIAP, fournie par MobSF, décrit ainsi toute une liste d’actions en lien avec le chiffrement des données. Ces informations pointent vers un respect plus ou moins grand des bonnes pratiques dans ce domaine. Plus bas, les choses sérieuses commencent vraiment.

Dans l’application qui nous sert d’exemple, on trouve ainsi une ribambelle de comportements douteux. Comme le précise Esther, ils ne sont pas tous nécessairement « volontaires ». Il s’agit surtout de déterminer si l’ensemble des signaux fournis par Pithus constitue un faisceau d’indices pointant vers un comportement malveillant.

On trouve ainsi une liste de problèmes relevés, dont les niveaux de dangerosité sont Low, Medium ou High. Ces derniers, en rouge, attirent immédiatement le regard. Par exemple, TeaTV peut lire et écrire sur le stockage externe. Si ce n’est pas un danger en soi, il faut savoir que n’importe quelle autre application ayant les mêmes droits va pouvoir lire ce qu’inscrit TeaTV sur la carte SD. Il peut alors y avoir échange de données.

On continue avec des fichiers pouvant contenir des informations sensibles codées en dur, l’emploi d’un générateur de nombres aléatoires reconnu comme peu sûr, la possible exécution de requêtes SQL (pouvant mener à des injections SQL), l’utilisation d’un algorithme faible de hachage, la création de fichiers temporaires ou encore la possible requête de droits root.

Ces éléments, issus de l’analyse statique de MobSF, sont ensuite à détailler. Exemple type, l’utilisation du générateur reconnu comme peu sûr n’est pas forcément un souci. Tout dépend en fait du mécanisme dans lequel il est impliqué. « Si on prend une application qui permet de lancer des dés et de générer une combinaison aléatoire, ce n’est pas grave », explique Esther. Si c’est pour chiffrer une information sensible, c’est un tout autre problème.

La section Behaviour analysis, tire parti d'Exodus. Elle fournit notamment une analyse des permissions, avec là encore un étiquetage Low/Medium/High. On peut voir dans l’exemple que l’application s’arroge le droit d’enregistrer l’audio par le micro, de lire/modifier/effacer du contenu sur le stockage externe, d’obtenir la localisation précise du GPS, de lire les SMS ou encore d'intercepter les appels sortants.

Des autorisations dont on se demande ce qu’une application centrée sur les séries pourrait faire. Et encore il ne s’agit là que de celles étiquetées en rouge.

Si Tracking analysis reprend simplement les outils de pistage détectés dans l’application – beaucoup en ont pour l’affichage des publicités – Threat analysis fournit une nouvelle liste de comportements directement problématiques ou pouvant l’être selon le contexte. Démarrer d’autres applications est ainsi un comportement courant pour une application malveillante, qui aura la capacité de récupérer une charge virale et ainsi de l’exécuter.

Obtenir la liste des paquets installés, récolter les chemins absolus de certains fichiers et les consigner dans un fichier JSON ainsi que récupérer les numéros IMEI et IMSI font partie des méthodes préférées pour constituer un identifiant unique pour le pistage publicitaire (fingerprinting). L’accès aux IMEI et IMSI est tout particulièrement sensible, s’agissant de références uniques.

L’application est également capable de récolter les adresses MAC des points d’accès Wi-Fi, leur SSID ainsi que la force du signal pour chaque connexion. Idéal pour trianguler une position. Encore une fois, on se demande pourquoi elle peut avoir besoin de renseignements aussi précis.

Enfin, Network Analysis donne le détail des domaines contactés ainsi que la liste des adresses trouvées dans le code, quand c’est possible. Esther nous explique pour cette liste que les URL peuvent être simplement contenues dans les commentaires du code, par exemple lorsque le développeur a « oublié » de les nettoyer. Dans le cas présent, beaucoup sont des liens vers des problèmes référencés sur GitHub pour le projet gRPC-Java.

Ce que l’on peut tirer de Pithus

Pithus peut couvrir de multiples besoins. Pour les chercheurs, il fournit une vue d’ensemble présentant rapidement un risque ou un danger avéré, par exemple quand l’application a déjà été identifiée comme malveillante. Les développeurs et éditeurs peuvent aussi s'en servir pour constater d'éventuels problèmes dans leurs produits.

Hors de la communauté de la sécurité, n’importe quelle personne avec quelques connaissances techniques peut se servir de Pithus pour analyser le comportement d’une application qui lui parait louche, ou tout simplement pour faire le tri dans les siennes. Un utilisateur Android pourrait tout à fait décider de faire le point sur les applications dont il se sert, éliminer celles lui paraissant les moins vertueuses ou échanger avec les développeurs sur le sujet.

Pithus semble être un bon moyen de faire un état des lieux sur le suivi des bonnes pratiques dans le domaine de la sécurité. Repérer des problèmes ne fait pas nécessairement d’une application un outil à éviter, similaire à un malware, mais le manque de connaissances dans la sécurisation des développements peut conduire à des failles, qui n’attendront que d'être exploitées. Espérons que cette avancée permettra de mieux sensibiliser sur le sujet.