Android
Dernière mise à jour
Cet article vous a-t-il été utile ?
Dernière mise à jour
Cet article vous a-t-il été utile ?
: History des versions d'android et leurs nouveautés.
: Application android vulnérable (Sorte d'équivalent de DVWA ou Mutillidae pour Android).
Les différents composants des appareils android sont les suivants:
Le noyau linux: Le noyau utilisé a été spécialement modifié par Google en dehors du cycle de développement classique pour l’environnement mobile.
Hardware Abstraction Layer (HAL): la couche d’abstraction matérielle représente l’interface entre le système et la partie Hardware c’est-à-dire le matériel. Il s’agit ni plus ni moins d’une interface qui fournit des fonctions génériques afin d’interagir avec le matériel tout en faisant abstraction des détails d’implémentation bas-niveau (audio, stockage, etc.).
Android Runtime (ART): ART est un environnement d'exécution utilisé principalement par le système d'exploitation Android. Il vise à remplacer la machine virtuelle Dalvik et à remplacer le bytecode par des instructions natives.
Native Libraries: un ensemble de bibliothèques et ressources permettant d’interagir avec le système : SSL, SQLite, Webkit, OpenGLsara, etc.
Android Framework: API Android utilisée par les développeurs d’applications, on y trouve des interfaces et des classes: ContentProviders, ActivityManager, ViewManager, etc.
Applications: elles appartiennent à la dernière couche du modèle présenté. Il s’agit de ce que l’on trouve communément sur tous les appareils (le navigateur, les contacts, la boîte à meuh, etc.).
La protection des données statiques se fait via deux éléments:
Le FBE (File-Based Encryption): protège les noms de fichiers et les données mais ne protège pas les métadonnées (telles que la taille du fichier ou l'heure de modification). À partir d'Android 9.0 ("Pie"), le chiffrement des métadonnées est pris en charge en générant une clé Keymaster utilisée pour chiffrer tout autre chose que les noms de fichiers et les données.
Le FDE (Full Disk Encryption): Chiffrement du disque de la même manière que pour un ordinateur par exemple.
Pour ce qui est de la protection dynamique, toutes transmission est chiffrée.
Cependant les versions antérieur à Android 7.0 ne supportent pas le FBE et celles antérieur à Android 4.4 ne supportent même pas le FDE.
Sur Android, chaque application fonctionne avec son propre utilisateur qui a son propre UID (User ID). Une sandbox existe également pour les processus et services (téléphone, WIFI, Bluetooth...).
Android dispose également d'un contrôle d'accès obligatoire qui dicte les actions autorisées par processus ou ensemble de processus à l'aide de Security Enhanced Linux (SE-Linux).
Android utilise des signatures d'application pour vérifier que les applications n'ont pas été trafiqué/manipulés. Les développeurs agréés doivent générer ces signatures avant de soumettre une application à la boutique d'applications officielle de la plate-forme.
Bonne ou mauvaise chose (suivant l'utilisateur qui l'utilise): Android permet à ces utilisateurs d'autoriser le téléchargement et l'exécution d'applications non vérifiées en activant un paramètre disponible dans les paramètres d'applications.
les fournisseurs d'appareils Android installent également parfois leur propre magasin d'applications personnalisé qui peuvent ne pas nécessairement respecter cette restriction.
Bonne chose car cela laisse plus de liberté aux utilisateurs Android dans le choix des applications qu'ils veulent utiliser (si il sait ce qu'il fait et connait l'éditeur).
Mauvaise chose également car cela laisse la porte ouverte à des applications potentiellement malveillantes. Le paramètre en question est désactivé par défaut mais les attaquant savent généralement manipuler leur cible pour la leur faire activer si la personne en question n'est pas assez sensibilisée au risques liées aux attaques sur mobile.
Tout le monde connais les méthodes d'authentification sur mobile allant des méthodes classiques (PIN, modèle, mot de passe) aux méthodes biométriques (empreinte digitale, face ID, scan d'iris) en passant par des méthodes moins conventionnelles telles que le déverrouillage de l'appareil dans un lieu (considéré comme) sécurisé par exemple.
L'authentification dépend généralement du software et du hardware bien qu'il existe des cas ou tout passe par le software. Il est possible de vérifier cela à l'aide d'un appel d'API que Android fournis dans son framework.
Les développeurs peuvent cependant ignorer l'authentification de l'utilisateur fournie par la plate-forme et basée sur le matériel ou effectuer leur propre contrôle d'authentification côté client personnalisé dans la couche logicielle, dégradant au passage les performances de sécurité.
Les appareils récents isolent les composants de la plate-forme dans la couche matérielle pour éviter qu'un noyau compromis puisse obtenir le contrôle total du matériel.
Ils utilisent notamment:
Une puce TPM (Trusted Platform Module): ll s'agit d'un standard cryptographique pour microporcesseur.
Un TEE (Trusted Execution Environment): zone sécurisée d'un processeur principal. Il garantit que le code et les données chargés à l'intérieur sont protégés en matière de confidentialité et d'intégrité .
Des TRSM (Tamper-Resistant Security Module): Un module de sécurité inviolable est un dispositif qui intègre des protections physiques pour empêcher la compromission des paramètres de sécurité cryptographiques qu'il contient.
Android utilise ce qu'ils appellent le Verified Boot afin de vérifier que l'ensemble des données chargées lors du démarrage de l'appareil proviennent d'une source sécurisée.
Les APK sont comme des fichiers ZIP qui contiennent tout ce dont une application Android a besoin pour fonctionner : le code de l'application, le fichier manifeste de l'application et les ressources de l'application. Cette section décrit les principaux composants d'un APK Android.
Tout d'abord, le fichier AndroidManifest.xml contient le package de l'application nom, version, composants, droits d'accès et bibliothèques référencées, ainsi que d'autres métadonnées. C'est un bon point de départ pour explorer l'application. À partir de ce fichier, vous pouvez obtenir des informations sur les composants de l'application et autorisations.
Comprendre les composants de votre application cible peut vous fournir un bon aperçu de son fonctionnement. Il existe quatre types d'applications composants : Activités (déclarées dans les balises <activity>), Services (déclarés dans les balises <service>), BroadcastReceivers (déclarés dans les balises <receiver>) et ContentProviders (déclarés dans les balises <provider>).
Les activités sont des composants d'application qui interagissent avec l'utilisateur. Le Les fenêtres des applications Android que vous voyez sont composées d'activités.
Les services sont des opérations de longue durée qui n'interagissent pas directement avec l'utilisateur, telles que que la récupération ou l'envoi de données en arrière-plan.
Les récepteurs de diffusion permettent a une application de répondre aux messages de broadcast du système Android et d'autres applications.
Les fournisseurs de contenu offrent un moyen de partager des données avec d'autres applications.
Les autorisations utilisées par l'application, telles que la possibilité d'envoyer les messages texte et les autorisations dont les autres applications ont besoin pour interagir avec, sont également déclaré dans le fichier AndroidManifest.xml.
Le fichier classes.dex contient le code source de l'application compilé dans le Format de fichier DEX.
Le fichier resources.arsc contient les ressources précompilées de l'application, tels que les chaînes de caractères, les couleurs et les styles. Le dossier res contient les ressources non compilées dans resources.arsc. Dans le dossier res, le fichier res/values/strings.xml contient des chaînes littérales de l'application.
Le dossier lib contient du code compilé qui dépend de la plate-forme. Chaque sous-répertoire de lib contient le code source spécifique utilisé pour une architecture mobile. Les modules de noyau compilés se trouvent ici et sont souvent une source de vulnérabilités.
Le dossier assets contient les assets de l'application, tels que la vidéo, l'audio et modèles de documents. Enfin, le dossier META-INF contient le fichier MANIFEST.MF, qui stocke les métadonnées sur l'application. Ce dossier contient également les certificat et signature de l'APK.
Une activité est tout simplement l'écran qui est affiché à l'utilisateur lorsqu'il utilise l'application. Une application posséde généralement plusieurs activitées (dont une principale un peu comme une classe "main()") et peut êgalement être amené à utiliser des activités d'autres applications.
Les vues représente l'interface de l'application, ou plus généralement les différents composants qui composent l'application (boutons, champs de saisie, listes...).
Les services sont des composant qui ne sont pas visibles par l'utilisateur, c'est eux qui s'occupent du fonctionnement de l'application en arrière-plan.
Les intents permettent d'établir des liens entre des applications (normalement isolées dans des sandboxes) afin de lancer des services, des activitées etc.
Les broadcast reveivers sont des "listeners d'intents". Ils démarrent des applications afin de repondre aux intents reçu.
Les content providers à la façon des intents permettent de communiquer avec d'autres applications ou des bases de données dans le cadre d'échange de données.
apktool est un outil permettant de pratiquer du reverse engeneering sur les fichiers apk.
Medusa est un excellent framework d'analyse statique et dynamique d'applications mobiles basé sur la structure de Metasploit (système de modules, fonctionnement et commandes semblables).
ASThook est un framework français d'analyse statique et dynamique d'applications Android. Il comtient des fonctionnalités de scans de code interéssantes et fournis une assistance utile aux auditeurs en proposant des PoC basés sur ces trouvailles.
Exemple d'utilisation:
$ asthook example.apk --tree --basic_vulns
Quark est un scanner de vulnérabilités ciblant les fichiers apk et java pour Android.
Exemples d'utilisation:
$ quark --apk path/to/exemple.apk
$ quark --java path/to/exemple.java
Décompilateur dex vers java
Dex2jar est un outil permettant de convertir des fichiers .apk en .jar (lisibles).
Exemple d'utilisation:
$ sh d2j-dex2jar.sh -f /path/to/apk_to_decompile.apk
JD-GUI est un utilitaire graphique autonome qui affiche les codes source Java des fichiers ".class". Vous pouvez parcourir le code source reconstruit avec le JD-GUI pour un accès instantané aux méthodes et aux champs.
Apkx a le même usage que dex2jar.
Exemple d'utilisation:
$ apkx path/to/apk_to_decompile.apk
Drozer est un framework de tests de sécurité pour Android.
DroidBox est développé pour offrir une analyse dynamique des applications Android.
Hooker est un projet open source pour les analyses dynamiques des applications Android. Ce projet fournit divers outils et applications qui peuvent être utilisés pour intercepter et modifier automatiquement tout appel d'API effectué par une application ciblée.
MARA est un framework de rétro-ingénierie et d'analyse d'applications mobiles. Il s'agit d'une boîte à outils qui rassemble des outils d'ingénierie inverse et d'analyse d'applications mobiles couramment utilisés pour aider à tester les applications mobiles contre les menaces de sécurité mobile OWASP.
Inspeckage est un outil dédié à l'analyse dynamique et avec des fonctionnalités interessantes telles que l'inspection en temps réel des hooks (Serialization, SQLite, WebView, IPC...)
IDA est un outil d'analyse de code binaire qui est disponible sous deux versions, IDA Pro (payant) et IDA Freeware (gratuit).
APKEditor est un utilitaire interessant en tant qu'auditeur notamment pour gérer les applications multi apk, elle permet notamment de merge un ensemble d'apk en un seul afin d'éviter les problèmes d'installation sur un appareil suite à l'extraction depuis un autre appareil.
Exemple d'utilisation:
$ java -jar APKEditor.jar m -i path/to/apkdirectory
ressource:
ressource:
ressource:
ressource:
ressource:
ressource:
ressource:
ressource:
ressource:
ressource:
ressource:
ressource:
ressource:
ressource:
ressource:
ressource:
