IMA5 2019/2020 P20 - Historique des versions

Mcreteur : /* Décompilation */

2019-12-17T19:48:51Z

‎Décompilation

Mcreteur : /* Automatisation */

2019-12-17T19:45:39Z

‎Automatisation

Mcreteur : /* Automatisation */

2019-12-17T19:35:28Z

‎Automatisation

Mcreteur : /* Automatisation du processus */

2019-12-17T18:46:19Z

‎Automatisation du processus

Mcreteur : /* Automatisation du processus */

2019-12-17T18:46:01Z

‎Automatisation du processus

Mcreteur : /* Documents Rendus */

2019-12-17T18:45:33Z

‎Documents Rendus

Mcreteur : /* Ecoute de la communication application mobile - objet connecté */

2019-12-17T18:40:13Z

‎Ecoute de la communication application mobile - objet connecté

Mcreteur : /* Reverse engineering sur l'application mobile associée à l'objet */

2019-12-17T18:29:41Z

‎Reverse engineering sur l'application mobile associée à l'objet

Mcreteur : /* Récupération de données utilisateur et firmware d'un objet connecté */

2019-12-17T18:27:23Z

‎Récupération de données utilisateur et firmware d'un objet connecté

Mcreteur : /* Choix techniques : matériel et logiciel */

2019-12-17T18:11:03Z

‎Choix techniques : matériel et logiciel

← Version précédente		Version du 17 décembre 2019 à 19:48
Ligne 166 :		Ligne 166 :

	J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.		J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.
		+
		+	Les deux outils présentés précédemment ne permettent que de transformer les fichiers Dalvik Executable de l'APK en fichiers java. Afin de pouvoir exploiter les fichiers comme le AndroidManifest.xml accompagnant toute application Android ou les ressources qui lui sont associées, on peut utiliser apktool :
		+
		+	apktool decode application.apk

	===Analyse du code source===		===Analyse du code source===

← Version précédente		Version du 17 décembre 2019 à 19:45
Ligne 230 :		Ligne 230 :


		+	===Tests===

−	~~===Tests===~~	+	Afin de tester la pertinence et l'efficacité de l'outil développé, je l'ai essayé sur plusieurs applications mobiles Android d'IoT plus ou moins connues. Les résultats ont été plutôt satisfaisant puisque pour les 4 applications analysées j'ai pu récupérer l'adresse de l'API utilisée ainsi que le type de base de données. L'analyse de certaines applications a révélé l'utilisation des fonctions de log Android ainsi que des appels HTTP. Dans les 4 applications, des occurrences au mot clé firmware ont été trouvées. J'ai pu récupéré aussi un grand nombre de requête SQL. Je me suis rendu compte que les 4 applications testées présentaient des parties de code obfusquées, ce qui n'avait pas été le cas pour l'application étudiée dans ce projet. L’outil développé remplit donc son rôle, à savoir, décompiler et décoder une application ainsi que présenter à l’utilisateur des morceaux de code qui vont lui permettre de comprendre de façon générale le fonctionnement de l’application et de lui donner des pistes pour une analyse plus profonde. Les morceaux de code recherchés par l’outil ont été défini à partir de l’analyse manuelle que j’ai pu réaliser sur l’application étudiée et ne sont donc peut-être pas pertinents pour tout le monde. L’outil conçu n’est pas fait pour être figé, l’analyse peut être modifiée rapidement selon les préférences de l’utilisateur, le plus gros du travail étant déjà réalisé.

	=Documents Rendus=		=Documents Rendus=

