Applications Android Pentesting

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Concepts de base des applications Android

Il est fortement recommandé de commencer par lire cette page pour connaître les parties les plus importantes liées à la sécurité Android et les composants les plus dangereux dans une application Android :

Android Applications Basics

ADB (Android Debug Bridge)

C’est l’outil principal dont vous avez besoin pour vous connecter à un appareil android (émulé ou physique).
ADB permet de contrôler les appareils soit via USB soit via Network depuis un ordinateur. Cet utilitaire permet le copying de fichiers dans les deux sens, l’installation et la uninstallation d’apps, l’execution de commandes shell, la backing up des données, la reading des logs, parmi d’autres fonctions.

Consultez la liste suivante des ADB Commands pour apprendre à utiliser adb.

Smali

Parfois il est intéressant de modifier le code de l’application pour accéder à des informations cachées (peut-être des mots de passe bien obfusqués ou des flags). Dans ce cas, il peut être utile de décompiler l’apk, modifier le code et recompiler celui-ci.
In this tutorial you can learn how to decompile and APK, modify Smali code and recompile the APK with the new functionality. Cela peut être très utile comme alternative pour plusieurs tests durant l’analyse dynamique qui vont être présentés. Donc, gardez toujours à l’esprit cette possibilité.

Other interesting tricks

adb shell pm list packages
com.android.insecurebankv2

adb shell pm path com.android.insecurebankv2
package:/data/app/com.android.insecurebankv2-Jnf8pNgwy3QA_U5f-n_4jQ==/base.apk

adb pull /data/app/com.android.insecurebankv2-Jnf8pNgwy3QA_U5f-n_4jQ==/base.apk
  • Fusionner tous les splits et les apks de base avec APKEditor:
mkdir splits
adb shell pm path com.android.insecurebankv2 | cut -d ':' -f 2 | xargs -n1 -i adb pull {} splits
java -jar ../APKEditor.jar m -i splits/ -o merged.apk

# after merging, you will need to align and sign the apk, personally, I like to use the uberapksigner
java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed

Android Enterprise & Work Profile Attacks

Android Enterprise Work Profile Bypass

Études de cas & Vulnérabilités

Air Keyboard Remote Input Injection

Android Rooting Frameworks Manager Auth Bypass Syscall Hook

Abusing Android Media Pipelines Image Parsers

Arm64 Static Linear Map Kaslr Bypass

Analyse statique

First of all, for analysing an APK you should take a look to the to the Java code using a decompiler.
Please, read here to find information about different available decompilers.

Recherche d’informations intéressantes

