* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
Les primes HackenProof ne sont lancées que lorsque leurs clients déposent le budget de récompense. Vous recevrez la récompense après la vérification du bug.
Il est fortement recommandé de commencer par lire cette page pour connaître les **parties les plus importantes liées à la sécurité Android et les composants les plus dangereux d'une application Android** :
C'est l'outil principal dont vous avez besoin pour vous connecter à un appareil Android (émulé ou physique).\
Il vous permet de contrôler votre appareil via **USB** ou **Réseau** depuis un ordinateur, de **copier** des fichiers aller-retour, d'**installer** et de désinstaller des applications, d'exécuter des commandes **shell**, d'effectuer des **sauvegardes**, de lire des **logs** et plus encore.
Parfois, il est intéressant de **modifier le code de l'application** pour accéder à des **informations cachées** (peut-être des mots de passe bien obfusqués ou des indicateurs). Ensuite, il peut être intéressant de décompiler l'APK, de modifier le code et de le recompiler.\
[**Dans ce tutoriel** vous pouvez **apprendre comment décompiler un APK, modifier le code Smali et recompiler l'APK** avec la nouvelle fonctionnalité](smali-changes.md). Cela peut être très utile comme **alternative pour plusieurs tests lors de l'analyse dynamique** qui vont être présentés. Alors, **gardez toujours cette possibilité à l'esprit**.
Les primes HackenProof ne sont lancées que lorsque leurs clients déposent le budget de récompense. Vous recevrez la récompense après la vérification du bug.
En jetant simplement un coup d'œil aux **chaînes de caractères** de l'APK, vous pouvez rechercher des **mots de passe**, des **URL** ([https://github.com/ndelphit/apkurlgrep](https://github.com/ndelphit/apkurlgrep)), des **clés API**, du **chiffrement**, des **UUID Bluetooth**, des **jetons** et tout ce qui est intéressant... recherchez même des **backdoors** d'exécution de code ou des backdoors d'authentification (identifiants administrateur codés en dur dans l'application).
Portez une attention particulière aux **URL Firebase** et vérifiez si elles sont mal configurées. [Plus d'informations sur ce qu'est Firebase et comment l'exploiter ici.](../../network-services-pentesting/pentesting-web/buckets/firebase-database.md)
En utilisant l'un des **décompilateurs** mentionnés [**ici**](apk-decompilers.md), vous pourrez lire le _Manifest.xml_. Vous pouvez également **renommer** le fichier APK avec l'extension **.zip** et le **décompresser**.\
* Tout d'abord, vérifiez si **l'application peut être déboguée**. Un APK de production ne devrait pas l'être (sinon d'autres pourront s'y connecter). Vous pouvez vérifier si une application peut être déboguée en recherchant dans le manifeste l'attribut `debuggable="true"` à l'intérieur de la balise _\<application_ Exemple : `<application theme="@2131296387" debuggable="true"`
* [Apprenez ici](drozer-tutorial/#is-debuggeable) comment trouver des applications déboguables sur un téléphone et les exploiter
* **Sauvegarde** : L'attribut **`android:allowBackup`** définit si les données de l'application peuvent être sauvegardées et restaurées par un utilisateur ayant activé le débogage USB. Si le drapeau de sauvegarde est défini sur true, cela permet à un attaquant de sauvegarder les données de l'application via adb même si l'appareil n'est pas rooté. Par conséquent, les applications qui gèrent et stockent des informations sensibles telles que les détails de carte, les mots de passe, etc. doivent avoir ce paramètre explicitement défini sur **false**, car par défaut il est défini sur **true** pour éviter de tels risques.
*`<application android:allowBackup="false"`
* **NetworkSecurity** : La sécurité réseau de l'application peut remplacer les valeurs par défaut avec **`android:networkSecurityConfig="@xml/network_security_config"`**. Un fichier portant ce nom peut être placé dans _**res/xml.**_ Ce fichier configurera des paramètres de sécurité importants tels que les épingles de certificat ou s'il autorise le trafic HTTP. Vous pouvez lire ici plus d'informations sur toutes les choses qui peuvent être configurées, mais vérifiez cet exemple sur la configuration du trafic HTTP pour certains domaines :
* **Activités exportées** : Vérifiez les activités exportées dans le manifeste car cela peut être dangereux. Plus tard, lors de l'analyse dynamique, il sera expliqué comment [vous pouvez exploiter ce comportement](./#exploiting-exported-activities-authorisation-bypass).
* **Fournisseurs de contenu** : Si un fournisseur exporté est exposé, vous pourriez avoir accès/modifier des informations intéressantes. Dans l'analyse dynamique, [vous apprendrez comment les exploiter](./#exploiting-content-providers-accessing-and-manipulating-sensitive-information).
* Vérifiez les configurations des **FileProviders** dans l'attribut `android:name="android.support.FILE_PROVIDER_PATHS"`. [Lisez ici pour en savoir plus sur les FileProviders](./#fileprovider).
* **Services exposés** : Selon ce que le service fait en interne, des vulnérabilités pourraient être exploitées. Dans l'analyse dynamique, [vous apprendrez comment les exploiter](./#exploiting-services).
* **Receveurs de diffusion** : [Vous apprendrez comment les exploiter éventuellement](./#exploiting-broadcast-receivers) lors de l'analyse dynamique.
* **Schéma d'URL** : Lisez le code de l'activité gérant le schéma et recherchez des vulnérabilités dans la gestion de l'entrée de l'utilisateur. Plus d'informations sur [ce qu'est un schéma d'URL ici](./#url-schemes).
* **minSdkVersion**, **targetSDKVersion**, **maxSdkVersion** : Ils indiquent les versions d'Android sur lesquelles l'application fonctionnera. Il est important de les garder à l'esprit car du point de vue de la sécurité, le fait de prendre en charge d'anciennes versions permettra à des versions vulnérables d'Android connues de l'exécuter.
Le **Tapjacking** est une attaque où une **application malveillante** est lancée et **se positionne au-dessus d'une application victime**. Une fois qu'elle obscurcit visiblement l'application victime, son interface utilisateur est conçue de manière à tromper l'utilisateur pour qu'il interagisse avec elle, tout en transmettant l'interaction à l'application victime.\
Pour détecter les applications vulnérables à cette attaque, vous devriez rechercher des **activités exportées** dans le manifeste Android (notez qu'une activité avec un intent-filter est automatiquement exportée par défaut). Une fois que vous avez trouvé les activités exportées, **vérifiez si elles nécessitent des autorisations**. Cela est dû au fait que la **application malveillante aura également besoin de cette autorisation**.\
Enfin, il est important de vérifier le code pour d'éventuelles configurations de **`setFilterTouchesWhenObscured`**. Si elle est définie sur **`true`**, un bouton peut être automatiquement désactivé s'il est obscurci :
Vous pouvez utiliser [**qark**](https://github.com/linkedin/qark) avec le paramètre `--exploit-apk` pour créer une application malveillante afin de tester les vulnérabilités potentielles de **Tapjacking**.\
Un projet d'exemple implémentant ce type de fonctionnalité peut être trouvé dans [**FloatingWindowApp**](https://github.com/aminography/FloatingWindowApp).
La mitigation est relativement simple car le développeur peut choisir de ne pas recevoir les événements tactiles lorsqu'une vue est recouverte par une autre. Utilisez la [Référence du développeur Android](https://developer.android.com/reference/android/view/View#security):
> Parfois, il est essentiel qu'une application puisse vérifier qu'une action est effectuée avec la pleine connaissance et le consentement de l'utilisateur, comme accorder une demande d'autorisation, effectuer un achat ou cliquer sur une publicité. Malheureusement, une application malveillante pourrait essayer de tromper l'utilisateur en lui faisant effectuer ces actions, sans le savoir, en dissimulant l'objectif réel de la vue. Pour remédier à cela, le framework propose un mécanisme de filtrage tactile qui peut être utilisé pour améliorer la sécurité des vues qui fournissent un accès à des fonctionnalités sensibles.
> Pour activer le filtrage tactile, appelez [`setFilterTouchesWhenObscured(boolean)`](https://developer.android.com/reference/android/view/View#setFilterTouchesWhenObscured%28boolean%29) ou définissez l'attribut de mise en page android:filterTouchesWhenObscured sur true. Lorsqu'il est activé, le framework ignorera les touches reçues chaque fois que la fenêtre de la vue est masquée par une autre fenêtre visible. Par conséquent, la vue ne recevra pas de touches chaque fois qu'un toast, une boîte de dialogue ou une autre fenêtre apparaîtra au-dessus de la fenêtre de la vue.
Les fichiers **créés** sur le **stockage interne** sont **accessibles** uniquement par l'**application**. Cette protection est implémentée par Android et est suffisante pour la plupart des applications. Cependant, les développeurs utilisent souvent `MODE_WORLD_READBALE` et `MODE_WORLD_WRITABLE` pour donner accès à ces fichiers à une autre application, mais cela ne limite pas les autres applications (malveillantes) à y accéder.\
Lors de l'**analyse statique**, vérifiez l'utilisation de ces **modes**, lors de l'**analyse dynamique**, vérifiez les **permissions** des fichiers créés (certains d'entre eux peuvent être lisibles/inscriptibles dans le monde entier).\
Les fichiers créés sur le **stockage externe**, tels que les cartes SD, sont **lisibles et inscriptibles globalement**. Étant donné que le stockage externe peut être retiré par l'utilisateur et également modifié par n'importe quelle application, vous ne devez **pas stocker d'informations sensibles à l'aide du stockage externe**.\
Comme pour les données provenant de toute source non fiable, vous devez **effectuer une validation des entrées** lors de la manipulation de **données provenant du stockage externe**. Nous vous recommandons vivement de ne pas stocker d'exécutables ou de fichiers de classe sur le stockage externe avant le chargement dynamique. Si votre application récupère des fichiers exécutables à partir du stockage externe, les fichiers doivent être signés et vérifiés cryptographiquement avant le chargement dynamique.\
À partir d'Android 4.4 (**API 17**), la carte SD dispose d'une structure de répertoire qui **limite l'accès d'une application au répertoire spécifique à cette application**. Cela empêche une application malveillante d'accéder en lecture ou en écriture aux fichiers d'une autre application.
* **Préférences partagées** : Android permet à chaque application de sauvegarder facilement des fichiers XML dans le chemin `/data/data/<nomdupackage>/shared_prefs/` et il est parfois possible de trouver des informations sensibles en clair dans ce dossier.
* **Bases de données** : Android permet à chaque application de sauvegarder facilement des bases de données SQLite dans le chemin `/data/data/<nomdupackage>/databases/` et il est parfois possible de trouver des informations sensibles en clair dans ce dossier.
Pour une raison quelconque, parfois les développeurs acceptent tous les certificats, même si, par exemple, le nom d'hôte ne correspond pas avec des lignes de code comme celle-ci :
Une bonne façon de tester cela est d'essayer de capturer le trafic en utilisant un proxy comme Burp sans autoriser Burp CA à l'intérieur de l'appareil. Vous pouvez également générer avec Burp un certificat pour un nom d'hôte différent et l'utiliser.
Certains développeurs enregistrent des données sensibles dans le stockage local et les chiffrent avec une clé codée en dur/prévisible dans le code. Cela ne devrait pas être fait car une rétro-ingénierie pourrait permettre aux attaquants d'extraire les informations confidentielles.
Les développeurs ne devraient pas utiliser des algorithmes **obsolètes** pour effectuer des **vérifications** d'autorisation, **stocker** ou **envoyer** des données. Certains de ces algorithmes sont : RC4, MD4, MD5, SHA1... Si des **hachages** sont utilisés pour stocker des mots de passe par exemple, des hachages résistants à la force brute devraient être utilisés avec un sel.
* Il est recommandé d'**obfusquer l'APK** pour rendre plus difficile le travail de rétro-ingénierie des attaquants.
* Si l'application est sensible (comme les applications bancaires), elle devrait effectuer ses **propres vérifications pour voir si le mobile est rooté** et agir en conséquence.
* Si l'application est sensible (comme les applications bancaires), elle devrait vérifier si un **émulateur** est utilisé.
* Si l'application est sensible (comme les applications bancaires), elle devrait **vérifier son intégrité avant de l'exécuter** pour vérifier si elle a été modifiée.
* Utilisez [**APKiD**](https://github.com/rednaga/APKiD) pour vérifier quel compilateur/packer/obfuscateur a été utilisé pour construire l'APK.
Selon ce [**billet de blog**](https://clearbluejar.github.io/posts/desuperpacking-meta-superpacked-apks-with-github-actions/), Superpacked est un méta-algorithme qui compresse le contenu d'une application dans un seul fichier. Le blog parle de la possibilité de créer une application qui décompresse ce type d'applications... et d'une façon plus rapide qui consiste à **exécuter l'application et à récupérer les fichiers décompressés du système de fichiers**.
L'outil [**mariana-trench**](https://github.com/facebook/mariana-trench) est capable de trouver des **vulnérabilités** en **analysant** le **code** de l'application. Cet outil contient une série de **sources connues** (qui indiquent à l'outil les **endroits** où l'**entrée** est **contrôlée par l'utilisateur**), des **sinks** (qui indiquent à l'outil les **endroits dangereux** où une entrée utilisateur malveillante pourrait causer des dommages) et des **règles**. Ces règles indiquent la **combinaison** de **sources-sinks** qui indique une vulnérabilité.
Une application peut contenir des secrets (clés API, mots de passe, URL cachées, sous-domaines...) à l'intérieur que vous pourriez être en mesure de découvrir. Vous pouvez utiliser un outil tel que [https://github.com/dwisiswant0/apkleaks](https://github.com/dwisiswant0/apkleaks)
Les primes HackenProof ne sont lancées que lorsque leurs clients déposent le budget de récompense. Vous recevrez la récompense après la vérification du bogue.
> Tout d'abord, vous avez besoin d'un environnement où vous pouvez installer l'application et tout l'environnement (certificat Burp CA, Drozer et Frida principalement). Par conséquent, un appareil rooté (émulé ou non) est extrêmement recommandé.
Vous pouvez créer un **compte gratuit** sur : [https://appetize.io/](https://appetize.io). Cette plateforme vous permet de **télécharger** et **exécuter** des APK, il est donc utile de voir comment un APK se comporte.
* [**Android Studio**](https://developer.android.com/studio) (Vous pouvez créer des appareils **x86** et **arm**, et selon [**ceci** ](https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html), les **dernières versions x86****supportent les bibliothèques ARM** sans avoir besoin d'un émulateur ARM lent).
* Si vous voulez essayer d'**installer** une **image** puis vous voulez la **supprimer**, vous pouvez le faire sur Windows : `C:\Users\<User>\AppData\Local\Android\sdk\system-images\` ou Mac : `/Users/myeongsic/Library/Android/sdk/system-image`
* C'est l'**émulateur principal que je recommande d'utiliser et vous pouvez**[ **apprendre à le configurer sur cette page**](avd-android-virtual-device.md).
* [**Genymotion**](https://www.genymotion.com/fun-zone/) **(Version gratuite :** Personal Edition, vous devez créer un compte. _Il est recommandé de **télécharger** la version **AVEC**__**VirtualBox** pour éviter les erreurs potentielles._)
Lors de la création d'un nouvel émulateur sur n'importe quelle plateforme, rappelez-vous que plus l'écran est grand, plus l'émulateur sera lent. Choisissez donc de petits écrans si possible.
Comme la plupart des gens utiliseront **Genymotion**, notez cette astuce. Pour **installer les services Google** (comme AppStore), vous devez cliquer sur le bouton marqué en rouge sur l'image suivante :
Remarquez également que dans la **configuration de la machine virtuelle Android dans Genymotion**, vous pouvez sélectionner le mode **Bridge Network** (ce sera utile si vous vous connectez à la machine virtuelle Android à partir d'une autre machine virtuelle avec les outils).
> Une fois que vous avez installé l'application, la première chose que vous devriez faire est de l'essayer et d'enquêter sur ce qu'elle fait, comment elle fonctionne et de vous familiariser avec elle.\
> Je vous suggère de **réaliser cette analyse dynamique initiale en utilisant l'analyse dynamique MobSF + pidcat**, ainsi vous pourrez **apprendre comment l'application fonctionne** tandis que MobSF **capture** beaucoup de **données intéressantes** que vous pourrez examiner ultérieurement.
Souvent, les développeurs laissent des informations de débogage accessibles au public. Ainsi, toute application disposant de l'autorisation `READ_LOGS` peut **accéder à ces journaux** et obtenir des informations sensibles.\
Lors de la navigation dans l'application, utilisez [**pidcat**](https://github.com/JakeWharton/pidcat)_(Recommandé, il est plus facile à utiliser et à lire)_ ou [adb logcat](adb-commands.md#logcat) pour lire les journaux créés et **rechercher des informations sensibles**.
Notez que **à partir des versions ultérieures à Android 4.0**, **les applications ne peuvent accéder qu'à leurs propres journaux**. Les applications ne peuvent donc pas accéder aux journaux d'autres applications.\
Android fournit un framework basé sur le presse-papiers pour fournir la fonction de copier-coller dans les applications Android. Mais cela crée un problème sérieux lorsque certaines **autres applications** peuvent **accéder** au **presse-papiers** qui contient des données sensibles. La fonction de **copier-coller** devrait être **désactivée** pour les parties **sensibles** de l'application. Par exemple, désactivez la copie des détails de la carte de crédit.
Si une application **plante** pendant son exécution et qu'elle **enregistre des journaux** quelque part, ces journaux peuvent être utiles à un attaquant, surtout dans les cas où l'application Android ne peut pas être rétro-ingénierée. Dans ce cas, évitez de créer des journaux lorsque l'application plante et si les journaux sont envoyés via le réseau, assurez-vous qu'ils sont envoyés via un canal SSL.\
La plupart des applications utilisent d'autres services dans leur application, comme Google Adsense, mais parfois elles **laissent fuir des données sensibles** ou des données qui ne sont pas nécessaires à envoyer à ce service. Cela peut se produire parce que le développeur n'a pas correctement implémenté la fonctionnalité. Vous pouvez **vérifier en interceptant le trafic** de l'application et voir si des données sensibles sont envoyées à des tiers ou non.
La plupart des applications utiliseront des **bases de données SQLite internes** pour enregistrer des informations. Lors du pentest, jetez un **coup d'œil** aux **bases de données** créées, aux noms des **tables** et des **colonnes** et à toutes les **données** enregistrées, car vous pourriez trouver des **informations sensibles** (ce qui serait une vulnérabilité).\
Si la base de données enregistre des informations confidentielles et est **chiffrée**, mais que vous pouvez **trouver** le **mot de passe** à l'intérieur de l'application, c'est toujours une **vulnérabilité**.
**Drozer** vous permet de **prendre le rôle d'une application Android** et d'interagir avec d'autres applications. Il peut faire **tout ce qu'une application installée peut faire**, comme utiliser le mécanisme de communication inter-processus (IPC) d'Android et interagir avec le système d'exploitation sous-jacent. À partir du [Guide Drozer](https://labs.mwrinfosecurity.com/assets/BlogFiles/mwri-drozer-user-guide-2015-03-23.pdf).\
Drozer est un outil utile pour **exploiter les activités exportées, les services exportés et les fournisseurs de contenu**, comme vous le verrez dans les sections suivantes.
### Exploiter les activités exportées
[**Lisez ceci si vous voulez vous rappeler ce qu'est une activité Android.**](android-applications-basics.md#launcher-activity-and-other-activities)\
Rappelez-vous également que le code d'une activité commence par la méthode `onCreate`.
Lorsqu'une activité est exportée, vous pouvez invoquer son écran depuis une application externe. Par conséquent, si une activité contenant des **informations sensibles** est **exportée**, vous pourriez **contourner** les **mécanismes d'authentification** pour y accéder.\
**NOTE**: MobSF détectera comme malveillante l'utilisation de _**singleTask/singleInstance**_ en tant que `android:launchMode` dans une activité, mais en raison de [ceci](https://github.com/MobSF/Mobile-Security-Framework-MobSF/pull/750), cela semble seulement dangereux sur les anciennes versions (versions d'API <21).
Notez qu'une contournement d'autorisation n'est pas toujours une vulnérabilité, cela dépend de la façon dont le contournement fonctionne et des informations qui sont exposées.
**Les activités peuvent également renvoyer des résultats**. Si vous parvenez à trouver une activité exportée et non protégée appelant la méthode **`setResult`** et **renvoyant des informations sensibles**, il y a une fuite d'informations sensibles.
[**Lisez ceci si vous voulez vous rappeler ce qu'est un fournisseur de contenu.**](android-applications-basics.md#content-provider)\
Les fournisseurs de contenu sont essentiellement utilisés pour **partager des données**. Si une application dispose de fournisseurs de contenu disponibles, vous pourrez peut-être **extraire des données sensibles** à partir d'eux. Il est également intéressant de tester les **injections SQL** et les **traversées de chemin** possibles, car elles pourraient être vulnérables.\
Un service est essentiellement quelque chose qui **peut recevoir des données**, les **traiter** et **renvoyer** (ou non) une réponse. Donc, si une application exporte certains services, vous devriez **vérifier** le **code** pour comprendre ce qu'il fait et le **tester****dynamiquement** pour extraire des informations confidentielles, contourner les mesures d'authentification...\
Vous pouvez rechercher des liens profonds manuellement, en utilisant des outils comme MobSF ou des scripts comme [celui-ci](https://github.com/ashleykinguk/FBLinkBuilder/blob/master/FBLinkBuilder.py).\
Vous pouvez **ouvrir** un **schéma** déclaré en utilisant **adb** ou un **navigateur** :
Pour trouver le **code qui sera exécuté dans l'application**, allez dans l'activité appelée par le lien profond et recherchez la fonction **`onNewIntent`**.
Chaque fois que vous trouvez un lien profond, vérifiez qu'il ne reçoit pas de données sensibles (comme des mots de passe) via les paramètres de l'URL, car toute autre application pourrait **usurper le lien profond et voler ces données !**
Vous devez également vérifier si un lien profond utilise un paramètre dans le chemin de l'URL, par exemple : `https://api.example.com/v1/users/{username}`, dans ce cas, vous pouvez forcer une traversée de chemin en accédant à quelque chose comme : `example://app/users?username=../../unwanted-endpoint%3fparam=value`.\
Notez que si vous trouvez les points d'extrémité corrects dans l'application, vous pourriez être en mesure de provoquer une **redirection ouverte** (si une partie du chemin est utilisée comme nom de domaine), une **prise de contrôle de compte** (si vous pouvez modifier les détails des utilisateurs sans jeton CSRF et que le point d'extrémité vulnérable utilise la méthode correcte) et toute autre vulnérabilité. Plus d'informations à ce sujet [ici](http://dphoeniixx.com/2020/12/13-2/).
* **Absence d'inspection de certificat :** L'application Android ne parvient pas à vérifier l'identité du certificat qui lui est présenté. La plupart des applications ignorent les avertissements et acceptent n'importe quel certificat auto-signé présenté. Certaines applications passent plutôt le trafic par une connexion HTTP.
* **Négociation de poignée de main faible :** L'application et le serveur effectuent une poignée de main SSL/TLS, mais utilisent une suite de chiffrement non sécurisée qui est vulnérable aux attaques de l'homme du milieu (MITM). Ainsi, tout attaquant peut facilement décrypter cette connexion.
* **Fuite d'informations de confidentialité :** La plupart du temps, il arrive que les applications effectuent une authentification via un canal sécurisé, mais que toutes les autres connexions se fassent via un canal non sécurisé. Cela n'ajoute rien à la sécurité de l'application, car les données sensibles restantes, telles que les cookies de session ou les données utilisateur, peuvent être interceptées par un utilisateur malveillant.
Parmi les 3 scénarios présentés, nous allons discuter de **comment vérifier l'identité du certificat**. Les 2 autres scénarios dépendent de la **configuration TLS** du serveur et de l'envoi ou non de données non chiffrées par l'application. Le testeur de pénétration doit vérifier par lui-même la configuration TLS du serveur ([ici](../../network-services-pentesting/pentesting-web/#ssl-tls-vulnerabilites)) et détecter si des **informations confidentielles sont envoyées par un canal non chiffré/vulnérable**.\
Plus d'informations sur la découverte et la correction de ce type de vulnérabilités [**ici**](https://manifestsecurity.com/android-application-security-part-10/).
Par défaut, lors de l'établissement d'une connexion SSL, le client (application Android) vérifie que le certificat du serveur a une chaîne de confiance vérifiable remontant à un certificat de confiance (racine) et correspond au nom d'hôte demandé. Cela pose un problème d'**attaques de l'homme du milieu (MITM)**.\
Dans l'épinglage de certificat, une application Android contient elle-même le certificat du serveur et ne transmet les données que si le même certificat est présenté.\
Tout d'abord, vous devez (devez) **installer le certificat** de l'**outil proxy** que vous allez utiliser, probablement Burp. Si vous n'installez pas le certificat CA de l'outil proxy, vous ne verrez probablement pas le trafic chiffré dans le proxy.\
Pour les applications ciblant **API Level 24+**, il ne suffit pas d'installer le certificat CA de Burp sur l'appareil. Pour contourner cette nouvelle protection, vous devez modifier le fichier de configuration de la sécurité réseau. Ainsi, vous pouvez modifier ce fichier pour autoriser votre certificat CA ou vous pouvez [**lire cette page pour un tutoriel sur la façon de forcer l'application à accepter à nouveau tous les certificats installés sur l'appareil**](make-apk-accept-ca-certificate.md).
Nous avons déjà discuté de ce qu'est l'épinglage SSL juste 2 paragraphes plus haut. Lorsqu'il est implémenté dans une application, vous devrez le contourner pour inspecter le trafic HTTPS ou vous ne le verrez pas.\
Voici quelques options que j'ai utilisées pour contourner cette protection :
* Modifier automatiquement l'**apk** pour contourner l'épinglage SSL avec [**apk-mitm**](https://github.com/shroudedcode/apk-mitm). Le meilleur avantage de cette option est que vous n'avez pas besoin de root pour contourner l'épinglage SSL, mais vous devrez supprimer l'application et réinstaller la nouvelle, et cela ne fonctionnera pas toujours.
* Vous pouvez utiliser **Frida** (discuté ci-dessous) pour contourner cette protection. Voici un guide pour utiliser Burp+Frida+Genymotion : [https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/](https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/)
* Vous pouvez également essayer de contourner automatiquement l'épinglage SSL en utilisant [**objection**](frida-tutorial/objection-tutorial.md)**:** `objection --gadget com.package.app explore --startup-command "android sslpinning disable"`
* Vous pouvez également essayer de contourner automatiquement l'épinglage SSL en utilisant l'analyse dynamique de **MobSF** (expliquée ci-dessous)
* Si vous pensez toujours qu'il y a du trafic que vous ne capturez pas, vous pouvez essayer de **rediriger le trafic vers Burp en utilisant iptables**. Lisez ce blog : [https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62](https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62)
**Vulnérabilités Web courantes**
Notez qu'à cette étape, vous devez rechercher des vulnérabilités Web courantes. Beaucoup d'informations sur les vulnérabilités Web peuvent être trouvées dans ce livre, donc je ne vais pas les mentionner ici.
### Frida
Boîte à outils d'instrumentation dynamique pour les développeurs, les reverse-engineers et les chercheurs en sécurité. En savoir plus sur [www.frida.re](https://www.frida.re).\
**C'est incroyable, vous pouvez accéder à une application en cours d'exécution et accrocher des méthodes en temps réel pour changer le comportement, changer les valeurs, extraire des valeurs, exécuter un code différent...**\
**Apprenez à utiliser Frida :** [**Tutoriel Frida**](frida-tutorial/)\
**Quelques "GUI" pour les actions avec Frida :** [**https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security**](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security)\
**Quelques autres abstractions basées sur Frida :** [**https://github.com/sensepost/objection**](https://github.com/sensepost/objection) **,** [**https://github.com/dpnishant/appmon**](https://github.com/dpnishant/appmon)\
**Vous pouvez trouver quelques scripts Frida impressionnants ici :** [**https://codeshare.frida.re/**](https://codeshare.frida.re)
### **Analyseur d'application Android**
Cet outil peut vous aider à gérer différents outils lors de l'analyse dynamique : [https://github.com/NotSoSecure/android\_application\_analyzer](https://github.com/NotSoSecure/android\_application\_analyzer)
### Injection d'intention
Cette vulnérabilité ressemble à **Open Redirect dans la sécurité web**. Étant donné que la classe `Intent` est `Parcelable`, **les objets appartenant à cette classe** peuvent être **transmis** en tant que **données supplémentaires** dans un autre objet `Intent`.\
De nombreux développeurs utilisent cette **fonctionnalité** et créent des **composants proxy** (activités, récepteurs de diffusion et services) qui **prennent une intention intégrée et la transmettent à des méthodes dangereuses** telles que `startActivity(...)`, `sendBroadcast(...)`, etc.\
C'est dangereux car **un attaquant peut forcer l'application à lancer un composant non exporté qui ne peut pas être lancé directement depuis une autre application**, ou à accorder à l'attaquant l'accès à ses fournisseurs de contenu. **`WebView`** change parfois également une **URL d'une chaîne en un objet `Intent`**, en utilisant la méthode `Intent.parseUri(...)`, et la transmet à `startActivity(...)`.
### Injections côté client Android et autres
Vous connaissez probablement ce type de vulnérabilités sur le Web. Vous devez être particulièrement prudent avec ces vulnérabilités dans une application Android :
* **Injection SQL :** Lorsque vous travaillez avec des requêtes dynamiques ou des fournisseurs de contenu, assurez-vous d'utiliser des requêtes paramétrées.
* **Injection JavaScript (XSS) :** Vérifiez que la prise en charge de JavaScript et des plugins est désactivée pour tous les WebViews (désactivée par défaut). [Plus d'informations ici](webview-attacks.md#javascript-enabled).
* **Inclusion de fichiers locaux :** Vérifiez que l'accès au système de fichiers est désactivé pour tous les WebViews (activé par défaut) `(webview.getSettings().setAllowFileAccess(false);)`. [Plus d'informations ici](webview-attacks.md#javascript-enabled).
* **Cookies persistants** : Dans plusieurs cas, lorsque l'application Android termine la session, le cookie n'est pas révoqué ou il peut même être enregistré sur le disque.
* [**Drapeau de sécurité** dans les cookies](../../pentesting-web/hacking-with-cookies/#cookies-flags)
Les primes HackenProof ne sont lancées que lorsque leurs clients déposent le budget de récompense. Vous recevrez la récompense après la vérification du bogue.
**Évaluation des vulnérabilités de l'application** à l'aide d'une interface web conviviale. Vous pouvez également effectuer une analyse dynamique (mais vous devez préparer l'environnement).
Remarquez que MobSF peut analyser les applications **Android** (apk), **IOS** (ipa) et **Windows** (apx) (les applications Windows doivent être analysées à partir d'un MobSF installé sur un hôte Windows).\
De plus, si vous créez un fichier **ZIP** avec le code source d'une application **Android** ou **IOS** (allez dans le dossier racine de l'application, sélectionnez tout et créez un fichier ZIP), MobSF pourra également l'analyser.
MobSF vous permet également de **comparer/différer** les analyses et d'intégrer **VirusTotal** (vous devrez définir votre clé API dans _MobSF/settings.py_ et l'activer : `VT_ENABLED = TRUE``VT_API_KEY = <Votre clé API>``VT_UPLOAD = TRUE`). Vous pouvez également définir `VT_UPLOAD` sur `False`, alors le **hash** sera **téléchargé** au lieu du fichier.
MobSF peut également être très utile pour l'**analyse dynamique** sur Android, mais dans ce cas, vous devrez installer MobSF et **genymotion** sur votre hôte (une machine virtuelle ou Docker ne fonctionnera pas). _Remarque : Vous devez **d'abord démarrer une machine virtuelle dans genymotion** et **ensuite MobSF.**_\
* **Extraire les données de l'application** (URL, journaux, presse-papiers, captures d'écran réalisées par vous, captures d'écran réalisées par "**Exported Activity Tester**", e-mails, bases de données SQLite, fichiers XML et autres fichiers créés). Tout cela est fait automatiquement, sauf pour les captures d'écran, vous devez appuyer lorsque vous souhaitez une capture d'écran ou vous devez appuyer sur "**Exported Activity Tester**" pour obtenir des captures d'écran de toutes les activités exportées.
À partir des versions d'Android supérieures à 5, il démarrera automatiquement Frida et définira les paramètres **proxy** globaux pour capturer le trafic. Il ne capturera le trafic que de l'application testée.
Par défaut, il utilisera également certains scripts Frida pour **contourner la vérification de l'authenticité SSL**, la **détection de root** et la **détection de débogueur**, ainsi que pour **surveiller les API intéressantes**.\
Pour **démarrer** le test dynamique, appuyez sur le bouton vert : "**Start Instrumentation**". Appuyez sur "**Frida Live Logs**" pour voir les journaux générés par les scripts Frida et sur "**Live API Monitor**" pour voir toutes les invocations des méthodes accrochées, les arguments passés et les valeurs retournées (cela apparaîtra après avoir appuyé sur "Start Instrumentation").\
MobSF vous permet également de charger vos propres **scripts Frida** (pour envoyer les résultats de vos scripts Frida à MobSF, utilisez la fonction `send()`). Il dispose également de **plusieurs scripts pré-écrits** que vous pouvez charger (vous pouvez en ajouter d'autres dans `MobSF/DynamicAnalyzer/tools/frida_scripts/others/`), il vous suffit de les **sélectionner**, d'appuyer sur "**Load**" et d'appuyer sur "**Start Instrumentation**" (vous pourrez voir les journaux de ces scripts dans "**Frida Live Logs**").
* **Énumérer les classes chargées** : cela affichera toutes les classes chargées
* **Capturer les chaînes de caractères** : cela affichera toutes les chaînes de caractères capturées lors de l'utilisation de l'application (très bruyant)
* **Capturer les comparaisons de chaînes de caractères** : cela pourrait être très utile. Cela affichera les 2 chaînes de caractères comparées et si le résultat était vrai ou faux.
* **Énumérer les méthodes de classe** : indiquez le nom de la classe (comme "java.io.File") et cela affichera toutes les méthodes de la classe.
* **Rechercher un modèle de classe** : recherche de classes par motif
* **Tracer les méthodes de classe** : **tracer** une **classe entière** (voir les entrées et sorties de toutes les méthodes de la classe). N'oubliez pas que par défaut, MobSF trace plusieurs méthodes intéressantes de l'API Android.
Une fois que vous avez sélectionné le module auxiliaire que vous souhaitez utiliser, vous devez appuyer sur "**Start Intrumentation**" et vous verrez toutes les sorties dans "**Frida Live Logs**".
Mobsf vous propose également une interface de commande avec quelques commandes **adb**, des commandes **MobSF** et des commandes **shell** courantes en bas de la page d'analyse dynamique. Quelques commandes intéressantes :
Lorsque le trafic http est capturé, vous pouvez voir une vue peu attrayante du trafic capturé sur le bouton "**HTTP(S) Traffic**" en bas ou une vue plus agréable sur le bouton vert "**Start HTTPTools**". À partir de la deuxième option, vous pouvez **envoyer** les **requêtes capturées** vers des **proxies** tels que Burp ou Owasp ZAP.\
Pour ce faire, _allumez Burp -->__désactivez Intercept --> dans MobSB HTTPTools, sélectionnez la requête_ --> appuyez sur "**Send to Fuzzer**" --> _sélectionnez l'adresse du proxy_ ([http://127.0.0.1:8080\\](http://127.0.0.1:8080)).
Une fois que vous avez terminé l'analyse dynamique avec MobSF, vous pouvez appuyer sur "**Start Web API Fuzzer**" pour **fuzzer les requêtes http** et rechercher des vulnérabilités.
Après avoir effectué une analyse dynamique avec MobSF, les paramètres du proxy peuvent être mal configurés et vous ne pourrez pas les corriger depuis l'interface graphique. Vous pouvez corriger les paramètres du proxy en effectuant les étapes suivantes :
Cet outil est conçu pour rechercher plusieurs **vulnérabilités de sécurité liées aux applications Android**, que ce soit dans le **code source** ou les **APK empaquetés**. L'outil est également **capable de créer un APK déployable "Proof-of-Concept"** et des **commandes ADB** pour exploiter certaines des vulnérabilités trouvées (activités exposées, intents, tapjacking...). Comme avec Drozer, il n'est pas nécessaire de rooter l'appareil de test.
SUPER est une application en ligne de commande qui peut être utilisée sous Windows, MacOS X et Linux pour analyser les fichiers _.apk_ à la recherche de vulnérabilités. Elle le fait en décompressant les APK et en appliquant une série de règles pour détecter ces vulnérabilités.
Toutes les règles sont regroupées dans un fichier `rules.json`, et chaque entreprise ou testeur peut créer ses propres règles pour analyser ce dont il a besoin.
StaCoAn est un outil **multiplateforme** qui aide les développeurs, les chasseurs de primes et les hackers éthiques à effectuer une [analyse statique du code](https://en.wikipedia.org/wiki/Static\_program\_analysis) sur les applications mobiles\*.
Le concept est que vous faites glisser et déposez votre fichier d'application mobile (un fichier .apk ou .ipa) sur l'application StaCoAn et elle générera un rapport visuel et portable pour vous. Vous pouvez ajuster les paramètres et les listes de mots pour obtenir une expérience personnalisée.
AndroBugs Framework est un système d'analyse de vulnérabilités Android qui aide les développeurs ou les hackers à trouver des vulnérabilités de sécurité potentielles dans les applications Android.\
**Androwarn** est un outil dont le principal objectif est de détecter et avertir l'utilisateur des comportements potentiellement malveillants développés par une application Android.
La détection est effectuée par l'analyse statique du bytecode Dalvik de l'application, représenté sous forme de **Smali**, avec la bibliothèque [`androguard`](https://github.com/androguard/androguard).
Cet outil recherche les comportements courants des applications "mauvaises" tels que : l'exfiltration des identifiants de téléphonie, l'interception des flux audio/vidéo, la modification des données PIM, l'exécution de code arbitraire...
**MARA** est un **F**ramework d'**A**nalyse et de **R**étro-ingénierie d'**A**pplications **M**obiles. C'est un outil qui regroupe des outils couramment utilisés pour la rétro-ingénierie et l'analyse d'applications mobiles, afin d'aider à tester les applications mobiles contre les menaces de sécurité mobiles OWASP. Son objectif est de rendre cette tâche plus facile et plus conviviale pour les développeurs d'applications mobiles et les professionnels de la sécurité.
* Extraire du code Java et Smali à l'aide de différents outils
* Analyser les APK à l'aide de : [smalisca](https://github.com/dorneanu/smalisca), [ClassyShark](https://github.com/google/android-classyshark), [androbugs](https://github.com/AndroBugs/AndroBugs_Framework), [androwarn](https://github.com/maaaaz/androwarn), [APKiD](https://github.com/rednaga/APKiD)
* Extraire des informations privées de l'APK à l'aide d'expressions régulières.
* Analyser les domaines trouvés à l'aide de : [pyssltest](https://github.com/moheshmohan/pyssltest), [testssl](https://github.com/drwetter/testssl.sh) et [whatweb](https://github.com/urbanadventurer/WhatWeb)
Les primes HackenProof ne sont lancées que lorsque leurs clients déposent le budget de récompense. Vous recevrez la récompense après la vérification du bug.
**ProGuard** est un outil en ligne de commande open source qui réduit la taille, optimise et obfusque le code Java. Il est capable d'optimiser le bytecode ainsi que de détecter et supprimer les instructions inutilisées. ProGuard est un logiciel gratuit distribué sous la licence publique générale GNU, version 2.
**DeGuard inverse le processus d'obfuscation effectué par les outils d'obfuscation Android. Cela permet de réaliser de nombreuses analyses de sécurité, notamment l'inspection du code et la prédiction des bibliothèques.**
C'est un **déobfuscateur générique pour Android.** Simplify **exécute virtuellement une application** pour comprendre son comportement, puis **essaie d'optimiser le code** pour qu'il se comporte de manière identique mais soit plus facile à comprendre pour un humain. Chaque type d'optimisation est simple et générique, il n'importe donc pas quel type spécifique d'obfuscation est utilisé.
APKiD vous donne des informations sur **comment un APK a été créé**. Il identifie de nombreux **compilateurs**, **packers**, **obfuscateurs** et autres choses étranges. C'est [_PEiD_](https://www.aldeid.com/wiki/PEiD) pour Android.
AndroL4b est une machine virtuelle de sécurité Android basée sur ubuntu-mate qui comprend la collection des derniers frameworks, tutoriels et laboratoires de différents geeks de la sécurité et chercheurs pour la rétro-ingénierie et l'analyse de logiciels malveillants.
Les primes HackenProof sont lancées uniquement lorsque les clients déposent le budget de récompense. Vous recevrez la récompense après la vérification du bug.
* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
