Comment analyser la sécurité des APK et automatiser l'audit

1. Chat

En matière de sécurité mobile, vous ne la connaissez peut-être pas, car la recherche dans ce domaine n'est devenue populaire que ces dernières années. Alors, qu’est-ce que la sécurité mobile ? Tout d'abord, nous savons que la sécurité mobile n'est rien d'autre que certains problèmes de sécurité sur la plate-forme iOS et la plate-forme Android, y compris certains problèmes dans le système de plate-forme lui-même et des problèmes au niveau des applications. Bien entendu, certains protocoles de communication doivent être impliqués lorsque le client et le serveur interagissent, principalement les protocoles http et https, et bien sûr d'autres protocoles, tels que websocket, etc. Nous ne prêterons pas trop attention aux défauts de ces protocoles eux-mêmes. Ce à quoi nous devons prêter attention est de savoir si les paquets de données sont cryptés lorsque cela est nécessaire pendant la transmission, si le serveur contrôle les autorisations d'utilisation de l'utilisateur et certains services sur le serveur. . S'il existe des défauts dans le traitement logique, etc. Les idées sous cet aspect sont fondamentalement similaires à celles de la pénétration du Web, mais il existe quelques différences.

2. Attaque de chevaux de Troie

En parlant de sécurité mobile, bien sûr, les virus et les attaques de chevaux de Troie sont indispensables. Les chevaux de Troie de contrôle à distance courants incluent droidjack, SpyNote, etc. Il existe des logiciels de verrouillage apparus il y a quelque temps.

Photo 1Droidjack

Photo 2 Logiciel de verrouillage#🎜🎜 #

En termes simples, les cookies sont stockés côté client et les sessions sont stockées côté serveur. Du point de vue de la sécurité, les cookies sont relativement dangereux, tandis que les sessions sont relativement sécurisées, car les cookies sont stockés côté client et les attaquants peuvent obtenir des cookies côté client. Si le champ utilisé pour identifier l'identité de l'utilisateur n'est pas crypté, il l'est. facile à énumérer, l'attaquant peut alors falsifier des cookies et effectuer des opérations non autorisées. Si l'authentification de session est activée, le client n'obtiendra l'ID de session correspondant qu'après une connexion réussie. Cet identifiant est une chaîne cryptée et ne peut pas être traversé.

Alors, à quoi ressemble son processus de certification ? Tout d'abord, nous devons savoir que l'authentification de session repose également sur les cookies. Une fois que l'utilisateur s'est connecté avec succès, le serveur écrira la session correspondante de l'utilisateur dans la base de données du serveur. La session contient certaines informations d'identité de l'utilisateur et d'autres informations. puis le serveur L'ID correspondant à cette session sera envoyé au client, donc le contenu du cookie dans le client n'est généralement qu'une chaîne de sessionid=xxxxxx. L'utilisateur doit apporter cet ID de session dans les requêtes ultérieures. Le serveur identifie l'ID de session, puis interroge la base de données pour obtenir les informations d'autorisation de l'utilisateur correspondantes, puis détermine si l'utilisateur est autorisé à effectuer l'opération de réponse.

Évidemment, le mécanisme de session est relativement plus sûr, mais l'autre côté de la sécurité a également un prix Par rapport aux cookies, le mécanisme de session consommera plus de performances du serveur.

Figure 4 Processus d'authentification de session

Cependant, du côté mobile, l'authentification de l'identité de l'utilisateur n'utilise pas de cookies, mais est basée sur l'identification par jeton. Alors, de quel type de méthode d’authentification s’agit-il ? Pour l'exprimer en bref, son processus d'authentification est généralement le suivant : une fois la vérification de la connexion du client réussie, le serveur renvoie une chaîne de jeton. Cette chaîne est l'identifiant de session de l'utilisateur. Vous devez apporter ce jeton avec vous afin que l'identité de l'utilisateur puisse être identifiée.

Figure 5 Processus d'authentification par jeton

Si nous trouvons une demande sans jeton lors de l'analyse du paquet de données, alors ce paquet de données est susceptible d'avoir une vulnérabilité d'accès non autorisé. Bien entendu, elle doit être combinée avec le scénario spécifique. . Analysez et déterminez si cela a un impact sur la logique métier. C'est notre posture générale pour découvrir les vulnérabilités non autorisées sur le terminal mobile. Cependant, cette posture est trop retardée mentalement. En gros, quiconque la rencontre peut la creuser.