← Version précédente		Version du 17 décembre 2019 à 19:35
Ligne 206 :		Ligne 206 :

	===Outil développé===		===Outil développé===
		+
		+	Le but final de ce projet étant d’essayer d’automatiser les méthodes et outils proposés, j’ai développé un script permettant d’avoir une première impression sur le code d’une application mobile à partir de son APK. Ce script gère le processus de décompilation et de décodage avec les outils dex2jar, CFR et apktool avant de réaliser une analyse statique du code obtenu.
		+	Ayant besoin d’un fichier APK et des outils cités précédemment, ce script s’utilise de la façon suivante :
		+	$ apk_analysis.sh {application.apk} {chemin_vers_dossier_dex2jar} {chemin_vers_CFR.jar} {chemin_vers_apktool}
		+	Si le nombre d’arguments qui lui sont présentés n’est pas correct, un rappel d’utilisation est affiché à l’utilisateur.
		+	Une fois la décompilation et le décodage réalisé, une analyse est lancée afin de trouver dans le code :
		+	*Les permissions requises par l’application
		+	*Les features Android utilisées
		+	*La présence des propriétés android:allowBackup et android:debuggable
		+	*La présence d’URL
		+	*La présence d’appel HTTP
		+	*La présence de log Android
		+	*La base de données utilisée par l’application
		+	*La présence de requête SQL
		+	*La présence de hash MD5
		+	*La présence des mots clés “login=”, “admin=”, “password=”, “passwd=”, “apikey=”, “secret=”, “token=”, “firmware” ou encore “url=”
		+
		+	Ces recherches sont réalisées à l’aide de la commande grep et d’expressions régulières. Le résultat de l’analyse est enregistré dans le fichier {nom_de_l’application}_analysis.txt créé dans le répertoire courant. Un dossier contenant la décompilation et le décodage de l’APK est créé aussi à cet endroit avec pour nom le nom de l’application analysée, ce dernier étant extrait du nom du fichier APK.
		+	J’ai développé ce script non pas uniquement pour repérer des failles de sécurité dans l’application mais plutôt afin d’avoir une idée grossière de comment l’application étudiée fonctionne en me basant sur l’étude que j’ai réalisé manuellement dans ce projet tout en essayant de rendre l’analyse pertinente à n’importe quelle application Android.
		+	La décompilation d’une application ne décompilant pas uniquement le code produit par les développeurs mais aussi toutes les ressources utilisées, la difficulté dans le travail effectué a été de savoir dans quel(s) dossier(s) effectuer chaque partie de l’analyse afin de ne récupérer que ce qu’il nous intéresse vraiment. Par exemple, pour l’analyse des appels aux fonctions de log Android, j’ai remarqué que de nombreuses ressources/dépendances faisaient des appels à ces fonctions et cela ne nous intéresse pas du tout de savoir quels sont ces logs. Afin d’éviter cela, j’ai extrait le nom du package écrit dans le fichier AndroidManifest afin de le transformer en chemin. C’est généralement dans ce package que se trouve tout le code nous intéressant. J’ai cependant dû modifier le comportement de mon script lorsque je me suis rendu compte qu’après décompilation de certaines applications, le package écrit dans le manifeste Android n’existe pas. J’ai donc dû mettre en place une recherche de ce package avant toute analyse afin de vérifier son existence. Si il n’existe pas, il n’y a pas d’autres choix que d’élargir la recherche à tout le code excepté quelques dossiers que l’on retrouve régulièrement comme android ou androidx.
		+	En revanche, pour la recherche de mots clés ou de requêtes SQL par exemple, il va être intéressant de réaliser l’analyse dans l’intégralité du code puisque je me suis rendu compte qu’assez souvent, on trouvait certains mots clés ou requêtes SQL dans le code smali que l’on ne retrouvait pas dans le code java, faute de décompilation ou autre.
		+	L’utilisateur se verra alors parasité avec quelques résultats ne l’intéressant pas mais je n’ai pas trouvé de meilleure solution pour être plus précis dans les recherches. Dans tous les cas, le tri manuel par l’utilisateur des résultats obtenus restera beaucoup plus rapide qu’une analyse manuelle fichier par fichier.
		+
		+

	===Tests===		===Tests===

@@ Ligne 203 : / Ligne 203 : @@
 Malheureusement je n'ai pas pu tirer d'informations importantes des logs de l'application.
-==Automatisation du processus==
+==Automatisation==
 ===Outil développé===

← Version précédente		Version du 17 décembre 2019 à 18:46
Ligne 204 :		Ligne 204 :

	==Automatisation du processus==		==Automatisation du processus==
		+
		+	===Outil développé===
		+
		+	===Tests===

	=Documents Rendus=		=Documents Rendus=

← Version précédente		Version du 17 décembre 2019 à 18:45
Ligne 208 :		Ligne 208 :

	https://archives.plil.fr/mcreteur/Plateforme_cyber.git		https://archives.plil.fr/mcreteur/Plateforme_cyber.git
		+
		+	Ayant convenu avec les encadrants de ne mettre aucun des résultats obtenus dans ce wiki public en raison des effets que cela pourrait provoquer vis à vis de la société commercialisant l'objet étudié, le rapport de ce projet n'a été communiqué que par mail aux encadrants.

@@ Ligne 149 : / Ligne 149 : @@
 ===Ecoute de la communication application mobile - objet connecté===