Just taking a look to the strings of the APK you can search for passwords, URLs (https://github.com/ndelphit/apkurlgrep), api keys, encryption, bluetooth uuids, tokens and anything interesting… look even for code execution backdoors or authentication backdoors (hardcoded admin credentials to the app).

Firebase

Pay special attention to firebase URLs and check if it is bad configured. More information about whats is FIrebase and how to exploit it here.

Basic understanding of the application - Manifest.xml, strings.xml

The examination of an application’s Manifest.xml and strings.xml files can reveal potential security vulnerabilities. These files can be accessed using decompilers or by renaming the APK file extension to .zip and then unzipping it.

Vulnerabilities identified from the Manifest.xml include:

  • Debuggable Applications: Applications set as debuggable (debuggable="true") in the Manifest.xml file pose a risk as they allow connections that can lead to exploitation. For further understanding on how to exploit debuggable applications, refer to a tutorial on finding and exploiting debuggable applications on a device.
  • Backup Settings: The android:allowBackup="false" attribute should be explicitly set for applications dealing with sensitive information to prevent unauthorized data backups via adb, especially when usb debugging is enabled.
  • Network Security: Custom network security configurations (android:networkSecurityConfig="@xml/network_security_config") in res/xml/ can specify security details like certificate pins and HTTP traffic settings. An example is allowing HTTP traffic for specific domains.
  • Exported Activities and Services: Identifying exported activities and services in the manifest can highlight components that might be misused. Further analysis during dynamic testing can reveal how to exploit these components.
  • Content Providers and FileProviders: Exposed content providers could allow unauthorized access or modification of data. The configuration of FileProviders should also be scrutinized.
  • Broadcast Receivers and URL Schemes: These components could be leveraged for exploitation, with particular attention to how URL schemes are managed for input vulnerabilities.
  • SDK Versions: The minSdkVersion, targetSDKVersion, and maxSdkVersion attributes indicate the supported Android versions, highlighting the importance of not supporting outdated, vulnerable Android versions for security reasons.

From the strings.xml file, sensitive information such as API keys, custom schemas, and other developer notes can be discovered, underscoring the need for careful review of these resources.

Tapjacking

Tapjacking is an attack where a malicious application is launched and positions itself on top of a victim application. Once it visibly obscures the victim app, its user interface is designed in such a way as to trick the user to interact with it, while it is passing the interaction along to the victim app.
In effect, it is blinding the user from knowing they are actually performing actions on the victim app.

Find more information in:

Tapjacking

Task Hijacking

An activity with the launchMode set to singleTask without any taskAffinity defined is vulnerable to task Hijacking. This means, that an application can be installed and if launched before the real application it could hijack the task of the real application (so the user will be interacting with the malicious application thinking he is using the real one).

More info in:

Android Task Hijacking

Insecure data storage

Internal Storage

In Android, files stored in internal storage are designed to be accessible exclusively by the app that created them. This security measure is enforced by the Android operating system and is generally adequate for the security needs of most applications. However, developers sometimes utilize modes such as MODE_WORLD_READABLE and MODE_WORLD_WRITABLE to allow files to be shared between different applications. Yet, these modes do not restrict access to these files by other applications, including potentially malicious ones.

  1. Static Analysis:
  • Ensure that the use of MODE_WORLD_READABLE and MODE_WORLD_WRITABLE is carefully scrutinized. These modes can potentially expose files to unintended or unauthorized access.
  1. Dynamic Analysis:
  • Verify the permissions set on files created by the app. Specifically, check if any files are set to be readable or writable worldwide. This can pose a significant security risk, as it would allow any application installed on the device, regardless of its origin or intent, to read or modify these files.

External Storage

When dealing with files on external storage, such as SD Cards, certain precautions should be taken:

  1. Accessibility:
  • Files on external storage are globally readable and writable. This means any application or user can access these files.
  1. Security Concerns:
  • Given the ease of access, it’s advised not to store sensitive information on external storage.
  • External storage can be removed or accessed by any application, making it less secure.
  1. Handling Data from External Storage:
  • Always perform input validation on data retrieved from external storage. This is crucial because the data is from an untrusted source.
  • Storing executables or class files on external storage for dynamic loading is strongly discouraged.
  • If your application must retrieve executable files from external storage, ensure these files are signed and cryptographically verified before they are dynamically loaded. This step is vital for maintaining the security integrity of your application.

External storage can be accessed in /storage/emulated/0 , /sdcard , /mnt/sdcard

Tip

Starting with Android 4.4 (API 17), the SD card has a directory structure which limits access from an app to the directory which is specifically for that app. This prevents malicious application from gaining read or write access to another app’s files.

Sensitive data stored in clear-text

  • Shared preferences: Android allow to each application to easily save xml files in the path /data/data/<packagename>/shared_prefs/ and sometimes it’s possible to find sensitive information in clear-text in that folder.
  • Databases: Android allow to each application to easily save sqlite databases in the path /data/data/<packagename>/databases/ and sometimes it’s possible to find sensitive information in clear-text in that folder.

Broken TLS

Accept All Certificates

For some reason sometimes developers accept all the certificates even if for example the hostname does not match with lines of code like the following one:

SSLSocketFactory sf = new cc(trustStore);
sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

Une bonne façon de tester cela est d’essayer de capturer le trafic en utilisant un proxy comme Burp sans autoriser Burp CA à l’intérieur de l’appareil. Vous pouvez aussi générer avec Burp un certificat pour un nom d’hôte différent et l’utiliser.

Cryptographie défaillante

Processus de gestion des clés insuffisants

Certains développeurs sauvegardent des données sensibles dans le stockage local et les chiffrent avec une clé hardcodée/prédictible dans le code. Cela ne devrait pas être fait car du reversing pourrait permettre à des attaquants d’extraire l’information confidentielle.

Utilisation d’algorithmes non sécurisés et/ou obsolètes

Les développeurs ne devraient pas utiliser des algorithmes dépréciés pour effectuer des vérifications d’autorisation, stocker ou envoyer des données. Certains de ces algorithmes sont : RC4, MD4, MD5, SHA1… Si des hashes sont utilisés pour stocker des mots de passe par exemple, il faut utiliser des hashes résistants au brute-force avec du salt.

Autres vérifications

  • Il est recommandé d’obfusquer l’APK pour rendre le travail de reverse engineer plus difficile aux attaquants.
  • Si l’app est sensible (comme des applications bancaires), elle devrait effectuer ses propres vérifications pour détecter si le mobile est rooté et agir en conséquence.
  • Si l’app est sensible (comme des applications bancaires), elle devrait vérifier si un emulator est utilisé.
  • Si l’app est sensible (comme des applications bancaires), elle devrait vérifier son intégrité avant exécution pour confirmer qu’elle n’a pas été modifiée.
  • Utilisez APKiD pour vérifier quel compiler/packer/obfuscator a été utilisé pour construire l’APK

React Native Application

Lisez la page suivante pour apprendre comment accéder facilement au code javascript des applications React :

React Native Application

Xamarin Applications

Lisez la page suivante pour apprendre comment accéder facilement au code C# d’une application xamarin :

Xamarin Apps

Superpacked Applications

Selon ce blog post superpacked est un algorithme Meta qui compresse le contenu d’une application en un seul fichier. Le blog parle de la possibilité de créer une app qui décompresse ce type d’apps… et d’une manière plus rapide qui consiste à exécuter l’application et récupérer les fichiers décompressés depuis le filesystem.

Automated Static Code Analysis

L’outil mariana-trench est capable de trouver des vulnerabilities en scannant le code de l’application. Cet outil contient une série de known sources (qui indique à l’outil les endroits où l’input est contrôlé par l’utilisateur), sinks (qui indique à l’outil les endroits dangereux où une input malveillante pourrait causer des dégâts) et des rules. Ces rules indiquent la combinaison de sources-sinks qui signale une vulnérabilité.

Avec cette connaissance, mariana-trench passera en revue le code et trouvera d’éventuelles vulnérabilités.

Secrets leaked

Une application peut contenir des secrets (API keys, mots de passe, urls cachées, sous-domaines…) à l’intérieur qu’il est possible de découvrir. Vous pouvez utiliser un outil tel que https://github.com/dwisiswant0/apkleaks

Bypass Biometric Authentication

Bypass Biometric Authentication (Android)

Autres fonctions intéressantes

  • Code execution: Runtime.exec(), ProcessBuilder(), native code:system()
  • Send SMSs: sendTextMessage, sendMultipartTestMessage
  • Native functions déclarées comme native: public native, System.loadLibrary, System.load
  • Read this to learn how to reverse native functions
  • In-memory native code execution via JNI (downloaded shellcode → mmap/mprotect → call):

In Memory Jni Shellcode Execution

Other tricks

content:// protocol

Dynamic Analysis

Tout d’abord, vous avez besoin d’un environnement où vous pouvez installer l’application et tous les éléments de l’environnement (Burp CA cert, Drozer et Frida principalement). Par conséquent, un appareil rooté (émulé ou non) est fortement recommandé.

Online Dynamic analysis

Vous pouvez créer un compte gratuit sur : https://appetize.io/. Cette plateforme permet de uploader et exécuter des APKs, ce qui est utile pour voir comment un apk se comporte.

Vous pouvez même voir les logs de votre application sur le web et vous connecter via adb.

Grâce à la connexion ADB vous pouvez utiliser Drozer et Frida à l’intérieur des emulators.

Local Dynamic Analysis

Using an emulator

  • Android Studio (Vous pouvez créer des devices x86 et arm, et d’après this les dernières versions x86 prennent en charge les bibliothèques ARM sans nécessiter un emulator arm lent).
  • Apprenez à le configurer sur cette page :

AVD - Android Virtual Device

  • Genymotion (version gratuite : Personal Edition, vous devez créer un compte. Il est recommandé de télécharger la version AVEC VirtualBox pour éviter des erreurs potentielles.)
  • Nox (Gratuit, mais il ne supporte pas Frida ou Drozer).

Tip

Lors de la création d’un nouvel emulator sur n’importe quelle plateforme, rappelez-vous que plus l’écran est grand, plus l’emulator sera lent. Choisissez donc des écrans petits si possible.

Pour installer les services google (comme AppStore) dans Genymotion, vous devez cliquer sur le bouton marqué en rouge de l’image suivante :

Notez aussi que dans la configuration de la Android VM dans Genymotion vous pouvez sélectionner le Bridge Network mode (cela sera utile si vous vous connectez à la Android VM depuis une VM différente avec les outils).

Use a physical device

Vous devez activer les options de debugging et il est préférable que vous puissiez le rooter :

  1. Settings.
  2. (Depuis Android 8.0) Sélectionnez System.
  3. Sélectionnez About phone.
  4. Appuyez sur Build number 7 fois.
  5. Revenez en arrière et vous trouverez les Developer options.

Une fois que vous avez installé l’application, la première chose à faire est de l’essayer, d’étudier ce qu’elle fait, comment elle fonctionne et de vous familiariser avec elle.
Je suggère d’effectuer cette analyse dynamique initiale en utilisant MobSF dynamic analysis + pidcat, ainsi nous pourrons apprendre le fonctionnement de l’application pendant que MobSF capture beaucoup de données intéressantes que vous pourrez consulter ultérieurement.

Magisk/Zygisk quick notes (recommandé sur les appareils Pixel)

  • Patch du boot.img avec l’application Magisk et flash via fastboot pour obtenir un root systemless
  • Activez Zygisk + DenyList pour cacher le root ; envisagez LSPosed/Shamiko pour un masquage plus poussé
  • Conservez le boot.img original pour récupérer après les OTA ; ré-patchez après chaque OTA
  • Pour le mirroring d’écran, utilisez scrcpy sur l’hôte

Unintended Data Leakage

Logging

Les développeurs doivent être prudents quant à l’exposition d’informations de debugging publiquement, car cela peut conduire à des sensitive data leaks. Les outils pidcat et adb logcat sont recommandés pour surveiller les logs des applications afin d’identifier et protéger les informations sensibles. Pidcat est préféré pour sa facilité d’utilisation et sa lisibilité.

Warning

Notez que depuis les versions postérieures à Android 4.0, les applications ne peuvent accéder qu’à leurs propres logs. Les applications ne peuvent donc pas accéder aux logs des autres apps.
Quoi qu’il en soit, il est toujours recommandé de ne pas logger d’informations sensibles.

Copy/Paste Buffer Caching

Le framework clipboard-based d’Android permet les fonctionnalités de copier-coller dans les apps, mais présente un risque car d’autres applications peuvent accéder au clipboard, exposant potentiellement des données sensibles. Il est crucial de désactiver les fonctions de copy/paste pour les sections sensibles d’une application, comme les détails de carte de crédit, afin d’éviter des data leaks.

Crash Logs

Si une application crashe et sauvegarde des logs, ces logs peuvent aider des attaquants, en particulier lorsque l’application ne peut pas être reverse-engineered. Pour atténuer ce risque, évitez de logger lors de crashes, et si des logs doivent être transmis sur le réseau, assurez-vous qu’ils le soient via un canal SSL pour la sécurité.

En tant que pentester, essayez de consulter ces logs.

Analytics Data Sent To 3rd Parties

Les applications intègrent souvent des services comme Google Adsense, ce qui peut involontairement leak des données sensibles en raison d’une mauvaise implémentation par les développeurs. Pour identifier d’éventuels leaks de données, il est conseillé d’intercepter le trafic de l’application et de vérifier si des informations sensibles sont envoyées à des services tiers.

SQLite DBs

La plupart des applications utiliseront des bases de données SQLite internes pour sauvegarder des informations. Pendant le pentest, jetez un coup d’œil aux databases créées, aux noms des tables et colonnes et à toutes les données stockées car vous pourriez trouver des informations sensibles (ce qui constituerait une vulnérabilité).
Les bases de données devraient se trouver dans /data/data/the.package.name/databases comme /data/data/com.mwr.example.sieve/databases

Si la base de données sauvegarde des informations confidentielles et est encrypted mais que vous pouvez trouver le password dans l’application, c’est toujours une vulnérabilité.

Enumérez les tables en utilisant .tables et énumérez les colonnes des tables avec .schema <table_name>

Drozer (Exploit Activities, Content Providers and Services)

From Drozer Docs: Drozer allows you to assume the role of an Android app and interact with other apps. It can do anything that an installed application can do, such as make use of Android’s Inter-Process Communication (IPC) mechanism and interact with the underlying operating system. .
Drozer est un outil utile pour exploiter exported activities, exported services and Content Providers comme vous l’apprendrez dans les sections suivantes.

Exploiting exported Activities

Read this if you want to refresh what is an Android Activity.
Rappelez-vous aussi que le code d’une activity commence dans la méthode onCreate.

Authorisation bypass

Quand une Activity est exportée, vous pouvez invoquer son écran depuis une application externe. Donc, si une activity contenant des informations sensibles est exported vous pourriez bypass les mécanismes d’authentication pour y accéder.

Learn how to exploit exported activities with Drozer.

Vous pouvez aussi démarrer une activity exportée depuis adb :

  • PackageName is com.example.demo
  • Exported ActivityName is com.example.test.MainActivity
adb shell am start -n com.example.demo/com.example.test.MainActivity

NOTE: MobSF will detect as malicious the use of singleTask/singleInstance as android:launchMode in an activity, but due to this, apparently this is only dangerous on old versions (API versions < 21).

Tip

Notez qu’un authorisation bypass n’est pas toujours une vulnerability : cela dépendra de la manière dont le bypass fonctionne et des informations qui sont exposées.

Fuite d’informations sensibles

Activities can also return results. Si vous parvenez à trouver une activity exportée et non protégée appelant la méthode setResult et retournant des informations sensibles, il y a une fuite d’informations sensibles.

Tapjacking

Si le tapjacking n’est pas empêché, vous pourriez abuser de l’activity exportée pour faire en sorte que l’utilisateur effectue des actions inattendues. Pour plus d’infos sur what is Tapjacking follow the link.

Exploiting Content Providers - Accessing and manipulating sensitive information

Read this if you want to refresh what is a Content Provider.
Les Content Providers sont essentiellement utilisés pour partager des données. Si une app expose des Content Providers, vous pourriez être capable d’extraire des données sensibles depuis ceux-ci. Il est également intéressant de tester d’éventuelles SQL injections et Path Traversals, car elles pourraient être vulnérables.

Learn how to exploit Content Providers with Drozer.

Exploiting Services

Read this if you want to refresh what is a Service.
Rappelez-vous que les actions d’un Service commencent dans la méthode onStartCommand.

Un Service est essentiellement quelque chose qui peut recevoir des données, les traiter et retourner (ou non) une réponse. Donc, si une application exporte des services, vous devriez vérifier le code pour comprendre ce qu’il fait et le tester dynamiquement afin d’extraire des informations confidentielles, contourner les mesures d’authentification…
Learn how to exploit Services with Drozer.

Exploiting Broadcast Receivers

Read this if you want to refresh what is a Broadcast Receiver.
Rappelez-vous que les actions d’un Broadcast Receiver commencent dans la méthode onReceive.

Un Broadcast Receiver attendra un type de message. Selon la façon dont le receiver traite le message, il pourrait être vulnérable.
Learn how to exploit Broadcast Receivers with Drozer.

Exploiting Schemes / Deep links

Vous pouvez rechercher des deep links manuellement, en utilisant des outils comme MobSF ou des scripts comme this one.
Vous pouvez ouvrir un scheme déclaré en utilisant adb ou un browser :

adb shell am start -a android.intent.action.VIEW -d "scheme://hostname/path?param=value" [your.package.name]

Notez que vous pouvez omettre le nom du package et que l’appareil mobile appellera automatiquement l’application censée ouvrir ce lien.

<!-- Browser regular link -->
<a href="scheme://hostname/path?param=value">Click me</a>
<!-- fallback in your url you could try the intent url -->
<a href="intent://hostname#Intent;scheme=scheme;package=your.package.name;S.browser_fallback_url=http%3A%2F%2Fwww.example.com;end">with alternative</a>

Code exécuté

Pour trouver le code qui sera exécuté dans l’application, allez à l’activity appelée par le deeplink et cherchez la fonction onNewIntent.

Infos sensibles

Chaque fois que vous trouvez un deeplink, vérifiez que il ne reçoit pas de données sensibles (comme des mots de passe) via les paramètres de l’URL, car n’importe quelle autre application pourrait usurper le deeplink et voler ces données !

Paramètres dans le chemin (path)

Vous devez aussi vérifier si un deeplink utilise un paramètre à l’intérieur du chemin de l’URL comme: https://api.example.com/v1/users/{username}, dans ce cas vous pouvez forcer une path traversal en accédant à quelque chose comme: example://app/users?username=../../unwanted-endpoint%3fparam=value.
Notez que si vous trouvez les endpoints corrects à l’intérieur de l’application, vous pourriez provoquer un Open Redirect (si une partie du chemin est utilisée comme nom de domaine), un account takeover (si vous pouvez modifier les détails des utilisateurs sans token CSRF et que l’endpoint vulnérable utilisait la méthode correcte) et toute autre vuln. More info about this here.

Plus d’exemples

An interesting bug bounty report about links (/.well-known/assetlinks.json).

Inspection de la couche de transport et échecs de vérification

  • Les certificats ne sont pas toujours correctement vérifiés par les applications Android. Il est courant que ces applications ignorent les avertissements et acceptent des certificats self-signed ou, dans certains cas, reviennent à des connexions HTTP.
  • Les négociations pendant la poignée de main SSL/TLS sont parfois faibles, utilisant des suites de chiffrement non sécurisées. Cette vulnérabilité rend la connexion susceptible aux attaques man-in-the-middle (MITM), permettant aux attaquants de déchiffrer les données.
  • Leakage of private information est un risque lorsque les applications s’authentifient via des canaux sécurisés mais communiquent ensuite sur des canaux non sécurisés pour d’autres transactions. Cette approche ne protège pas les données sensibles, telles que les cookies de session ou les informations utilisateur, contre l’interception par des entités malveillantes.

Vérification des certificats

Nous nous concentrerons sur la vérification des certificats. L’intégrité du certificat du serveur doit être vérifiée pour renforcer la sécurité. C’est crucial car des configurations TLS non sécurisées et la transmission de données sensibles sur des canaux non chiffrés peuvent représenter des risques importants. Pour des étapes détaillées sur la vérification des certificats serveur et la correction des vulnérabilités, this resource provides comprehensive guidance.

SSL Pinning

SSL Pinning est une mesure de sécurité où l’application vérifie le certificat du serveur par rapport à une copie connue stockée dans l’application elle-même. Cette méthode est essentielle pour prévenir les attaques MITM. Mettre en place SSL Pinning est fortement recommandé pour les applications traitant des informations sensibles.

Inspection du trafic

Pour inspecter le trafic HTTP, il est nécessaire d’installer le certificat de l’outil proxy (e.g., Burp). Sans installer ce certificat, le trafic chiffré pourrait ne pas être visible via le proxy. For a guide on installing a custom CA certificate, click here.

Les applications ciblant API Level 24 and above nécessitent des modifications du Network Security Config pour accepter le certificat CA du proxy. Cette étape est cruciale pour inspecter le trafic chiffré. For instructions on modifying the Network Security Config, refer to this tutorial.

Si Flutter est utilisé, vous devez suivre les instructions dans this page. Ceci est dû au fait que simplement ajouter le certificat dans le store ne fonctionnera pas, puisque Flutter a sa propre liste de CAs valides.

Détection statique du SSL/TLS pinning

Avant d’essayer des bypasss runtime, cartographiez rapidement où le pinning est appliqué dans l’APK. La découverte statique vous aide à planifier les hooks/patchs et à vous concentrer sur les bons chemins de code.

Tool: SSLPinDetect

  • Utilitaire d’analyse statique open-source qui décompile l’APK en Smali (via apktool) et scanne des patterns regex sélectionnés d’implémentations de SSL/TLS pinning.
  • Rapporte le chemin de fichier exact, le numéro de ligne et un extrait de code pour chaque correspondance.
  • Couvre les frameworks courants et les chemins de code custom : OkHttp CertificatePinner, custom javax.net.ssl.X509TrustManager.checkServerTrusted, SSLContext.init with custom TrustManagers/KeyManagers, and Network Security Config XML pins.

Installation

  • Prérequis : Python >= 3.8, Java on PATH, apktool
git clone https://github.com/aancw/SSLPinDetect
cd SSLPinDetect
pip install -r requirements.txt

Utilisation

# Basic
python sslpindetect.py -f app.apk -a apktool.jar

# Verbose (timings + per-match path:line + snippet)
python sslpindetect.py -a apktool_2.11.0.jar -f sample/app-release.apk -v

Exemple de règles de pattern (JSON) Utilisez ou étendez des signatures pour détecter des styles de pinning propriétaires/personnalisés. Vous pouvez charger votre propre JSON et analyser à grande échelle.

{
"OkHttp Certificate Pinning": [
"Lcom/squareup/okhttp/CertificatePinner;",
"Lokhttp3/CertificatePinner;",
"setCertificatePinner"
],
"TrustManager Override": [
"Ljavax/net/ssl/X509TrustManager;",
"checkServerTrusted"
]
}

Notes and tips

  • Fast scanning on large apps via multi-threading and memory-mapped I/O; les regex pré-compilées réduisent la charge / les faux positifs.
  • Pattern collection: https://github.com/aancw/smali-sslpin-patterns
  • Typical detection targets to triage next :
  • OkHttp: utilisation de CertificatePinner, setCertificatePinner, références au package okhttp3/okhttp
  • Custom TrustManagers: javax.net.ssl.X509TrustManager, redéfinitions de checkServerTrusted
  • Custom SSL contexts: SSLContext.getInstance + SSLContext.init avec des managers personnalisés
  • Declarative pins in res/xml network security config et références dans le manifest
  • Utilisez les emplacements correspondants pour planifier des Frida hooks, des patchs statiques ou des revues de config avant les tests dynamiques.

Bypassing SSL Pinning

When SSL Pinning is implemented, bypassing it becomes necessary to inspect HTTPS traffic. Various methods are available for this purpose:

Looking for Common Web Vulnerabilities

Il est important de rechercher également les vulnérabilités web courantes au sein de l’application. Des informations détaillées sur l’identification et l’atténuation de ces vulnérabilités dépassent le cadre de ce résumé mais sont largement couvertes ailleurs.

Frida

Frida est une boîte à outils d’instrumentation dynamique pour développeurs, reverse-engineers et chercheurs en sécurité.
Vous pouvez accéder à une application en cours d’exécution et hooker des méthodes à l’exécution pour changer le comportement, modifier des valeurs, extraire des valeurs, exécuter du code différent…
Si vous voulez pentest des applications Android vous devez savoir comment utiliser Frida.

Anti-instrumentation & SSL pinning bypass workflow

Android Anti Instrumentation And Ssl Pinning Bypass

Dump Memory - Fridump

Vérifiez si l’application stocke des informations sensibles en mémoire qu’elle ne devrait pas stocker, comme des passwords ou des mnemonics.

Using Fridump3 you can dump the memory of the app with:

# With PID
python3 fridump3.py -u <PID>

# With name
frida-ps -Uai
python3 fridump3.py -u "<Name>"

Cela va dump la mémoire dans le dossier ./dump, et vous pouvez y utiliser grep avec quelque chose comme :

strings * | grep -E "^[a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+$"

Données sensibles dans Keystore

Dans Android le Keystore est le meilleur endroit pour stocker des données sensibles, cependant, avec des privilèges suffisants il est toujours possible d’y accéder. Comme les applications ont tendance à stocker ici des données sensibles en clair, les pentests doivent vérifier cela car un utilisateur root ou quelqu’un ayant un accès physique à l’appareil pourrait être en mesure de voler ces données.

Même si une app stocke des données dans le keystore, les données devraient être chiffrées.

To access the data inside the keystore you could use this Frida script: https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js

frida -U -f com.example.app -l frida-scripts/tracer-cipher.js

Fingerprint/Biometrics Bypass

En utilisant le Frida script suivant, il pourrait être possible de bypass fingerprint authentication que des applications Android utilisent pour protéger certaines zones sensibles :

frida --codeshare krapgras/android-biometric-bypass-update-android-11 -U -f <app.package>

Background Images

Lorsque vous mettez une application en arrière-plan, Android stocke un snapshot of the application afin que, lorsqu’elle est ramenée au premier plan, il commence à charger l’image avant l’application pour que cela ait l’air d’avoir chargé plus rapidement.

Cependant, si ce snapshot contient des informations sensibles, quelqu’un ayant accès au snapshot pourrait voler ces informations (notez que vous avez besoin du root pour y accéder).

Les snapshots sont généralement stockés dans : /data/system_ce/0/snapshots

Android fournit un moyen de prevent the screenshot capture by setting the FLAG_SECURE en tant que paramètre de layout. En utilisant ce flag, le contenu de la fenêtre est traité comme sécurisé, empêchant son apparition dans les captures d’écran ou son affichage sur des écrans non sécurisés.

getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);