Il existe une autre façon de rechercher les vulnérabilités d'accès non autorisé, ce qui semble plutôt étrange. La cause première de cette vulnérabilité d'accès non autorisé est l'erreur dans la stratégie d'authentification elle-même. Je me souviens qu'il y a longtemps, j'avais effectué une analyse de protocole sur un logiciel de diffusion en direct et découvert que sa logique d'authentification était la suivante : une fois la vérification de la connexion de l'utilisateur réussie, le serveur renvoie l'identifiant de l'utilisateur, puis produit localement le jeton de l'utilisateur. . Dans les demandes ultérieures, apportez ce jeton comme preuve de l'identité de l'utilisateur. C'est évidemment bogué, car l'ID utilisateur peut être traversé et l'algorithme de génération de jeton est local, donc l'attaquant peut calculer le jeton lui-même tant qu'il obtient les identifiants des autres utilisateurs et extrait l'algorithme de génération de jeton local, et. puis le faux utilisateur s'est connecté.

Bien sûr, il est encore relativement difficile de découvrir de telles vulnérabilités non autorisées, ce qui nécessite que les chercheurs de vulnérabilité disposent de capacités d'analyse inverse et de capacités de codage relativement approfondies. Cependant, en tant que développeur, vous ne devez pas relâcher le renforcement de la sécurité des applications à cause de cette difficulté. Surtout pour l'authentification des utilisateurs, un module fonctionnel très important, vous devez prendre une bonne protection de sécurité.

4. Exploration des vulnérabilités du client Apk

1. Introduction des outils couramment utilisés

En ce qui concerne les vulnérabilités des clients, la méthode principale consiste à décompiler le client de l'application via des outils de décompilation pour obtenir le code source, puis à combiner une certaine expérience et connaissances en sécurité. à l'audit statique du code source. Les outils de décompilation courants incluent apkide, jeb, apktools, etc. Faisons une capture d'écran pour que vous compreniez :

Photo 6 Principe de changement

Photo 7 Jeb

Bien sûr, mon préféré est l'assistant de marche arrière Android, qui est très pratique.

Assistant inverse Android Figure 8

Utilisé en conjonction avec jeb, il peut essentiellement répondre à l'analyse inverse quotidienne.

La plateforme d'applications Android est principalement divisée en couche native et couche Java. Pour la couche Java, nous pouvons utiliser les outils ci-dessus pour l'analyse, et pour la couche native, nous devons utiliser ida pour l'analyse. Ida est un outil de désassemblage très simple à utiliser. Nous pouvons désassembler le fichier so de l'apk via ida, puis utiliser sa fonction f5 pour convertir le code d'assemblage arm en pseudo-code c++ et analyser l'algorithme logique. Il prend également en charge le débogage dynamique et peut déboguer à distance les applications apk. Nous pouvons utiliser le débogage dynamique ida pour contourner certaines vérifications dans la couche so, telles que la vérification du packaging secondaire, ou effectuer un débogage et un shelling dynamiques.

2. Introduction au bombardement d'applications

En parlant de bombardement d'applications, cela est très nécessaire pendant le processus d'analyse de l'apk. Avant de parler de déballage, comprenons d’abord ce qu’est l’emballage. L'empaquetage signifie d'abord obtenir le contrôle du programme avant l'exécution de l'application, puis transférer le contrôle du programme au programme d'origine. L'implémentation de l'emballage sur la plate-forme Android consiste à crypter et masquer le fichier dex d'origine, puis à obtenir le fichier dex d'origine via le programme shell et à le restaurer. L'autre méthode consiste à extraire les instructions de fonction et à utiliser des hooks pour répondre lors de l'exécution. La fonction de chargement de classe remplit les instructions.

