Déballage de la sécurité Android : Partie 1 Utilisation inappropriée de la plateforme

👋 Bonjour et bienvenue dans une nouvelle série d’articles de blog dans lesquels nous approfondirons la sécurité d’Android. Cette série se concentrera principalement sur les 10 principales menaces de sécurité mobiles telles que déterminées par la Fondation Open Web Application Security Project (OWASP), la principale communauté de sécurité des applications dans notre domaine.

Bien que ces articles se concentrent sur la plate-forme Android, de nombreuses idées et sentiments sous-jacents sont totalement indépendants de la plate-forme, tout comme la liste des 10 meilleurs OWASP elle-même.

Ces messages complètent également ma conférence de janvier 2022 « Ne vous faites pas piquer par l’OWASP – Une introduction à l’écriture de code pour une plus grande sécurité Android » dans laquelle j’aborde plus en détail les 5 principaux problèmes. Veuillez consulter ma page de discussions pour plus de détails et des liens pertinents. Une application complémentaire qui illustre les problèmes décrits dans la conférence est également disponible gratuitement en téléchargement.

Veuillez noter que cette série est à des fins éducatives seul. N’oubliez pas de tester uniquement sur les applications où vous avez la permission de le faire et surtout, ne soyez pas méchant.

Dans cette première partie de ma série sur la sécurité Android, nous examinerons la menace n°1 pour la sécurité des applications mobiles telle que déterminée par l’OWASP, qu’ils décrivent comme étant l’utilisation inappropriée de la plate-forme.

À première vue, l’utilisation inappropriée de la plate-forme semble être une déclaration quelque peu vague pour quelque chose qui est censé être la problème brûlant dans la sécurité des applications mobiles. Cependant, ce que ce titre essaie de dire subtilement, c’est que la principale menace pour la sécurité de nos applications mobiles est en fait nous. Pour le dire franchement, nous sommes le problème! ¹

Qu’est-ce que je veux dire par cette déclaration hyperbolique? Eh bien, c’est généralement une mauvaise utilisation involontaire d’un développeur, une négligence ou une simple incompréhension de la plate-forme Android qui entraîne nos problèmes de sécurité les plus graves.

On ne peut s’attendre à ce que personne connaisse l’intégralité de la plate-forme à fond, et les développeurs ne sont pas infaillibles. Des erreurs qui se produisent toujours, mais j’espère qu’en introduisant certains des problèmes de sécurité les plus courants que nous écrivons accidentellement dans notre code, vous réfléchirez à deux fois avant de commettre vous-même la même erreur et vous éviterez un éventuel désastre de sécurité.

Veuillez excuser le terrible jeu de mots, le premier exemple courant d’utilisation abusive de la plate-forme Android relève de la définition d’un Intent. Pour ceux qui découvrent Android, la plate-forme utilise le Intent classe comme un moyen de commencer une action quelconque. Cette action peut prendre la forme d’une navigation vers un nouvel écran dans votre application, de l’exécution d’un service d’arrière-plan/de premier plan ou de l’enregistrement d’un récepteur de diffusion pour obtenir des mises à jour régulières d’une source. le Intent La classe fournit un moyen simple de regrouper les données et de les transmettre à des composants d’application séparés et constitue le moyen le plus courant d’y parvenir avec le framework.

Cependant, le framework Android aussi permet à d’autres applications d’envoyer et de recevoir Intent instances entre elles, dans le but de faciliter la « communication » entre les applications. C’est là que réside le premier écueil courant.

Pour permettre la communication entre les applications, le ou les composants de l’application que nous souhaitons pouvoir recevoir Intent doit être marqué comme android:exported=true au sein de la AndroidManifest.xml filet. Le marquage d’un composant avec cet indicateur permet à une « intention explicite » ² d’être envoyée par toute autre application (ou le système) pour effectuer l’action spécifiée qui peut être gérée par le composant récepteur.

De plus, les composants peuvent également définir <intent-filter> dans le manifeste pour spécifier les types d’intentions auxquelles l’activité, le service ou le récepteur de diffusion peut répondre. Grâce à cette définition, une autre application peut utiliser une « intention implicite » ³ pour demander au système de montrer que votre application est compatible lorsqu’elle propose une intention spécifique. Par exemple, transmettre au système une intention implicite d’afficher des applications capables de gérer l’URL https://spght.dev peut proposer une liste des navigateurs Web installés. Cependant, quelque chose qui pourrait ne pas être évident pour les débutants est qu’en spécifiant un filtre d’intention, le composant est marqué sur le système comme exportable. même si android:exported=true n’est pas explicitement défini dans le manifeste.

D’après mon expérience, il n’est pas rare de voir des composants d’application marqués par inadvertance comme « exportables » alors qu’en fait, ils ne devraient pas l’être. Ces composants d’application mal définis posent un énorme risque de sécurité car ils deviennent directement accessibles et peuvent donc être potentiellement exploités.

La principale raison pour laquelle une exportation mal gérée est si dangereuse est due au fait qu’il est trivial de trouver ces vulnérabilités dans une application et de les cibler.

Les acteurs malveillants peuvent rechercher manuellement des applications de rétro-ingénierie ou utiliser des outils de ligne de commande tels que drozer ou slicer pour rechercher des composants exportés vulnérables. Une fois rassemblé, il est possible d’utiliser adb pour démarrer le composant ou créer une intention qui exécute l’action souhaitée par le pirate.

Un exemple concret notable de cela a été révélé par le chasseur de primes de bogues, Mehtab Zafar (mzfr), dans son article de blog de novembre 2020 détaillant comment une «activité de lien profond» mal configurée a permis à un exploit de script intersite (XSS) d’être effectué sur l’application mobile officielle GitHub. Ouais.

Dans l’application compagnon écrite pour mon discours, cela est démontré par une mauvaise configuration d’une activité MainActivity être exportable bien qu’il nécessite normalement une « authentification » pour y accéder depuis l’application.

À MainActivity est exportable, il est possible d’appeler simplement adb pour que le système ouvre l’activité et contourne ainsi le besoin d’authentification.

Tout cela peut sembler un peu effrayant, mais heureusement, arrêter ce vecteur d’attaque est aussi simple que de s’assurer que les composants pertinents de votre AndroidManifest.xml les fichiers sont marqués correctement avec android:exported.

En fait, depuis Android 12 (API 31), c’est désormais un exigence pour régler le android:exported propriété sur toute la vôtre Activity, Serviceet BroadcastReceiver définitions dans votre application AndroidManifest.xml fichier(s) lors du ciblage de ce SDK.

En tant que niveau de protection supplémentaire, la plate-forme Android permet également à une application de définir une « autorisation personnalisée » via l’utilisation d’éléments d’autorisation dans le manifeste pour restreindre les interactions avec ses composants exposés.

Par exemple, une application peut définir une autorisation de « signature » ​​qui permet uniquement l’interaction avec d’autres applications qui partagent la même autorisation. et sont construits avec le même certificat de signature :

Enfin, pour éviter le sort de GitHub, il est également de bon ton de vérifier et de valider le contenu du Intent que vous recevez lors du traitement des données d’un <intent-filter>. De ne pas faites aveuglément confiance à ce que vous recevez sera ce que vous attendez !

Dans les prochains articles de cette série, nous explorerons d’autres cas d' »utilisation inappropriée de la plate-forme » et d’autres exemples du Top 10 de l’OWASP pour mobile.