Analyseur d’applications Android

Cet outil peut vous aider à gérer différents outils pendant l’analyse dynamique : https://github.com/NotSoSecure/android_application_analyzer

Intent Injection

Les développeurs créent souvent des composants proxy comme activities, services et broadcast receivers qui gèrent ces Intents et les transmettent à des méthodes telles que startActivity(...) ou sendBroadcast(...), ce qui peut être risqué.

Le danger vient du fait de permettre à des attaquants de déclencher des composants d’application non exportés ou d’accéder à des content providers sensibles en détournant ces Intents. Un exemple notable est le composant WebView convertissant des URL en objets Intent via Intent.parseUri(...) puis les exécutant, pouvant mener à des injections d’Intent malveillantes.

Essential Takeaways

  • Intent Injection est similaire au problème Open Redirect du web.
  • Les exploitations consistent à passer des objets Intent comme extras, lesquels peuvent être redirigés pour exécuter des opérations non sécurisées.
  • Cela peut exposer des composants non exportés et des content providers aux attaquants.
  • La conversion d’URL en Intent par WebView peut faciliter des actions non souhaitées.

Android Client Side Injections and others

Vous connaissez probablement ce type de vulnérabilités depuis le Web. Il faut être particulièrement prudent avec ces vulnérabilités dans une application Android :

  • SQL Injection: Lors de l’utilisation de requêtes dynamiques ou de Content-Providers, assurez-vous d’utiliser des requêtes paramétrées.
  • JavaScript Injection (XSS): Vérifiez que le support JavaScript et les Plugins sont désactivés pour tout WebView (désactivé par défaut). More info here.
  • Local File Inclusion: Les WebViews devraient avoir l’accès au système de fichiers désactivé (activé par défaut) - (webview.getSettings().setAllowFileAccess(false);). More info here.
  • Eternal cookies : Dans plusieurs cas, lorsqu’une application Android termine la session, le cookie n’est pas révoqué ou peut même être enregistré sur le disque.
  • Secure Flag in cookies

