Méthodologie
Dernière mise à jour
Cet article vous a-t-il été utile ?
Dernière mise à jour
Cet article vous a-t-il été utile ?
Recherche passive
Recherche active
Cartographie de la surface d'attaque
Etude du fonctionnement de l'application pour en comprendre la structure et les fonctions
Stockage
Déterminer si des données sensibles sont partagées via des notifications (Chercher tout usage de la classe NotificationManager)
Valider que le cache de clavier est désactivé dans les définitions d'activités (android:inputType="TextNoSuggestions")
Vérifier l'implémentation des bakups
Vérifier si android:allowBackup="true" dans AndroidManifest.xml (automatique sauf si explicitement désactivé depuis Android 6.0)
Déterminer comment sont fais les backups (Auto-Backup ou clés/valeur)
Vérifier si des règles de backup sont en place (backup_rules.xml)
Lister et analyser les occurences d'APIs et Permissions permettant de stocker des données sur des stockages externes (getExternalStoragePublicDirectory, getExternalStorageDirectory, getExternalFilesDir, MediaStore, WRITE_EXTERNAL_STORAGE, MANAGE_EXTERNAL_STORAGE)
Vérifier si une bdd externe firebase/appspot est utilisée
Analyser l'usage des APIs de Logging (Log, Logger, System.out.print, System.err.print, java.lang.Throwable#printStackTrace)
Crypto
Lister les classes, interfaces, fonctions et exceptions de cryptographie et rechercher toute mauvaise pratique liée à leur usage
Vérifier si des pseudorandom number generator (PRNG) sont utilisés pour protéger des données sensibles (java.util.Random par exemple)
Vérifier si d'autres méthodes de randomisation non sécurisées sont utilisées pour protéger des données sensibles tels que des token basés sur le temps etc (exp: Date().getTime(), calendar.MILLISECOND)
Valider la taille des clés de cryptographie (classes KeyGenerator et KeyPairGenerator)
Chercher des clés codées en dur (classe SecretKeySpec)
Déterminer si l'application utilise des algorithmes de chiffrement symétriques faibles (Cipher.getInstance, SecretKeyFactory.getInstance, KeyGenerator.getInstance)
Déterminer si l'application utilise des modes de chiffrement symétriques faibles (Cipher.getInstance)
Authentification
Si setUserAuthenticationRequired est utilisée, valider la durée pendant laquelle la clé est autorisée à être utilisée après une authentification réussie
Vérifier si l'application utilise des mécanismes d'authentification biométriques (vérifier dans les permissions de l'application)
Réseau
Vérifier si l'application utilise TrustManager et HostnameVerifier et valider s'ils sont correctement implémentés
Valider si des custom trust anchors sont utilisés
Vérifier si ils autorisent des communications en clair
Vérifier si ils autorisent les certificats utilisateur
Vérifier si le certificate pinning est configuré
Vérifier la date d'expiration des pins
Vérifier si les webviews ignorent les erreurs TLS
Vérifier si l'application valide l'hostname Si l'application est basée sur le SDK Android, alors vérifier que la classe ProviderInstaller est appelée avec soit installIfNeeded ou installIfNeededAsync
Vérifier la version TLS utilisée par l'application
Rechercher si des url http:// sont utilisées dans le code
Vérifier si le flag android:usesCleartextTraffic="true" est présent dans le fichier AndroidManifest.xml
Code
Rechercher les occurences d'intents contenant des actions système (android.intent.action.*)
Lister les intents implicites
Vérifier la présence de vulnérabilité selon les capacités de chacun d'entre eux
Vérifier la configuration du client WebViewClient
Rechercher les fonctions de callbacks shouldOverrideUrlLoading, shouldInterceptRequest
Vérifier si les WebViews sont autorisées à charger des pages suspicieuses
Vérifier si le flag EnableSafeBrowsing est actif dans le fichier AndroidManifest.xml
Vérifier si des CVE existes sur les versions des librairies tiers utilisées par l'application.
Vérifier que les flags de sécurité relatifs aux librairies natives sont actifs (PIC, stack canaries...)
Plateforme
Lister les content providers exportés
Déterminer si les données sont protégées par des permissions (android:permissions)
Déterminer si le android:protectionLevel à la valeur "signature"
Analyser comment sont utilisés les content providers dans le code
Vérifier si le flag FLAG_SECURE est utilisé
Lister les permissions de l'application
Vérifier comment les permissions sont utilisées dans le code
Vérifier si android:protectionLevel="normal" ou "dangerous" est utilisé
Lister les deeplinks de l'application dans le fichier AndroidManifest.xml
Identifier les services, activités, broadcast receivers etc exportés
Analyser le code lié à ces élements
Lister les PendingIntents Lister les WebViews interpretant le code JavaScript
Lister les WebViews utilisant un bridge natif
Lister les WebViews comportant des configurations potentiellement dangereuses
Lister les WebViews debuggables Vérifier le nettoyage des données liées aux WebViews
Vérifier que les URL ouvertes dans des WebViews ne peuvent pas être contrôlées complètement ou partiellement par les utilisateurs
Vérifier si l'application utilise des mécanismes anti-tapjacking
Résilience
Vérifier la présence de symboles de debugging
Vérifier la présence de code de debug
Vérifier la présence de mécanismes anti-root
Vérifier la présence de mécanismes anti-debug
Vérifier la présence de checks d'intégrité
Vérifier la présence de mécanismes anti-hooking/anti-reverse
Vérifier la présence de mécanismes anti-emulateur
Analyser le niveau d'obfuscation du code
Vérifier la version de signature de l'application
Vérifier le type de certificat avec lequel est signée l'application
Vérifier l'algoritme de signature de l'application
Vérifier la taille de la clé de chiffrement utilisée pour signer l'application
Stockage
Tracer les appels de fonctions relatives aux notifications (setContentTitle ou setContentText de NotificationCompat.Builder)
Regarder si le clavier fait des suggestions sur les champs sensibles
Faire un backup après installation de l'application puis après utilisation de l'application et vérifier qu'aucune donnée sensible ne fuite
Vérifier qu'aucune donnée sensible ne fuite dans la mémoire.
Prendre un snapshot des répértoires et fichiers externes avant et après usage de l'application puis les comparer pour vérifier la présence de données sensibles
Tracer les lectures/écritures dans les fichiers externes en temps réel
Prendre un snapshot des répértoires et fichiers internes avant et après usage de l'application puis les comparer pour vérifier la présence de données sensibles
Tracer les lectures/écritures dans les fichiers internes en temps réel
Vérifier les droits d'accès aux bdd firebase/appspot
Utiliser logcat pour analyser les logs en temps réel (rechercher la présence de toute donnée sensible)
Crypto
Tracer les méthodes de cryptographie avec frida et analyser les entrées/sorties, l'usage des clés de chiffrement, les protocoles utilisés etc.
Tracer les méthodes de randomisation avec frida
Authentification
Si l'application utilise la biométrie, tenter de la contourner avec des scripts frida.
Réseau
Vérifier si l'application autorise les certificats auto-signés avec Burp Suite
Vérifier si l'application autorise les certificats non trustés
Vérifier si l'application accepte les hostnames incorrectes
En cas de SSL Pinning, tenter de le contourner avec frida
Hook la fonction java.security.Security.getProviders() et déterminer si le premier provider est GmsCore_OpenSSL
Utiliser testssl.sh pour auditer les configurations TLS du/des domaine(s) utilisé(s) par l'application
Utiliser Wireshark pour vérifier la version de TLS utilisée par l'application
Utiliser Wireshark ou Burp Suite pour vérifier si des communications HTTP non chiffrées sont utilisées par l'application
Code
Tracer les méthodes startActivityForResult et onActivityResult et inspecter les intents et leurs données
Tracer les méthodes shouldOverrideUrlLoading, shouldInterceptRequest, getHost, getScheme, getPath et vérifier s'il existe des restrictions sur le chargement des pages web.
Vérifier si l'application est fonctionnelle sur des versions précédentes
Si oui, vérifier si l'utilisateur est alerté et si il est possible d'ignorer cette alerte
Rechercher des vulnérabilités de corruption de mémoire dans le code natif
Rechercher des vulnérabilités de corruption de mémoire dans le code Java/Kotlin
Plateforme
Vérifier s'il est possible d'accéder à des données sensibles depuis les content providers exportés
Chercher des SQLi dans les providers exportés
Chercher des path traversal dans les providers exportés
Vérifier si il est possible de manipuler les services exportés
Vérifier si il est possible de récupérer des informations sensibles au travers des broadcast receivers exportés
Vérifier si il est possible de contourner des mécanismes d'authentification au travers de forced browsing en utilisant les activités exportées
Vérifier si des données sensibles sont exposées depuis l'interface utilisateur de l'application
Vérifier si la vue de l'application est remplacée lorsque l'application est mise en arrière plan
Vérifier si les permissions listées sont utilisées ou non
Pour chaque deeplink relevé
Vérifier les fichiers Digital Asset Links
Si ils sont présents
Sur chaque sous-domaine s'il y en a
À la racine de l'hostname si un wildcard est utilisé
Si ils ne sont pas en HTTP Si ils ne sont pas syntaxiquement corrects
Si on y retrouve bien le nom du package audité
Si il n'y a pas de redirection
S'ils permettent d'ouvrir une WebView, vérifier que les deeplinks sont correctement traités
Tracer la fonction Intent.getData
Fuzzing
Analyser comment sont utilisées les WebViews dans l'application et vérifier si il est possible de les manipuler
Tenter de superposer une application malveillante au dessus de l'application cible et vérifier si les boutons sont toujours accessibles
Tester les attaques de type task hijacking / Standhogg
Auditer les lecteurs de QR code
Résilience
Ouvrir l'application avec un appareil rooté et vérifier le comportement de l'application au démarrage
Si l'application empêche le démarrage, tenter de bypasser la restriction avec frida
Ouvrir l'application avec un émulateur et vérifier le comportement de l'application au démarrage
Si l'application empêche le démarrage, tenter de bypasser la restriction avec frida
Vérifier si l'application détecte la présence d'outils de hooking/reverse
Si l'application empêche le démarrage, tenter de bypasser la restriction avec frida
Attacher un debugger à l'application et vérifier son comportement
Si l'application empêche l'action, tenter de bypasser la restriction avec frida
Ouvrir l'application avec un appareil sans mécanisme d'authentification et vérifier si elle fonctionne sans alerte ou protection particulière
Liste des niveaux de logs :
V = Verbose (lowest priority)
D = Debug
I = Info
W = Warning
E = Error
F = Fatal
S = Silent (highest priority)
Rédaction d'un rapport
Cette catégorie regroupe toutes les vulnérabilités liés à une mauvaise utilisation des fonctionnalités Android tels que les "intents", les permissions, le TouchID etc.
Stocker des données non chiffrées dans le stockage local de l'appareil est une mauvaise pratique, car il existe des applications malveillantes qui peuvent tenter d'en récupérer des informations sensibles. Les attaquants peuvent également récupérer directement les données d'un appareil volé.
Tout comme pour le pentest web, le chiffrement des communications est important pour éviter que des acteurs malveillants intercepte les informations transmises par l'application, celle-ci doit avoir mis en place une bonne protection sur données en transit.
Cette catégorie regroupe toutes les vulnérabilités liés à la sécurité du système d'authentification (Mot de passe faible / par défaut, bypass, politique de mot de passe faible et/ou contournable...)
Dans ce type de vulnérabilité on va retrouver toutes les données sensibles non chiffrés ou chiffrés avec des moyens obsolètes tels que le MD5 par exemple.
à ne pas confondre avec la vulnérabilité "Insecure authentication", les attaquants utilisent généralement des outils automatisés disponibles ou personnalisés pour se connecter à une application en tant qu'utilisateur légitime. Une fois connectés, ils peuvent effectuer des attaques binaires contre l'application mobile et essayer d'exécuter des fonctionnalités privilégiées qui ne devraient être exécutables qu'avec un utilisateur disposant de privilèges plus élevés lorsque l'application mobile est en mode "hors ligne".
Comme son nom l'indique, dans ce type de vulnérabilités se trouve tous les problèmes liés à l'usage de fonctions et méthodes vulnérables, déprécié(e)s ou aux mauvaises pratique de sécurité dans le code (pour résumé, le non respect du "security by design").
Dans ce type de vulnérabilités, les attaquants peuvent créer des applications malveillantes en modifiant le code source des applications existantes et en les hébergeant dans des magasins d'applications tiers. Les attaquants peuvent également fournir ces applications malveillantes modifiées à la victime en utilisant des techniques de phishing.
Les attaquants téléchargeront une application depuis l'App Store afin d'effectuer des techniques d'ingénierie inverse et d'analyse statique, à l'aide des outils disponibles. Cela leur permet de comprendre les fonctionnalités de l'application, de modifier le code et de le recompiler.
Pour ce type de vulnérabilités, les attaquant vont d'abord analyser le fonctionnement de l'application afin de découvrir des fonctionnalités en back-end qu'il vont directement cibler sans passer par l'application.