Pour les applications packées, la logique du programme d'origine est fondamentalement méconnaissable et nous ne pouvons pas effectuer d'analyse de sécurité via le programme packé. Par conséquent, nous devons décompresser l'application. Les outils de déballage automatisés courants incluent drizzledump et dexhunter. Dexhunter est facile à utiliser, mais il nécessite un flashage, et de nombreux fournisseurs de cryptage l'ont vérifié, il ne fonctionnera donc pas si vous l'utilisez directement. Vous devez apporter quelques modifications et contourner certaines détections. Quant à l’utilisation détaillée, vous pouvez trouver des tutoriels en ligne, je n’entrerai donc pas dans les détails ici. Si l'outil ne fonctionne pas, vous devrez finalement vous rendre sur ida.

3. Audit du code source statique

Examinons en détail les problèmes auxquels il faut prêter attention en matière de détection de sécurité au niveau du code source.

Sécurité des composants

Le premier est la problématique de sécurité des composants Nous savons que les applications Android comportent quatre composants majeurs, à savoir : l'activité, le service. , fournisseur de contenu, récepteur de diffusion. Si ces composants ne sont pas très nécessaires, leur attribut d'exportation, exported, doit être défini sur false, c'est-à-dire que l'exportation est interdite. S'il est défini sur true, il sera appelé par des applications externes, ce qui peut entraîner une fuite d'informations, un contournement d'autorisations et d'autres vulnérabilités. De plus, lors de l'utilisation de Intent.getXXXExtra() pour obtenir ou traiter des données, si try...catch n'est pas utilisé pour la gestion des exceptions, une vulnérabilité de déni de service peut se produire. Ces exceptions incluent, sans s'y limiter : une exception de pointeur nul, exception de conversion de type, exception d'accès hors limites de tableau, exception de classe non définie, exception de sérialisation et de désérialisation.

Comme la sécurité des composants mentionnée ci-dessus, nous la jugeons généralement en analysant le fichier androidManifest.xml d'Android. AndroidManifest.xml est le fichier d'entrée des applications Android. Il décrit les composants exposés dans le package (activités, services, etc.), leurs classes d'implémentation respectives, diverses données pouvant être traitées et l'emplacement de démarrage. En plus de déclarer les activités, les fournisseurs de contenu, les services et les récepteurs d'intention dans le programme, les autorisations et l'instrumentation (contrôle et tests de sécurité) peuvent également être spécifiés. En analysant ce fichier manifest.xml, nous pouvons également découvrir des vulnérabilités telles que la sauvegarde des données des applications et la personnalisation des applications. Bien entendu, ces vulnérabilités sont généralement des vulnérabilités à risque relativement faible, c'est-à-dire qu'elles n'auront pas beaucoup d'impact sur la logique métier du programme. De plus, en raison de la vulnérabilité du débogage de l'application, même si debuggable est défini pour interdire aux attaquants de déboguer l'application, cela n'empêchera pas les attaquants de déboguer l'application, car les développeurs ne peuvent contrôler que l'application elle-même à partir du débogage, mais ne peuvent pas contrôler le système de l'utilisateur. . Un attaquant peut déboguer toutes les applications du système en définissant une propriété en mémoire, que l'application soit définie ou non pour être déboguée. Cependant, il est toujours nécessaire de définir ce paramètre pour désactiver le débogage ici, car tous les analystes inverses ne savent pas que ce paramètre peut être contourné.

problème de sécurité webview

Pour dire qu'il existe des vulnérabilités plus graves dans les applications clientes Android, il doit s'agir de vulnérabilités webview. De nombreuses applications ont désormais des pages Web intégrées, telles que de nombreuses plateformes de commerce électronique, Taobao, JD.com, Juhuasuan, etc., comme indiqué ci-dessous :

Le composant Webview peut être décrit comme une épée à double face. D'une part, son apparence peut réduire la charge de développement client et placer la logique principale du programme sur le serveur pour la mise en œuvre. Localement, il vous suffit d'utiliser WebView. pour charger la page Web correspondante. Mais si elle est mal configurée, des vulnérabilités d'exécution de commandes à distance peuvent exister. Les CVE concernés incluent CVE-2012-6636, CVE-2014-1939 et CVE-2014-7224.

cve-2012-6636 Cette vulnérabilité est causée par le programme qui ne restreint pas correctement l'utilisation de la méthode WebView.addJavascriptInterface. Un attaquant distant pourrait exploiter cette vulnérabilité pour exécuter des méthodes d'objet Java arbitraires à l'aide de l'API Java Reflection.

