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.
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#🎜🎜 #
Les attaquants peuvent utiliser des logiciels tels que Droidjack pour générer des programmes de chevaux de Troie. Ce type de programme de cheval de Troie malveillant existe généralement sur certains marchés d'apk de troisième ordre. De manière générale, les attaquants mettront des informations alléchantes dans ces apks, telles que le visionnage gratuit de telle ou telle vidéo de beauté, un client sans publicité pour telle ou telle vidéo, un tel navigateur d'images sympa, etc. Une fois que l'attaquant a publié ces APK contenant des informations alléchantes sur Internet, il démarre un programme serveur sur le serveur distant. Une fois que l'utilisateur a installé et exécuté ce programme malveillant, le pirate informatique peut contrôler le téléphone mobile de l'utilisateur sur le serveur distant. divers comportements et voler les informations privées des utilisateurs. En dernière analyse, ces attaques au niveau des virus chevaux de Troie sont principalement dues à la faible sensibilisation des utilisateurs à la sécurité, elles ne seront donc pas les principaux objets de discussion. Nous nous concentrons principalement sur la sécurité au niveau des applications. Android. discuter. 3. Exploration des vulnérabilités côté serveur d'applications Alors, comment exploitons-nous les vulnérabilités des applications ? Tout d'abord, pour les agents de sécurité qui sont passés de la sécurité Web à l'exploration de vulnérabilités mobiles, ils souhaitent bien sûr rechercher des vulnérabilités similaires à leur propre domaine. Le côté serveur de l'application est fondamentalement le même que le côté serveur dans le domaine. domaine de la sécurité Web, sauf qu'il s'agit d'un programme Web. Son client est plutôt un navigateur, alors que les applications mobiles disposent généralement d'une application qui peut être installée sur un appareil mobile. Par conséquent, pour l’exploration des vulnérabilités du serveur d’applications, nous pouvons toujours utiliser notre expérience Web passée pour exploiter certaines vulnérabilités telles que XSS, Ssrf, l’injection SQL et la lecture de fichiers arbitraires. Lors de la recherche de vulnérabilités dans les applications Web, nous pouvons configurer le proxy dans le navigateur pour capturer les paquets et analyser nos applications Web. Alors, comment devons-nous effectuer une analyse des paquets sur les applications mobiles ? En fait, l'analyse des paquets des applications Android repose également sur le proxy, mais la configuration du proxy est relativement compliquée. Après avoir configuré les agents correspondants en burptsuit ou fiddler, nous pouvons les utiliser pour intercepter et rejouer les paquets de données. Les étapes spécifiques ne seront pas expliquées en détail ici. Il existe des tutoriels en ligne, vous pouvez les consulter par vous-même. Ici, je n'entrerai pas dans les détails de certaines vulnérabilités classiques comme l'injection xss et sql. Ici, je parlerai principalement des vulnérabilités non autorisées des applications mobiles. Nous savons qu'en matière de sécurité Web, les vulnérabilités d'accès non autorisé sont généralement causées par le fait que le serveur n'effectue pas de vérification des autorisations sur les demandes des utilisateurs et exécute les demandes des utilisateurs uniquement sur la base des ID utilisateur. Alors, quel est le processus d’authentification correct ? Une brève description sous forme de texte est la suivante : une fois que l'utilisateur s'est connecté avec succès et est authentifié, le serveur écrira les autorisations de l'utilisateur dans un cookie, puis les renverra au navigateur. Le navigateur conservera ce cookie, l'utilisateur apportera ce cookie ; paquets de requêtes ultérieurs, le serveur vérifie le cookie dans le paquet de données pour identifier les autorisations de l'utilisateur et effectuer des opérations avec les autorisations correspondantes.
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é.
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.
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.
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.
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. Cliquez sur AndroidCodeCheck.exe ou exécutez python. AndroidCodeCheck.py peut effectuer une analyse des vulnérabilités1. 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'utilisation1 Placez le fichier apk qui doit être analysé dans le répertoire workspace/apk.
4 Sortie du rapportLe chemin de sortie du rapport est sous rapport1) format txt
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
Figure 13 Vulnérabilités 5, adresse du projet
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!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
