Editions ENI Livres | Vidéos | e-Formations
Tester des applications mobiles
Introduction
Maintenant que nous connaissons le fonctionnement des applications Android ainsi que les composants internes, il est temps de se concentrer sur la partie "testing", dans laquelle nous allons voir les choses du point de vue d’un hacker éthique. Et parce qu’il n’est pas toujours facile pour les développeurs de développer une application sans vulnérabilités, surtout sans de bonnes connaissances de tous les mécanismes mis en place ainsi que du fonctionnement d’une application, de la mémoire, etc., nous allons voir dans ce chapitre comment déceler les différentes failles de sécurité connues et voir comment il est possible de les exploiter. Il y a actuellement près de trois millions d’applications sur le Google Play Store et ce nombre croît chaque jour. Imaginez le nombre de failles potentielles existant dans la nature ! Avec les connaissances nécessaires sur les différentes failles de sécurité ainsi que sur l’exploitation de ces failles, il est beaucoup plus facile de sécuriser ces applications et d’adopter les bonnes pratiques et les bons comportements pour éviter les mauvaises surprises. Commençons par énumérer les méthodologies standards avant de tester des applications vulnérables.
Méthodologie
La méthodologie est une chose importante dans le hacking éthique parce que nous n’allons pas tester une application et l’OS Android n’importe comment. Il y a quelques phases à ne pas négliger et il existe différentes méthodologies que nous verrons dans la suite de ce livre. Commençons par les phases de tests standards d’une application.
1. Découverte de l’environnement
Il faut avant tout connaître la ou les applications cibles disponibles ainsi que l’environnement sur lequel l’application s’exécute. Dans notre cas, ce sera bien évidemment Android, mais dans un cas réel de test d’intrusion, nous ne savons jamais ce que nous allons trouver dans le réseau interne. Il faudra alors scanner les cibles pour découvrir les applications qui s’exécutent afin de trouver l’environnement sur lequel nous allons effectuer nos tests.
2. Analyse
L’analyse est l’étape destinée à la collecte d’informations afin d’avoir une idée précise sur le type d’application à tester. La collecte d’informations est une étape très importante également, voire fondamentale, dans le hacking éthique pour obtenir un maximum d’informations sur l’application cible et découvrir le plus de vulnérabilités possible. En effet...
Recherche de vulnérabilités et exploitation
Il est temps maintenant de rechercher et d’exploiter les vulnérabilités que nous allons découvrir dans nos applications. Nous avons vu les vulnérabilités des applications mobiles selon le top 10 de l’OWASP. Nous allons alors illustrer ces vulnérabilités par la pratique en les utilisant pour tester les faiblesses de nos applications et de notre système. Nous allons nous servir d’outils, qui sont une référence dans ce domaine et très appréciés par de nombreux développeurs et testeurs d’applications.
1. Drozer
Drozer n’est plus à présenter maintenant et nous allons commencer par exploiter la puissance de cet outil en analysant nos applications vulnérables, en découvrant leur surface d’attaque et en tentant de découvrir leurs failles de sécurité. Avant de commencer, assurons-nous que nous sommes bien connectés à notre service virtuel Android et que tous nos outils sont démarrés et bien configurés, comme vu précédemment dans le chapitre Préparation de l’environnement de test Android. Nous pouvons ensuite passer aux choses sérieuses. N’hésitez pas à consulter l’aide de l’outil.
a. Analyse
La toute première chose à faire quand nous connaissons l’environnement de test est de regarder quelle application se trouve sur le système et surtout comment l’appeler (du moins, comment l’invoquer). Nous allons commencer par tester l’application GoatDroid, et plus précisément Fourgoats, car GoatDroid dispose d’une seconde application vulnérable appelée Herd Financial.
Nous allons taper dans la console Drozer run app.package.list -f org comme ci-dessous pour avoir des informations :
Nous pouvons clairement voir maintenant le nom complet de l’application (ou du package), soit org.owasp.goatdroid.fourgoats ; c’est ce nom que nous devrons mettre à la fin de chaque requête que nous allons faire. Maintenant que nous connaissons cette information, nous allons pouvoir essayer plusieurs choses. Nous commençons par ouvrir le fichier AndroidManifest.xml. Comme nous le savons, le fichier peut contenir des informations importantes...
Décompilation d’une application pour analyse
Nous allons maintenant examiner notre fichier AndroidManifest.xml avec un autre outil (APKTool) que nous avons installé. Nous pourrons ainsi étudier en détail l’intégralité de l’application, comme son code source, tous les fichiers qu’elle contient, de quelle manière elle a été développée, etc. Pour ce faire, nous aurons besoin de décoder (ou décompiler) le code source, c’est-à-dire le fichier .apk contenant le code source de l’application. Nous avions tapé dans le chapitre Préparation de l’environnement de test Android la commande :
java -jar apktool_2.3.4.jar Cette commande vérifie les différentes options disponibles, comme l’illustre la figure ci-dessous :
Nous n’allons pas passer en revue toutes les différentes options disponibles, mais ce qui nous intéresse ici, comme nous voulons décoder l’application (fichier .apk), c’est l’option d, qui signifie "décode". Pour ce faire, tapons dans l’invite de commandes java -jar apktool_2.3.4.jar d suivi du nom de l’application que nous souhaitons décoder. Nous allons reprendre, pour illustrer le principe, le fichier EniTest.apk, utilisé en début de chapitre avec les outils dex2jar et JD-GUI. Il faut se rappeler...
Analyse du trafic Android
Nous avons étudié dans le chapitre Les différents types d’attaques, des attaques de type Man-in-the-Middle (l’homme au milieu). Nous allons mettre en pratique ce type d’attaque voir comment il est possible d’intercepter le trafic de notre appareil Android si une faille de sécurité est présente. Pour ce faire, nous allons nous servir de l’outil Burp Suite, mais commençons tout d’abord par configurer l’outil dans notre service virtuel Android de manière à pouvoir récupérer le trafic et se placer au milieu de la communication (d’où le nom de "l’homme au milieu").
Rendons-nous dans le service virtuel Android et allons dans les paramètres Wi-Fi, comme ci-dessous :
Sélectionnons Wi-Fi ; nous devrions obtenir une fenêtre comme celle ci-dessous :
Ensuite, cliquons sur WiredSSID jusqu’à ce que nous récupérions une fenêtre qui permettra de configurer le proxy comme ci-dessous :
Rendons-nous dans Modify network :
Sélectionnons les options avancées Advanced options et, dans Proxy, sélectionnons le mode manuel Manual et entrons l’adresse IP du proxy ainsi que le port d’écoute (ici, le 8080), puis validons les changements. Nous obtenons ainsi une fenêtre...
Un autre outil intégré au SDK
Un autre outil intégré directement au SDK qui peut être utile est Monkeyrunner, qui est sans doute moins connu du grand public et plus connu des développeurs, car il fournit une API pour écrire des programmes qui contrôlent un périphérique ou un émulateur Android en dehors du code Android.
Avec Monkeyrunner, nous pouvons par exemple écrire un programme Python qui installe une application ou un package de test. Dans ce cas, Android l’exécute, lui envoie des frappes au clavier, prend des captures d’écran de son interface utilisateur et stocke les captures d’écran sur le poste de travail.
L’outil Monkeyrunner est principalement conçu pour tester les applications et les périphériques au niveau fonctionnel, mais nous pouvons l’utiliser pour exécuter d’autres actions. Il s’exécute dans un shell ADB directement sur le périphérique ou l’émulateur et génère des flux pseudo-aléatoires d’événements utilisateur et système. Monkeyrunner contrôle les périphériques et les émulateurs à partir d’un poste de travail en envoyant des commandes et des événements spécifiques à partir d’une API.
L’outil Monkeyrunner fournit ces fonctionnalités...
Conclusion
Dans ce chapitre, nous avons passé en revue une grande majorité de failles de sécurité incluses du top 10 de l’OWASP. Nous étudierons les autres failles du top 10 dans le chapitre suivant, pour les reproduire sur d’autres systèmes. Nous avons vu qu’avec une bonne logique et les bons outils, il était possible de tester de manière efficace nos applications vulnérables. Nous n’avons pas exploré tous les modules disponibles dans l’outil Drozer. Nous vous laissons explorer tous ces modules par vous-même et vous rendre compte de la puissance de cet outil.
