Introduction

En tant que fan inconditionnel des téléphones Android, si votre téléphone tombe soudainement, votre première pensée serait-elle "Oh mon Dieu !" ou que votre argent dans Google Pay ou Paypal n'est pas en sécurité ? Si la dernière application téléchargée affiche non seulement diverses publicités ennuyeuses, mais également des notifications inattendues, penseriez-vous qu'il pourrait s'agir d'une tentative de phishing et désinstalleriez-vous immédiatement l'application ?

Comment pouvons-nous garantir que notre application offre une expérience sûre aux utilisateurs qui ne connaissent pas suffisamment les vulnérabilités de sécurité d'Android ? Quelles sont les failles de sécurité de l’écosystème Android ? Où pouvons-nous explorer de nouvelles techniques de test de sécurité Android ? Comment pouvons-nous rationaliser le processus de test de sécurité ?

Vulnérabilités de sécurité Android courantes

Premièrement, l'avantage du développement open source du système d'exploitation Android cache également des problèmes de sécurité inhérents à son développement, tels que le système sandbox du système Android (c'est-à-dire la machine virtuelle). Cependant, la couche sous-jacente présente une vulnérabilité après l'autre, permettant aux programmes (ou outils) malveillants d'obtenir un accès root et de briser les restrictions du bac à sable. Tout comme à l’ère du PC, il n’existe pas de système d’exploitation PC absolument sécurisé ; À l’ère de l’Internet mobile, il n’existe pas non plus de système d’exploitation mobile absolument sécurisé. Les risques de sécurité de l'écosystème open source Android sont comme des sonnettes d'alarme tachées de sang, frappant le cœur de chaque développeur Android.

Deuxièmement, les risques de sécurité dans le processus de développement d'applications/SDK Android sont comme des trous noirs inconnus. Nous ne savons jamais où se situe le point final d’une confrontation sécuritaire, qui sont les attaquants, qui sont les terminateurs et comment se défendre contre eux.

Enfin, au niveau de l'utilisateur, quelles sont les vulnérabilités de comportement de sécurité courantes et reconnaissables ?

Les applications Android et les SDK présentent dans une certaine mesure des failles de sécurité. Peut-être qu'un jour, votre application pourrait être affectée par l'une des vulnérabilités de sécurité ci-dessus. Par coïncidence, lors du test récent d'un SDK Android, nous avons découvert une vulnérabilité de sécurité liée aux composants d'application Android. Sur la base de cet exemple, les méthodes, techniques et processus de test de sécurité du SDK Android sont résumés.

Exemples de tests de sécurité des applications Android

Aperçu des causes de vulnérabilité
Un composant facultatif d'une application (ci-après dénommé l'application) Android SDK a ouvert un port aléatoire localement pour surveiller si le service de couche Java est actif. Cependant, lorsque la couche Java communique avec le composant, elle ne vérifie pas strictement les paramètres d'entrée, ce qui entraîne la possibilité d'être remplie de code d'attaque et d'attaques malveillantes lors de l'appel de la fonction "system()" du système Linux.

La capture d'écran suivante montre qu'après l'attaque du port de simulation, l'intention du composant d'application modifie le contenu de l'URL pendant la communication et la vue Web affiche un code tronqué :

Risques de sécurité potentiels de la vulnérabilité

Les quatre principaux composants d'application des applications Android : activité, récepteur, service et fournisseur de contenu, ainsi que les rôles de sécurité des composants d'application communiquant via une intention pour IPC, ne seront pas abordés en détail ici. Tirant parti de la vulnérabilité liée aux composants dans l'exemple ci-dessus, le diagramme suivant montre les dimensions de l'attaque liées au côté APP du terminal :

En raison de l'environnement d'application local de l'application Android, la prise réseau manque intrinsèquement de mécanisme d'authentification et d'autorisation précis. Par conséquent, si le client Android est utilisé comme serveur, que le code inverse est utilisé pour rechercher le numéro de port aléatoire local de l'application et que l'attaque est activement envoyée au port, les risques de sécurité suivants se cacheront :

1. Exécution de commande locale : lorsque le nom du package de l'application intégrée est spécifié comme l'application elle-même et que le nom du composant est spécifié comme l'activité de l'application, toute activité de l'application peut être commencé, y compris l'activité non exportée protégée, créant ainsi un risque pour la sécurité. Par exemple, une vulnérabilité de déni de service peut être détectée en démarrant une par une plusieurs activités non exportées via des requêtes HTTP.

2. Contrôle de commande pour modifier les autorisations de l'application : transmettez l'intention de démarrer les composants de l'application Android via le port de socket ouvert, puis exécutez des opérations telles que le démarrage d'une activité et l'envoi de diffusion avec les autorisations du application attaquée. Parce que les intentions transmises via le socket ne peuvent pas effectuer de contrôles précis sur l'identité et les autorisations de l'expéditeur, contournant la protection des autorisations fournie par Android pour les composants d'application, et peuvent démarrer les composants d'application non exportés et protégés par autorisation, ce qui présente un risque pour la sécurité.