Analyse automatique

MobSF

Analyse statique

Évaluation des vulnérabilités de l’application via une interface web agréable. Vous pouvez également effectuer une analyse dynamique (mais vous devez préparer l’environnement).

docker pull opensecurity/mobile-security-framework-mobsf
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

Remarquez que MobSF peut analyser Android(apk), IOS(ipa) and Windows(apx) applications (Windows applications must be analyzed from a MobSF installed in a Windows host).
De plus, si vous créez un fichier ZIP avec le code source d’une application Android ou IOS (allez au dossier racine de l’application, sélectionnez tout et créez un ZIPfile), il pourra également l’analyser.

MobSF permet aussi de diff/Compare les analyses et de s’intégrer avec VirusTotal (vous devrez définir votre clé API dans MobSF/settings.py et l’activer : VT_ENABLED = TRUE VT_API_KEY = <Your API key> VT_UPLOAD = TRUE). Vous pouvez aussi mettre VT_UPLOAD sur False, alors le hash sera upload au lieu du fichier.

Assisted Dynamic analysis with MobSF

MobSF peut aussi être très utile pour l’dynamic analysis sur Android, mais dans ce cas vous devrez installer MobSF et genymotion sur votre hôte (une VM ou Docker ne fonctionneront pas). Note: You need to start first a VM in genymotion and then MobSF.
L’analyse dynamique de MobSF peut :

  • Dump application data (URLs, logs, clipboard, screenshots made by you, screenshots made by “Exported Activity Tester”, emails, SQLite databases, XML files, and other created files). Tout cela est fait automatiquement sauf pour les captures d’écran : vous devez appuyer quand vous voulez une capture d’écran ou appuyer sur “Exported Activity Tester” pour obtenir des captures de toutes les activités exportées.
  • Capturer le trafic HTTPS
  • Utiliser Frida pour obtenir des runtime information