+La dernière piste pour récupérer le firmware de l'objet est l'écoute de la communication bluetooth ayant lieue entre l'objet connecté et l'application mobile pour le transfert de données ou de mise à jour. Ayant commencé à explorer cette piste en tout fin de projet, j'ai du faire avec le matériel disponible, un LimeSDR qui est un radio logiciel. La recherche d'un programme compatible avec le LimeSDR permettant de capturer les communications bluetooth n'a pas été très fructueuse puisque je n'ai trouvé qu'un seul outil sous forme de projet sur github, [https://github.com/jocover/BLESDR blesdr]. Après 3 tentatives, ce programme ne m'a permis de récupérer que les paquets d'advertising.
-Des captures d'écran illustrant les résultats sont visibles sur le wiki du projet Gitlab.
+Après quelques recherches il semblerait qu'un development kit nRF52 ou 51 ou un Adafruit Bluefruit programmés avec le nRF sniffer permettraient de réaliser l'action souhaitée et de manière beaucoup plus simple.
 ==Reverse engineering sur l'application mobile associée à l'objet==

@@ Ligne 158 : / Ligne 158 : @@
 C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution.
 Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.
@@ Ligne 166 : / Ligne 167 : @@
 J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.
 Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware.
@@ Ligne 180 : / Ligne 182 : @@
 J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application.
 En analysant le manifeste android de l'application, j'ai pu localiser la présence d'une propriété très interessante :
@@ Ligne 196 : / Ligne 201 : @@
 Au cours de l'analyse du code source, j'ai pu remarquer que certaines informations étaient loggées. Android Debug Bridge m'a alors été encore utile puisqu'il m'a permis de suivre les logs de l'application avec logcat via la commande :
     adb logcat {nom_package_cible}
 Malheureusement je n'ai pas pu tirer d'informations importantes des logs de l'application.
 ==Automatisation du processus==

@@ Ligne 90 : / Ligne 90 : @@
 ==Récupération de données utilisateur et firmware d'un objet connecté==
 En ouvrant l'objet connecté étudié, nous nous sommes rendus compte de la présence de pins de debug RX, TX, CLK, IO, VCC, GND. Avec l'aide de Thierry Flamen, nous avons soudé des fils de connexion sur chacun de ces pins afin de pouvoir les exploiter.
-Dans un premier temps, j'ai utilisé un convertisseur série -> USB afin d'exploiter les pins TX et RX. Je n'ai eu aucun résultat avec minicom.
+Dans un premier temps, j'ai utilisé un convertisseur série -> USB afin d'exploiter les pins TX et RX. Je n'ai eu aucun résultat avec minicom. Afin de vérifier que rien n'était envoyé par l'objet sur les Rx et Tx, j'ai utilisé un oscilloscope. La différence de potentielle observée entre les pins Tx et GND était trop faible pour qu'une quelconque information ne soit envoyée via l'UART de l'objet.
 Dans un second temps, j'ai utilisé un JLink SEGGER debugger, dispositif permettant de debugger des micro-controleurs dont celui présent dans l'objet étudié. Le constructeur du micro-controleur en question met à disposition un outil en ligne de commande permettant entre autres de programmer la puce ou de lire son contenu par l'intermédiaire du JLink. J'ai alors connecté ce dernier à l'objet avec les pins de Serial Wire Debug CLK et IO présents sur le circuit puis tenté de récupérer le firmware :
@@ Ligne 99 : / Ligne 100 : @@
 J'ai alors été confronté à une protection empêchant la lecture des données. Après quelques recherches, le seul moyen d'enlever cette protection serait d'effacer le contenu du micro-contrôleur et de le reprogrammer. Cela n'est pas envisageable puisque ceux sont les données actuellement présentes dans l'objet que je souhaite récupérer.
 Suite à ces deux impasses, j'ai du me tourner vers la dernière piste pour la récupération des données de l'objet, à savoir, exploiter le fait que l'objet puisse être mis à jour à partir de l'application mobile associée.
