👾Méthodologie

Mindmaps

• https://xmind.app/m/GkgaYH/

• https://www.mindmeister.com/fr/map/1491593727/android-pentesting?fullscreen=1&v=public

Collecte d'informations

• Recherche passive

• Recherche active

• Cartographie de la surface d'attaque

Ingénierie inverse

Etude du fonctionnement de l'application pour en comprendre la structure et les fonctions

Analyse statique

Catégorie	Checklist
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

Analyse dynamique

Catégorie	Checklist
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

Vérification des logs avec logcat

Liste des niveaux de logs :

• V = Verbose (lowest priority)

• D = Debug

• I = Info

• W = Warning

• E = Error

• F = Fatal

• S = Silent (highest priority)

Rapport

Rédaction d'un rapport

Top 10 OWASP

Improper platform usage

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.

Insecure data storage

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é.

Insecure communication

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.

Insecure authentication

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...)

Insufficent cryptography

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.

Insecure authorization

à 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".

Poor code quality

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").

Code tampering

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.

Reverse engineering

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.

Extraneous functionnality

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.