À partir des versions Android > 5, il automatically start Frida et configurera les paramètres globaux de proxy pour capture le trafic. Il ne capturera que le trafic de l’application testée.

Frida

Par défaut, il utilisera aussi certains Frida Scripts pour bypass SSL pinning, root detection et debugger detection et pour monitor interesting APIs.
MobSF peut aussi invoke exported activities, grab screenshots of them et les save pour le rapport.

Pour start le test dynamique, appuyez sur le bouton vert : “Start Instrumentation”. Appuyez sur “Frida Live Logs” pour voir les logs générés par les Frida scripts et sur “Live API Monitor” pour voir toutes les invocation to hooked methods, arguments passed and returned values (cela apparaîtra après avoir appuyé sur “Start Instrumentation”).
MobSF permet aussi de charger vos propres Frida scripts (pour envoyer les résultats de vos scripts Frida à MobSF utilisez la fonction send()). Il propose également several pre-written scripts que vous pouvez charger (vous pouvez en ajouter d’autres dans MobSF/DynamicAnalyzer/tools/frida_scripts/others/), il suffit de les sélectionner, appuyer sur “Load” puis sur “Start Instrumentation” (vous pourrez voir les logs de ces scripts dans “Frida Live Logs”).

De plus, vous disposez de certaines fonctionnalités auxiliaires Frida :

  • Enumerate Loaded Classes: Il affichera toutes les classes chargées
  • Capture Strings: Il affichera toutes les capture strings pendant l’utilisation de l’application (très verbeux)
  • Capture String Comparisons: Peut être très utile. Il montrera les 2 strings being compared et si le résultat était True ou False.
  • Enumerate Class Methods: Indiquez le nom de la classe (comme “java.io.File”) et il affichera toutes les méthodes de la classe.
  • Search Class Pattern: Recherche des classes par pattern
  • Trace Class Methods: Trace une whole class (voir les inputs et outputs de toutes les méthodes de la classe). Rappelez-vous que par défaut MobSF trace plusieurs méthodes intéressantes de l’Android API.