@@ Ligne 104 : / Ligne 107 : @@
 Afin de mettre à jour l'objet connecté, après appairage, l'application mobile réalise des appels API sur un serveur distant afin de vérifier si l'objet est à jour ou non et récupérer la dernière version du firmware. J'ai donc décidé d'observer ces communications afin de voir si il y avait quelque chose à exploiter à ce niveau. Pour cela, j'ai utilisé le logiciel OWASP ZAP qui est un proxy présentant de nombreuses fonctionnalités de pentest. Après avoir installé ce proxy sur mon ordinateur. J'ai configuré un smartphone android pour utiliser ce dernier. Dès lors, toutes les requêtes HTTP passent par l'OWASP ZAP avant d'atteindre leur cible. Le logiciel permet alors de visualiser toutes les requêtes réalisées à partir du smartphone avec les différents paramètres envoyées ainsi que les réponses reçues. Une fois le proxy mis en place, j'ai pu visualiser les différents échanges réalisées entre l'application mobile associée à l'objet connecté à son lancement et le serveur distant. Un premier appel de login est réalisé au lancement de l'application. J'ai pu retrouver en clair sur le logiciel servant de proxy, les paramètres associées à cet appel, à savoir, mon adresse email servant de login ainsi que mon mot de passe. Les identifiants étant corrects, le serveur distant envoie en réponse un token nécessaire à tous les autres appels API. Ce token est aussi lisible sur le logiciel. Après avoir récupéré mon token, j'ai tenté de réaliser un appel API via Postman. Cela a fonctionné et nous pouvons donc de cette façon, récupérer les données stockées sur le serveur distant.
-Après ce premier appel de login, un appel de vérification de la version du firmware est réalisé. L'objet en ma possession n'étant pas à jour, il s'en est suivi un autre appel afin de récupérer la mise à jour à appliquer sur l'objet. La mise à jour a alors été téléchargé sur le smartphone. Après avoir installé un explorateur de fichiers sur ce dernier, j'ai rapidement retrouvé le fichier de mise à jour téléchargé. Malheureusement, ce fichier d'extension .des semble être un fichier encrypté.
+Après ce premier appel de login, un appel de vérification de la version du firmware est réalisé. L'objet en ma possession n'étant pas à jour, il s'en est suivi un autre appel afin de récupérer la mise à jour à appliquer sur l'objet. La mise à jour a alors été téléchargé sur le smartphone. Après avoir installé un explorateur de fichiers sur ce dernier, j'ai rapidement retrouvé le fichier de mise à jour téléchargé.
-Le sujet de ce projet ne portant pas en particulier sur l'objet utilisé pour les expérimentations et ne voulant pas perdre de temps, je n'ai pas poursuivi de recherche visant à trouver comment exploiter ce fichier. En revanche, j'ai utilisé le "Damn Vulnerable Router Firmware" qui est un firmware dédié à l'expérimentation afin de tester les différents logiciels existants pour l'analyse d'un firmware.
+===Analyse d'un firmware===
 Après avoir récupéré le binaire du firmware, j'ai utilisé Binwalk. Binwalk est un outil d'analyse de firmware qui permet de scanner la signature d'un binaire, d'analyser les différents fichiers y étant présents, d'en réaliser une extraction ou encore de mesurer l'entropie du binaire afin de savoir si le firmware est encrypté ou non.
@@ Ligne 141 : / Ligne 146 : @@
 Cet outil permet un gain de temps conséquent et est semblable à ce que nous avions prévu de réaliser dans la partie automatisation pour l'analyse du code source d'applications mobiles.

@@ Ligne 29 : / Ligne 29 : @@
 * Un objet connecté à exploiter à définir avec les encadrants, dont le nom et les résultats obtenus sur ce dernier ne seront pas explicités ici
-* Convertisseur série -> USB pour l'exploitation de pins de communication série
+* Convertisseur USB - TTL pour l'exploitation de pins de communication série
-* Debugger pour l'exploitation de pins de debug
+* Segger JLink pour l'exploitation de pins de Serial Wire Debug
 Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer :
-* Ghidra
+* [https://ghidra-sre.org/ Ghidra]
-* IDA
+* [https://rada.re/n/ Radare2]
-* Radare2
+* [https://github.com/ReFirmLabs/binwalk Binwalk]
-* Binwalk
+* [https://github.com/craigz28/firmwalker Firmwalker]
-* Firmwalker
+* [https://ibotpeaches.github.io/Apktool/ Apktool]
-* Apktool
+* [https://github.com/pxb1988/dex2jar dex2jar]
-* dex2jar
+* [https://java-decompiler.github.io/ JDGUI]
-* JDGUI
+* [https://www.benf.org/other/cfr/ CFR decompiler]
-* CFR decompiler
+* [https://www.zaproxy.org/ OWASP ZAP]
-* OWASP ZAP
+* [https://developer.android.com/studio/command-line/adb Android Debug Bridge]
-* Android Debug Bridge
+* [https://github.com/nelenkov/android-backup-extractor Android backup extractor]
 ==Liste des tâches à effectuer==