3. Divulgation d'informations sensibles, contrôle du téléphone mobile : un service local ouvre le port UDP pour écouter, et après avoir reçu un mot de commande spécifique, il peut renvoyer les informations sensibles du téléphone mobile. Par exemple, le majordome du téléphone mobile Baidu peut gérer à distance la clé secrète du téléphone portable, puis des attaquants non autorisés peuvent gérer entièrement le téléphone portable via le réseau.

Exécution des tests de sécurité Android

Optimisation de la version de renforcement de la sécurité Android

1. Ajoutez des contrôles pour les commandes système et un filtrage des caractères spéciaux dans les couches natives et Java.

2. Crypter la communication du socket pour le processus démon JNI Watchdog.

3. Ajoutez une fonctionnalité de vérification pour les URL, les intentions et les activités dans les fonctions de notification locales afin d'empêcher la redirection vers des liens malveillants lorsque vous cliquez sur les notifications.

4. Modifiez l'emplacement de stockage du nom du package dans le stockage local de l'application.

5. Ajoutez une fonctionnalité de configuration en ligne.

Ce sont les exigences importantes pour cette optimisation du renforcement de la sécurité.

Tests de sécurité spéciaux

Si vous suivez des tests de système ou des tests de performances conventionnels, il vous suffit d'effectuer des tests avancés en fonction des exigences changeantes. Cependant, pour les tests de sécurité, garantir la robustesse de la sécurité du SDK nécessite des tests spéciaux inversés, simulant diverses méthodes d'attaque de sécurité et des cas de test divergents pour les points modifiés.

Tests de régression de sécurité réguliers sur Android

1. Données de confidentialité : sécurité du stockage externe et sécurité du stockage interne ; vérifiez si les noms d'utilisateur, les mots de passe, les enregistrements de discussion, les informations de configuration et autres informations privées sont enregistrés localement et cryptés ; vérifier l'intégrité des informations avant de les utiliser.

2. Attaques par autorisation : vérifiez le répertoire de l'application et assurez-vous que ses autorisations ne permettent pas aux autres membres du groupe de lire ou d'écrire ; vérifiez si les autorisations système sont attaquées.

3. Protection des autorisations des composants Android : empêchez les composants internes de l'application d'être appelés arbitrairement par des programmes tiers : empêchez les activités d'être appelées par des programmes tiers, empêchez le piratage d'activités ; assurer la sécurité de la réception et de la transmission des émissions, recevoir uniquement les émissions envoyées par l'application et empêcher des tiers de recevoir le contenu transmis ; empêcher le démarrage ou l'arrêt malveillant des services ; vérifier les autorisations de fonctionnement du fournisseur de contenu ; si les composants doivent être appelés en externe, vérifiez si des restrictions de signature ont été appliquées à l'appelant.

4. Mises à niveau : vérifiez l'intégrité et la légalité du package de mise à niveau pour éviter tout piratage.

5. Bibliothèques tierces : si des bibliothèques tierces sont utilisées, suivez leurs mises à jour et vérifiez leur sécurité.

6. Sécurité des ROM : utilisez des ROM officielles ou des ROM fournies par des équipes faisant autorité pour éviter l'ajout de publicités implantées, de chevaux de Troie, etc.

7. Contre-mesures anti-fissuration : contrecarre la décompilation, rendant impossible la décompilation à l'aide des outils de décompilation ou l'obtention du code de désassemblage correct après la décompilation ; contrecarrer l'analyse statique en utilisant l'obscurcissement et le cryptage du code ; contrecarrer le débogage dynamique en ajoutant du code pour détecter les débogueurs et les émulateurs ; empêcher la recompilation en vérifiant les signatures et en vérifiant la valeur de hachage du fichier dex compilé.

Après avoir terminé les tests de sécurité spéciaux et les tests de processus réguliers, effectuez des tests de régression continue pour les fonctionnalités existantes de l'application, la compatibilité entre les nouvelles et les anciennes versions et la compatibilité avec les différentes versions du système d'exploitation Android.

Conclure

Par rapport aux scénarios de tests ordinaires de performances et de fonctionnalités du système, les scénarios de tests de sécurité nécessitent une compréhension plus complète de l'écosystème Android, par exemple : couvrant le niveau d'apparence de sécurité de l'utilisateur, le niveau d'attaque locale et à distance du système d'application et le niveau de vulnérabilité du système d'exploitation, avec se concentrer davantage sur la conception de cas de test de réflexion sur les attaques inversées.

Si le point de départ du développement est la défense de la sécurité, le point de départ des tests est la mentalité d'attaque de pirate informatique. La conception de scénarios de test pour des scénarios d'attaque et la mise en œuvre de techniques de test d'attaque déterminent la robustesse de la sécurité du SDK.

Pour garantir le plus haut niveau de sécurité pour vos applications, envisagez d'utiliser les tests de sécurité des applications WeTest. Ce service fournit une évaluation complète des problèmes de sécurité dans les applications, une détection rapide des vulnérabilités des programmes et propose des exemples de réparation de code pour faciliter la réparation des vulnérabilités.

Faites confiance à WeTest pour protéger votre application contre les menaces potentielles et maintenir une expérience utilisateur sécurisée.