Une fois que vous avez sélectionné le module auxiliaire que vous souhaitez utiliser, vous devez appuyer sur “Start Instrumentation” et vous verrez toutes les sorties dans “Frida Live Logs”.

Shell

MobSF propose également un shell avec quelques commandes adb, MobSF commands, et commandes courantes de shell en bas de la page d’analyse dynamique. Quelques commandes intéressantes :

help
shell ls
activities
exported_activities
services
receivers

HTTP tools

When http traffic is capture you can see an ugly view of the captured traffic on “HTTP(S) Traffic” bottom or a nicer view in “Start HTTPTools” green bottom. From the second option, you can send the captured requests to proxies like Burp or Owasp ZAP.
To do so, power on Burp –> turn off Intercept –> in MobSB HTTPTools select the request –> press “Send to Fuzzer” –> select the proxy address (http://127.0.0.1:8080\).

Once you finish the dynamic analysis with MobSF you can press on “Start Web API Fuzzer” to fuzz http requests an look for vulnerabilities.

Tip

After performing a dynamic analysis with MobSF the proxy settings me be misconfigured and you won’t be able to fix them from the GUI. You can fix the proxy settings by doing:

adb shell settings put global http_proxy :0

Assisted Dynamic Analysis with Inspeckage

You can get the tool from Inspeckage.
This tool with use some Hooks to let you know what is happening in the application while you perform a dynamic analysis.

Yaazhini

This is a great tool to perform static analysis with a GUI

Qark

This tool is designed to look for several security related Android application vulnerabilities, either in source code or packaged APKs. The tool is also capable of creating a “Proof-of-Concept” deployable APK and ADB commands, to exploit some of the found vulnerabilities (Exposed activities, intents, tapjacking…). As with Drozer, there is no need to root the test device.

pip3 install --user qark  # --user is only needed if not using a virtualenv
qark --apk path/to/my.apk
qark --java path/to/parent/java/folder
qark --java path/to/specific/java/file.java

ReverseAPK

  • Affiche tous les fichiers extraits pour une consultation facile
  • Décompile automatiquement les fichiers APK en Java et Smali
  • Analyse AndroidManifest.xml pour détecter les vulnérabilités et comportements courants
  • Analyse statique du code source pour détecter les vulnérabilités et comportements courants
  • Informations sur l’appareil
  • et plus encore
reverse-apk relative/path/to/APP.apk

SUPER Android Analyzer

SUPER est une application en ligne de commande utilisable sous Windows, MacOS X et Linux, qui analyse les fichiers .apk à la recherche de vulnérabilités. Elle procède en décompressant les APKs et en appliquant une série de règles pour détecter ces vulnérabilités.

Toutes les règles sont centralisées dans un fichier rules.json ; chaque entreprise ou testeur peut créer ses propres règles pour analyser ce dont il a besoin.

Téléchargez les derniers binaires depuis la download page

super-analyzer {apk_file}

StaCoAn

StaCoAn est un outil crossplatform qui aide les développeurs, bugbounty hunters et ethical hackers à effectuer des static code analysis sur des applications mobiles.

Le principe est que vous glissez-déposez le fichier de votre application mobile (un fichier .apk ou .ipa) sur l’application StaCoAn, et il générera pour vous un rapport visuel et portable. Vous pouvez ajuster les paramètres et les wordlists pour obtenir une expérience personnalisée.

Télécharger latest release:

./stacoan

AndroBugs

AndroBugs Framework est un système d’analyse de vulnérabilités Android qui aide les développeurs ou hackers à trouver des vulnérabilités de sécurité potentielles dans les applications Android.
Windows releases

python androbugs.py -f [APK file]
androbugs.exe -f [APK file]

Androwarn

Androwarn est un outil dont le but principal est de détecter et d’alerter l’utilisateur sur les comportements potentiellement malveillants développés par une application Android.

La détection est effectuée avec l’analyse statique du bytecode Dalvik de l’application, représenté en Smali, avec la bibliothèque androguard.

Cet outil recherche les comportements courants des applications “malveillantes” tels que : Telephony identifiers exfiltration, Audio/video flow interception, PIM data modification, Arbitrary code execution…

python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3

MARA Framework

MARA est un framework d’ingénierie inverse et d’analyse d’applications mobiles. C’est un outil qui regroupe des outils couramment utilisés pour l’ingénierie inverse et l’analyse d’applications mobiles, afin d’aider à tester les applications mobiles contre les menaces de sécurité mobile d’OWASP. Son objectif est de faciliter cette tâche et de la rendre plus accessible aux développeurs d’applications mobiles et aux professionnels de la sécurité.

Il permet de :

Koodous

Utile pour détecter les malware : https://koodous.com/

Obfuscating/Deobfuscating code

Notez qu’en fonction du service et de la configuration utilisés pour obfusquer le code, les secrets peuvent être, ou non, effectivement obfusqués.

ProGuard

D’après Wikipedia: ProGuard est un outil en ligne de commande open source qui réduit, optimise et obfusque le code Java. Il peut optimiser le bytecode ainsi que détecter et supprimer les instructions inutilisées. ProGuard est un logiciel libre et est distribué sous la GNU General Public License, version 2.

ProGuard est distribué en tant que composant du Android SDK et s’exécute lors de la compilation de l’application en mode release.

DexGuard

Trouvez un guide étape par étape pour déobfusquer l’apk sur https://blog.lexfo.fr/dexguard.html

(D’après ce guide) La dernière fois que nous avons vérifié, le mode de fonctionnement de Dexguard était :

  • charger une ressource en tant qu’InputStream;
  • fournir le résultat à une classe héritant de FilterInputStream pour le décrypter;
  • effectuer une obfuscation inutile pour faire perdre quelques minutes à un analyste en reverse engineering;
  • passer le résultat décrypté à un ZipInputStream pour obtenir un fichier DEX;
  • finalement charger le DEX obtenu en tant que Resource en utilisant la méthode loadDex.

DeGuard

DeGuard inverse le processus d’obfuscation appliqué par les outils d’obfuscation Android. Cela permet de réaliser de nombreuses analyses de sécurité, y compris l’inspection du code et l’identification prédictive des bibliothèques.

Vous pouvez téléverser un APK obfusqué sur leur plateforme.

[Deobfuscate android App]https://github.com/In3tinct/deobfuscate-android-app

C’est un outil LLM pour trouver d’éventuelles vulnérabilités de sécurité dans les applications Android et déobfusquer le code d’applications Android. Utilise l’API publique Gemini de Google.

Simplify

C’est un déobfuscateur Android générique. Simplify exécute virtuellement une application pour comprendre son comportement puis tente d’optimiser le code afin qu’il se comporte de manière identique mais soit plus facile à comprendre pour un humain. Chaque type d’optimisation est simple et générique, donc le type spécifique d’obfuscation utilisé n’a pas d’importance.

APKiD

APKiD vous donne des informations sur comment un APK a été créé. Il identifie de nombreux compilers, packers, obfuscators, et d’autres trucs bizarres. C’est le [PEiD] pour Android.

Manual

Read this tutorial to learn some tricks on how to reverse custom obfuscation

Labs

Androl4b

AndroL4b est une machine virtuelle de sécurité Android basée sur ubuntu-mate, incluant une collection des derniers frameworks, tutoriels et labs provenant de différents passionnés et chercheurs en sécurité pour le reverse engineering et l’analyse de malware.

References

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks