* 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) !
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) **groupe Discord** 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).
**Chaque application se voit attribuer un ID utilisateur spécifique**. Cela est fait lors de l'installation de l'application afin que l'application ne puisse interagir qu'avec les fichiers appartenant à son ID utilisateur ou les fichiers partagés. Par conséquent, seule l'application elle-même, certains composants du système d'exploitation et l'utilisateur root peuvent accéder aux données des applications.
**Deux applications peuvent être configurées pour utiliser le même UID**. Cela peut être utile pour partager des informations, mais si l'une d'entre elles est compromise, les données des deux applications seront compromises. C'est pourquoi ce comportement est **découragé**.\
**Pour partager le même UID, les applications doivent définir la même valeur `android:sharedUserId` dans leurs manifestes.**
Le **bac à sable de l'application Android** permet d'exécuter **chaque application** en tant que **processus séparé sous un ID utilisateur séparé**. Chaque processus a sa propre machine virtuelle, de sorte que le code d'une application s'exécute de manière isolée des autres applications.\
À partir d'Android 5.0(L), **SELinux** est appliqué. Fondamentalement, SELinux a refusé toutes les interactions de processus, puis a créé des politiques pour **ne permettre que les interactions attendues entre eux**.
Lorsque vous installez une **application et qu'elle demande des autorisations**, l'application demande les autorisations configurées dans les éléments **`uses-permission`** du fichier **AndroidManifest.xml**. L'élément **uses-permission** indique le nom de l'autorisation demandée dans l'**attribut name**. Il a également l'attribut **maxSdkVersion** qui arrête de demander des autorisations sur les versions supérieures à celle spécifiée.\
Notez que les applications Android n'ont pas besoin de demander toutes les autorisations au début, elles peuvent également **demander des autorisations dynamiquement** mais toutes les autorisations doivent être **déclarées** dans le **manifeste**.
Un filtre d'Intent spécifie les **types d'Intent auxquels une activité, un service ou un récepteur de diffusion peut répondre**. Il spécifie ce qu'une activité ou un service peut faire et quels types de diffusions un récepteur peut gérer. Il permet au composant correspondant de recevoir des Intents du type déclaré. Les filtres d'Intent sont généralement **définis via le fichier AndroidManifest.xml**. Pour un **récepteur de diffusion**, il est également possible de les définir en **programmation**. Un filtre d'Intent est défini par sa catégorie, ses actions et ses filtres de données. Il peut également contenir des métadonnées supplémentaires.
Dans Android, une activité/service/fournisseur de contenu/récepteur de diffusion est **publique** lorsque **`exported`** est défini sur **`true`** mais un composant est **également public** si le **manifeste spécifie un filtre d'Intent** pour celui-ci. Cependant, les développeurs peuvent **rendre explicitement les composants privés** (indépendamment de tout filtre d'Intent) en définissant l'attribut **`exported`** sur **`false`** pour chaque composant dans le fichier manifeste. Les développeurs peuvent également définir l'attribut **`permission`** pour **exiger une certaine autorisation d'accès** au composant, limitant ainsi l'accès à celui-ci.
L'**Action** de l'intent précédemment déclaré est **ACTION\_SEND** et l'**Extra** est un **Uri** mailto (l'Extra est l'information supplémentaire que l'intent attend).
Le processus de "résolution d'intent" détermine quelle application doit recevoir chaque message. Ce processus prend en compte l'attribut de **priorité**, qui peut être défini dans la déclaration de l'**intent-filter**, et **celui avec la priorité la plus élevée sera sélectionné**. Cette priorité peut être définie entre -1000 et 1000 et les applications peuvent utiliser la valeur `SYSTEM_HIGH_PRIORITY`. En cas de **conflit**, une fenêtre "choisir" apparaît pour que **l'utilisateur puisse décider**.
Celles-ci permettent à d'autres applications de **prendre des actions au nom de votre application**, en utilisant l'identité et les autorisations de votre application. Pour construire une intention en attente, il faut **spécifier une intention et l'action à effectuer**. Si l'intention déclarée n'est pas explicite (ne déclare pas quelle intention peut l'appeler), une **application malveillante pourrait effectuer l'action déclarée** au nom de l'application victime. De plus, **si une action n'est pas spécifiée**, l'application malveillante pourra faire **n'importe quelle action au nom de la victime**.
Contrairement aux intentions précédentes, qui ne sont reçues que par une seule application, les intentions de diffusion **peuvent être reçues par plusieurs applications**. Cependant, à partir de la version API 14, il est **possible de spécifier l'application qui doit recevoir** le message en utilisant Intent.set Package.
Alternativement, il est également possible de **spécifier une autorisation lors de l'envoi de la diffusion**. L'application réceptrice devra avoir cette autorisation.
Il existe **deux types** de diffusions : **normales** (asynchrones) et **ordonnées** (synchrones). L'**ordre** est basé sur la **priorité configurée dans l'élément récepteur**. **Chaque application peut traiter, relayer ou abandonner la diffusion.**
Il est possible d'**envoyer** une **diffusion** en utilisant la fonction \*\*`sendBroadcast(intent, receiverPermission)` \*\* de la classe `Context`.\
Vous pouvez également utiliser la fonction **`sendBroadcast`** de **`LocalBroadCastManager`** qui assure que le **message ne quitte jamais l'application**. En utilisant cela, vous n'aurez même pas besoin d'exporter un composant récepteur.
Si vous trouvez des fonctions contenant le mot "persistant" comme **`sendStickyBroadcast`** ou **`sendStickyBroadcastAsUser`**, **vérifiez l'impact et essayez de les supprimer**.
**Les liens profonds permettent de déclencher une intention via une URL**. Une application peut déclarer un **schéma d'URL** à l'intérieur d'une activité de sorte que chaque fois que l'appareil Android essaie d'**accéder à une adresse en utilisant ce schéma**, l'activité de l'application sera appelée :
Cela signifiera qu'il s'attend à une URL commençant par `example://gizmos`\
Dans ce cas, vous pouvez essayer d'abuser de la fonctionnalité en créant un site web avec les charges utiles suivantes. Il essaiera de naviguer vers des pages arbitraires et essaiera d'exécuter JS :
Pour trouver le **code qui sera exécuté dans l'application**, allez à l'activité appelée par le lien profond et recherchez la fonction **`onNewIntent`**.
Le **langage de définition d'interface Android** (AIDL) vous permet de définir l'interface de programmation que le client et le service acceptent pour **communiquer entre eux en utilisant une communication interprocessus** (IPC). Sur Android, **un processus ne peut normalement pas accéder à la mémoire d'un autre processus**. Pour communiquer, ils doivent décomposer leurs objets en primitives que le **système d'exploitation** peut comprendre, et marquer les objets de l'autre côté de cette frontière pour vous. Le code pour effectuer cette marquage est fastidieux à écrire, donc Android le gère pour vous avec AIDL.
Les services utilisant AIDL sont appelés **services liés**. Dans la classe du service, vous trouverez la méthode **`onBind`**. C'est **là que commence l'interaction**, c'est donc la première partie du code à examiner à la recherche de vulnérabilités potentielles.
Un service lié est le serveur dans une interface client-serveur. **Il permet aux composants (tels que les activités) de se lier au service, d'envoyer des demandes, de recevoir des réponses et d'effectuer une communication interprocessus** (IPC). Un service lié vit généralement seulement tant qu'il sert un autre composant d'application et ne s'exécute pas indéfiniment en arrière-plan.
Un Messenger est un autre type de mécanisme IPC. Puisque le **Messenger est également un "service lié"**, les données transmises depuis l'application cliente sont également traitées par la méthode `onBind`. Ainsi, l'examen du code doit commencer par cette méthode et vous devez rechercher l'invocation de fonctionnalités sensibles ou une manipulation non sécurisée des données.
Il est étrange de trouver une classe Binder directement invoquée car il est beaucoup plus facile d'utiliser AIDL (qui abstrait la classe Binder). Cependant, il est bon de savoir que **Binder est un pilote de niveau noyau qui déplace les données de la mémoire d'un processus à celle d'un autre** ([https://www.youtube.com/watch?v=O-UHvFjxwZ8](https://www.youtube.com/watch?v=O-UHvFjxwZ8)).
Une **activité Android** est un écran de l'interface utilisateur de l'application Android. De cette manière, une **activité Android** est très similaire aux fenêtres d'une application de bureau. Une application Android peut contenir une ou plusieurs activités, ce qui signifie une ou plusieurs écrans.
L'**activité de lancement** est ce que la plupart des gens considèrent comme le **point d'entrée** d'une application Android. L'activité de lancement est l'activité qui est démarrée lorsqu'un utilisateur clique sur l'icône d'une application. Vous pouvez déterminer l'activité de lancement en regardant le manifeste de l'application. L'activité de lancement aura les intentions MAIN et LAUNCHER suivantes répertoriées.
Gardez à l'esprit que toutes les applications n'auront pas d'activité de lancement, en particulier les applications sans interface utilisateur. Des exemples d'applications sans interface utilisateur (et donc sans activité de lancement) sont les applications préinstallées qui effectuent des services en arrière-plan, tels que la messagerie vocale.
Les activités peuvent être exportées, permettant à d'autres processus sur l'appareil de lancer l'activité. Par défaut, elles ne sont pas exportées, mais vous pouvez les exporter en définissant:
Notez que la capacité à **contourner les protections d'activité n'est pas toujours une vulnérabilité**, vous devez vérifier à quelles données vous avez accès.\
De plus, **certaines activités renvoient des données à un appelant**. Dans ces scénarios, vous devez rechercher la méthode **`setResult`** et vérifier les données qui sont passées dans le paramètre Intent. **Si ce sont des données sensibles, vous pourriez avoir une vulnérabilité de fuite d'informations** et elle est exploitable avec des applications capables de communiquer avec l'activité.
Les applications Android peuvent définir une **sous-classe** de [Application](https://developer.android.com/reference/android/app/Application). Les applications peuvent, mais n'ont pas besoin de définir une sous-classe personnalisée de Application. Si une application Android définit une sous-classe de Application, **cette classe est instanciée avant toute autre classe de l'application**.
[Les services](https://developer.android.com/guide/components/services) **s'exécutent en arrière-plan sans interface utilisateur.** Ils sont utilisés pour effectuer des **processus de longue durée, même si l'utilisateur commence à utiliser une application différente**.
Il existe une multitude de façons de les démarrer et sont donc un point d'entrée pour les applications. La façon par défaut qu'un service peut être démarré en tant que point d'entrée d'une application est via **Intents**.
Lorsque la méthode **`startService`** est appelée pour démarrer un Service, la méthode **`onStart`** dans le Service est exécutée. Il s'exécutera indéfiniment jusqu'à ce que la méthode **`stopService`** soit appelée. Si le service n'est nécessaire que tant que le client est connecté, le client doit s'y "connecter" en utilisant la méthode **`bindService`**.
Par exemple, un service pourrait jouer de la musique en arrière-plan pendant que l'utilisateur est dans une application différente, ou il pourrait récupérer des données sur le réseau sans bloquer l'interaction de l'utilisateur avec une activité.
Un **service peut être exporté, ce qui permet à d'autres processus sur l'appareil de démarrer le service**. Par défaut, les services ne sont pas exportés, mais cela peut être configuré dans le Manifest :
Les diffusions peuvent être considérées comme un système de messagerie et les **récepteurs de diffusion sont les auditeurs**. Si une application a enregistré un récepteur pour une diffusion spécifique, le code de ce récepteur est exécuté lorsque le système envoie la diffusion. Notez que dans ce cas, **plusieurs applications peuvent recevoir le même message**.
Il existe **2 façons** pour une application de **enregistrer un récepteur** : dans le **manifeste de l'application ou enregistré dynamiquement** dans le code de l'application en utilisant l'appel API **`registerReceiver`**. Dans le manifeste, vous pouvez limiter les diffusions que vous acceptez grâce à l'utilisation des **permissions dans l'élément récepteur**. Lorsqu'il est défini de manière dynamique, vous pouvez **transmettre la permission à la méthode `registerReceiver`**.
Dans les deux cas, pour enregistrer le récepteur, les **filtres d'intention pour le récepteur sont définis**. Ces filtres d'intention sont les diffusions qui doivent déclencher le récepteur.
Lorsque les diffusions spécifiques pour lesquelles le récepteur est enregistré sont envoyées, **`onReceive`** dans la classe BroadcastReceiver est **exécuté**.
Une application peut enregistrer un récepteur pour le message de batterie faible, par exemple, et changer son comportement en fonction de cette information.
La diffusion peut être **asynchrone** (chaque récepteur la reçoit) ou **synchrone** (la diffusion est reçue de manière ordonnée en fonction de la priorité définie pour la recevoir).
Pour **examiner** le **code** implémenté dans un récepteur de diffusion, vous devez rechercher la méthode **`onReceive`** de la classe du récepteur.\
Notez que les **diffusions ordonnées peuvent abandonner l'intention reçue ou même la modifier** en utilisant l'une des méthodes setter. Par conséquent, les **récepteurs doivent valider les données**.
Les fournisseurs de contenu sont la façon dont les **applications partagent des données structurées**, telles que des bases de données relationnelles. Par conséquent, il est très important d'utiliser des **permissions** et de définir le niveau de protection approprié pour les protéger.\
Les fournisseurs de contenu peuvent utiliser les attributs **`readPermission`** et **`writePermission`** pour spécifier les autorisations qu'une application doit avoir. **Ces autorisations ont la priorité sur l'attribut de permission**.\
De plus, ils peuvent également **autoriser des exceptions temporaires** en définissant **`grantUriPermission`** sur true, puis en configurant les paramètres appropriés dans l'élément **`grant-uri-permission`** à l'intérieur de l'élément fournisseur dans le fichier manifeste.
* Le composant Fournisseur de contenu fournit des données d'une application à d'autres sur demande.
* Vous pouvez stocker les données dans le système de fichiers, une base de données SQLite, sur le Web ou tout autre emplacement de stockage persistant accessible par votre application.
* Grâce au fournisseur de contenu, d'autres applications peuvent interroger ou même modifier les données (si le fournisseur de contenu le permet).
* Le fournisseur de contenu est utile dans les cas où une application souhaite partager des données avec une autre application.
* Il est très similaire aux bases de données et dispose de quatre méthodes.
Il s'agit d'un type de fournisseur de contenu qui **partagera des fichiers** à partir d'un dossier. Vous pouvez déclarer un fournisseur de fichiers de cette manière :
Notez l'attribut **`android:exported`** car s'il est **`true`**, les applications externes pourront accéder aux dossiers partagés.\
Notez que la configuration `android:resource="@xml/filepaths"` indique que le fichier _res/xml/filepaths.xml_ contient la configuration des **dossiers** que ce **FileProvider** va **partager**. Voici un exemple de la façon d'indiquer le partage d'un dossier dans ce fichier :
Le partage de quelque chose comme **`path="."`** peut être **dangereux** même si le fournisseur n'est pas exporté s'il existe une autre vulnérabilité dans une partie du code qui a tenté d'accéder à ce fournisseur.\
Vous pouvez **accéder** à une **image** à l'intérieur de ce dossier avec `content://com.example.myapp.fileprovider/myimages/default_image.jpg`
L'élément `<paths>` peut avoir plusieurs enfants, chacun spécifiant un répertoire différent à partager. En plus de l'élément **`<files-path>`**, vous pouvez utiliser l'élément **`<external-path>`** pour partager des répertoires dans le **stockage externe**, et l'élément **`<cache-path>`** pour partager des répertoires dans votre **répertoire de cache interne**.\
[Pour plus d'informations sur les attributs spécifiques des fournisseurs de fichiers, allez ici.](https://developer.android.com/reference/androidx/core/content/FileProvider)
Les WebViews sont en fait des **navigateurs Web** intégrés aux applications Android.\
Le contenu des WebViews peut être extrait de sites distants ou peut être des fichiers inclus dans l'application.\
Les WebViews sont **vulnérables aux mêmes vulnérabilités affectant tous les navigateurs Web**. Cependant, il existe certaines **configurations** qui peuvent être utiles pour **limiter** la **surface d'attaque**.
* Le **WebViewClient**, le mieux adapté pour le rendu HTML simple. Cela n'exécutera pas la fonction d'alerte JS. Ainsi, les tests XSS utilisant cette fonction seront invalides.
* Le **client WebChrome**, est un navigateur Chrome.
Pour charger une URL ou un fichier, il est possible d'utiliser les fonctions **`loadUrl`**, **`loadData`** ou **`loadDataWithBaseURL`**. **Il est important d'accéder uniquement aux URL sanitaires.**\
La sécurité de WebView peut être configurée via l'objet **`WebSettings`**.\
Par exemple, l'exécution de code JS peut être désactivée en utilisant la méthode **`setJavaScriptEnabled`** avec la valeur **`false`**. Cela **supprimera** la possibilité d'une **XSS** et d'autres vulnérabilités liées à JS.
La fonctionnalité JavaScript "**Bridge**" **injecte des objets Java dans un WebView les rendant accessibles à JS**. À partir d'Android 4.2, les méthodes doivent être annotées avec **`@JavascriptInterface`** pour être accessibles à JavaScript.
Si **`true`** est passé à **`setAllowContentAccess`**, **les WebViews pourront accéder aux fournisseurs de contenu** via le schéma **`content://`**. Cela pose évidemment un risque de sécurité. Notez que si cet accès est donné, il est très important de **s'assurer** que l'URL **`content://`** est **sûre**.
Par défaut, les fichiers locaux peuvent être accédés par les WebViews via des URL file://, mais il existe plusieurs façons d'empêcher ce comportement :
* En passant **`false`** à **`setAllowFileAccess`**, on empêche l'accès au système de fichiers à l'exception des ressources via `file:///android_asset`_et_`file:///android_res`. Ces chemins ne doivent être utilisés que pour des données non sensibles (comme des images), donc cela devrait être sûr.
* La méthode **`setAllowFileAccess`** indique si un chemin à partir d'une URL `file://` doit être en mesure d'accéder au contenu d'autres URL de schéma de fichier.
* La méthode **`setAllowUniversalAccessFromFileURLs`** indique si un chemin à partir d'une URL `file://` doit être en mesure d'accéder au contenu de n'importe quelle origine.
* Android exige que **toutes les applications soient signées numériquement avec un certificat** avant de pouvoir être installées. Android utilise ce certificat pour identifier l'auteur d'une application.
* Pour exécuter une application sur l'appareil, elle doit être signée. Lorsqu'une application est installée sur un appareil, le **gestionnaire de packages vérifie** si l'application a été correctement signée avec le certificat dans le fichier apk ou non.
* L'application peut être auto-signée ou signée par CA.
* La signature de l'application garantit qu'une application ne peut pas accéder à une autre application sauf par le biais d'IPC bien définis et qu'elle est transmise sans modification à l'appareil.
* Android 4.2 et ultérieur prennent en charge la vérification d'application. Les utilisateurs peuvent choisir d'activer la fonctionnalité « Vérifier les applications » et faire évaluer les applications par un vérificateur d'application avant l'installation.
* La vérification de l'application peut alerter l'utilisateur s'il essaie d'installer une application qui pourrait être dangereuse ; si une application est particulièrement mauvaise, elle peut bloquer l'installation.
MDM ou Mobile Device Management sont des suites logicielles utilisées pour **assurer un contrôle et des exigences de sécurité** sur les appareils mobiles. Ces suites utilisent les fonctionnalités appelées API d'administration de périphériques et nécessitent l'installation d'une application Android.
Généralement, les solutions MDM effectuent des fonctions telles que l'application de politiques de mot de passe, la force de chiffrement du stockage et l'activation de l'effacement à distance des données de l'appareil.
* 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)!
* 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).