cve-2014-1939 Cette vulnérabilité est causée par java/android/webkit/BrowserFrame.java utilisant l'API addJavascriptInterface et créant un objet de la classe SearchBoxImpl. Un attaquant peut exploiter cette vulnérabilité pour exécuter du code Java arbitraire en accédant à l'interface searchBoxJavaBridge_. .

cve-2014-7224 L'attaquant utilise principalement les deux Java Bridges d'accessibilité et d'accessibilitéTraversal pour exécuter du code d'attaque à distance.

La génération d'exécution de commandes à distance Webview repose également sur le mécanisme de réflexion de Java. La méthode addJavascriptInterface dans Webview peut injecter un objet Java dans WebView, et les méthodes de cet objet Java sont accessibles par Javascript. La raison pour laquelle addJavascriptInterface est fourni est que Javascript dans WebView puisse communiquer avec l'application locale. Il s'agit en effet d'une fonction très puissante. L'avantage est que lorsque la logique locale de l'application reste inchangée, le programme peut être mis à jour sans mettre à jour l'application et la page Web correspondante peut être modifiée. Cependant, dans les premières versions d'Android, il n'y avait aucune restriction sur les méthodes accessibles. Grâce au mécanisme de réflexion de Java, vous pouvez appeler n'importe quelle méthode de n'importe quel objet. C'est la cause fondamentale de la vulnérabilité WebView.

Attaque du package de mise à jour apk (attaque de l'homme du milieu)

Les vulnérabilités mentionnées ci-dessus sont relativement courantes dans les applications Android et ont un impact relativement important. Il existe également certaines vulnérabilités qui ont un impact relativement léger, mais. s'ils sont utilisés correctement, ils peuvent être nocifs. Par exemple, une attaque de l'homme du milieu nécessite que l'attaquant et la victime soient sur le même réseau local, et que le trafic de la victime soit contrôlé par l'attaquant. Que peut faire une attaque de l’homme du milieu ? Jouer à XSS ? Obtenir le cookie utilisateur ? Bien entendu, il est évidemment inutile d'obtenir le cookie utilisateur ici, il devrait s'agir des informations du jeton. Dans les attaques mobiles, des attaques de type « man-in-the-middle » correctement exploitées peuvent même conduire à l’exécution de commandes à distance. Par exemple, le package de mise à jour téléchargé lors de la mise à jour de l'application est contrôlé et remplacé par un paquet de données d'attaque malveillant. L'application exécute le programme de mise à jour dans le package renvoyé modifié par l'attaquant sans effectuer la vérification de signature nécessaire sur le package de mise à jour. provoquer l’exécution de programmes malveillants.

5. Implémentation de l'outil d'analyse statique des vulnérabilités Apk

1. Introduction au projet

Il n'existe actuellement aucun bon moteur d'analyse pour la détection des vulnérabilités côté client. Il y a quelque temps, j'ai enquêté sur une certaine entreprise numérique, un certain Bang et un certain outil d'analyse de sécurité APK crypté. Les résultats étaient moyens et fondamentalement similaires. Ils étaient tous basés sur une simple vérification de vulnérabilité basée sur le code source décompilé. Pouvons-nous donc également écrire nous-mêmes un outil de détection automatisé ? J'ai également écrit un outil d'analyse automatisé des fichiers manquants apk auparavant.

Permettez-moi de parler de mon idée d'implémentation ci-dessous. Tout d'abord, nous savons que nos principaux objets d'analyse sont les fichiers AndroidManifest.xml et dex, mais ces deux-là sont des fichiers binaires compilés et nous devons les décompiler. L'outil nécessaire pour décompiler AndroidManifest.xml est AXMLPrinter.jar, et le fichier nécessaire pour décompiler les fichiers dex est baksmali.jar. En fait, ces deux packages jar sont également couramment utilisés par certains outils d’ingénierie inverse. Jetons un coup d'œil au répertoire du programme de l'outil de décompilation de l'assistant inverse Android :

Figure 10 Répertoire du programme de l'assistant inverse Android

Cet outil inverse appelé Android Reverse Assistant utilise principalement ces deux outils pour implémenter le fichier AndroidManifest décompilé avec dex. .

Tant que nous écrivons la logique correspondante dans notre outil d'analyse automatisée des fuites et que nous appelons ces deux outils pour décompiler les fichiers AndroidManifest et dex, nous pouvons détecter la vulnérabilité en faisant correspondre certaines caractéristiques de vulnérabilité.

Ce qui suit est une brève introduction à la structure du répertoire du projet :

Figure 11 Répertoire et introduction du projet d'analyse des vulnérabilités Apk

Nous avons d'abord besoin du nom du package de l'application, puis détectons certains paramètres de l'application, tels que si la sauvegarde est autorisée, si elle est réglable, etc. ; nous obtenons ensuite des informations de configuration des quatre composants activité, service, contenu. fournisseur, récepteur de diffusion et déterminer s'il peut être exporté ; puis obtenir les autorisations appliquées par l'application pour déterminer si elle est trop sensible pour déterminer si elle a des restrictions d'autorisation ;

Ensuite, effectuez la détection des fonctionnalités de vulnérabilité sur le fichier smali décompilé. Cela repose principalement sur les caractéristiques de vulnérabilité que nous avons collectées au préalable. Ici, j'écris les caractéristiques de la vulnérabilité dans un fichier XML et, lors du démarrage de l'analyse des vulnérabilités, je le charge dans la mémoire pour que le programme l'appelle. Nous pouvons personnaliser ces caractéristiques de vulnérabilité afin que notre programme puisse analyser davantage de vulnérabilités. Actuellement, la définition des caractéristiques de vulnérabilité prend en charge les formes de chaîne et régulières. Ce projet est toujours en maintenance, mais les fonctions de base ont été implémentées et peuvent répondre à l'analyse et à la détection quotidiennes. Il suffit d'effectuer un dépannage sur les résultats de l'analyse.

2. Types de détection de vulnérabilité actuellement pris en charge par le logiciel

1. Vulnérabilité de lecture et d'écriture de fichiers arbitraires

2. Vulnérabilité clé de codage en dur

3. Vulnérabilités de déni de service local

5, vulnérabilité d'URL de schéma d'intention

6, vulnérabilité d'injection SQL locale du composant du fournisseur de contenu

7, détection de sécurité de chargement dynamique de code

8, vérification faible du certificat

9, vérification faible du nom d'hôte

10, vulnérabilité de piratage de données sensibles HTTPS

11, algorithme de hachage dangereux

12, cryptage AES faible

13, fuite d'informations privées de localisation

14, risque de fuite de journaux

15, risque d'utilisation abusive d'intention en attente

16, intention implicite Appelez

17. Lecture et écriture arbitraires de fichiers de base de données

18. Détection de vulnérabilité d'interface cachée du système WebView

19. Détection de vulnérabilité d'exécution de code à distance du composant WebView

20. mot de passe de stockage

22. Toute lecture et écriture de SharedPreferences

23 Lecture et écriture de n'importe quel fichier

24 L'utilisation de nombres aléatoires est dangereuse

25.

27. Vérification des autorisations de l'application

28, Vérification des autorisations personnalisées de l'application

30, Vérification de la vulnérabilité de la sauvegarde de l'application

3 Méthode d'utilisation

1 Placez le fichier apk qui doit être analysé dans le répertoire workspace/apk.

4 Sortie du rapport

Le chemin de sortie du rapport est sous rapport

Il peut être considéré comme le. journal d'exécution du programme et peut également être utilisé comme référence pour les résultats de l'analyse.

2) Format HTML

Le rapport au format html possède un répertoire. Cliquez sur le nom de la vulnérabilité dans le répertoire pour accéder à la description du type de vulnérabilité correspondant. Dans la description du type, vous pouvez cliquer sur Retour au répertoire pour revenir à la liste du répertoire des vulnérabilités afin de faciliter l'examen des vulnérabilités.

Enfin, je vais vous donner une capture d'écran du rapport d'analyse des vulnérabilités. Il est un peu brut et sera progressivement amélioré ultérieurement.首 Figure 12 Page d'accueil du répertoire de rapports

APK Outil de démonstration et d'analyse du code source statique Adresse du projet :

https://github.com/zsdlove/ApkVulCheck

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!