56 KiB
Pentesting des applications Android
{{#include ../../banners/hacktricks-training.md}}
Notions de base sur les 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 d'une application Android :
{{#ref}} android-applications-basics.md {{#endref}}
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 la copie de fichiers dans les deux sens, l'installation et la désinstallation d'apps, l'exécution de commandes shell, la sauvegarde des données, la lecture des logs, entre autres fonctions.
Consultez la liste suivante de 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 passwords bien obfusqués ou des flags). Ensuite, il peut être intéressant de décompiler l'apk, modifier le code et le recompiler.
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 lors de l'analyse dynamique qui vont être présentés. Donc, gardez toujours cette possibilité à l'esprit.
Autres astuces intéressantes
- Spoofing your location in Play Store
- Shizuku Privileged API (ADB-based non-root privileged access)
- Exploiting Insecure In-App Update Mechanisms
- Abusing Accessibility Services (Android RAT)
- Download APKs: https://apps.evozi.com/apk-downloader/, https://apkpure.com/es/, https://www.apkmirror.com/, https://apkcombo.com/es-es/apk-downloader/, https://github.com/kiber-io/apkd
- Extraire l'APK depuis l'appareil:
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
- Fusionnez 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
Études de cas & Vulnerabilities
{{#ref}} ../ios-pentesting/air-keyboard-remote-input-injection.md {{#endref}}
{{#ref}} ../../linux-hardening/privilege-escalation/android-rooting-frameworks-manager-auth-bypass-syscall-hook.md {{#endref}}
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
Rien qu'en regardant les strings de l'APK, vous pouvez rechercher des passwords, des URLs (https://github.com/ndelphit/apkurlgrep), des api keys, de l'encryption, des bluetooth uuids, des tokens et tout ce qui est intéressant... recherchez même des backdoors d'exécution de code ou des backdoors d'authentification (hardcoded admin credentials to the app).
Firebase
Portez une attention particulière aux Firebase URLs et vérifiez si elles sont mal configurées. Plus d'informations sur ce qu'est Firebase et comment l'exploiter ici.
Basic understanding of the application - Manifest.xml, strings.xml
L'examen des fichiers Manifest.xml et strings.xml d'une application peut révéler des vulnérabilités de sécurité potentielles. Ces fichiers sont accessibles via des décompilateurs ou en renommant l'extension APK en .zip puis en décompressant.
Vulnerabilities identified from the Manifest.xml include:
- Debuggable Applications: Les applications définies comme debuggable (
debuggable="true"
) dans le fichier Manifest.xml représentent un risque car elles autorisent des connexions pouvant mener à une exploitation. Pour comprendre comment exploiter des applications debuggable, référez-vous à un tutoriel sur la découverte et l'exploitation d'applications debuggable sur un appareil. - Backup Settings: L'attribut
android:allowBackup="false"
devrait être explicitement défini pour les applications manipulant des informations sensibles afin d'empêcher des sauvegardes non autorisées via adb, en particulier lorsque le usb debugging est activé. - Network Security: Les configurations réseau personnalisées (
android:networkSecurityConfig="@xml/network_security_config"
) dans res/xml/ peuvent spécifier des détails de sécurité comme le certificate pinning et les réglages du trafic HTTP. Un exemple est d'autoriser le trafic HTTP pour des domaines spécifiques. - Exported Activities and Services: Identifier les activities et services exportés dans le manifest peut mettre en évidence des composants susceptibles d'être détournés. Une analyse plus approfondie en test dynamique peut révéler comment exploiter ces composants.
- Content Providers and FileProviders: Des content providers exposés pourraient permettre un accès non autorisé ou la modification de données. La configuration des FileProviders doit également être scrutée.
- Broadcast Receivers and URL Schemes: Ces composants pourraient être utilisés pour des exploitations, en portant une attention particulière à la gestion des URL schemes pour des vulnérabilités d'entrée.
- SDK Versions: Les attributs
minSdkVersion
,targetSDKVersion
, etmaxSdkVersion
indiquent les versions Android supportées, ce qui souligne l'importance de ne pas supporter des versions Android obsolètes et vulnérables pour des raisons de sécurité.
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 est une attaque où une malicious application est lancée et se positionne au-dessus d'une application victime. Une fois qu'elle obscurcit visiblement l'application victime, son interface utilisateur est conçue de façon à tromper l'utilisateur pour qu'il interagisse avec elle, tandis qu'elle transmet l'interaction à l'application victime.
En pratique, c'est aveugler l'utilisateur afin qu'il ne sache pas qu'il effectue en réalité des actions sur l'application victime.
Find more information in:
{{#ref}} tapjacking.md {{#endref}}
Task Hijacking
Une activity avec le launchMode
défini sur singleTask
sans aucun taskAffinity
est vulnérable au task Hijacking. Cela signifie qu'une application peut être installée et si elle est lancée avant la vraie application, elle pourrait hijack the task of the real application (donc l'utilisateur interagira avec la malicious application en pensant utiliser la vraie).
More info in:
{{#ref}} android-task-hijacking.md {{#endref}}
Insecure data storage
Internal Storage
Sur Android, les fichiers stockés en internal storage sont conçus pour être accessibles exclusivement par l'app qui les a créés. Cette mesure de sécurité est appliquée par le système d'exploitation Android et est généralement suffisante pour la plupart des applications. Cependant, les développeurs utilisent parfois des modes comme MODE_WORLD_READABLE
et MODE_WORLD_WRITABLE
pour permettre le partage de fichiers entre différentes applications. Ces modes ne restreignent pas l'accès à ces fichiers par d'autres applications, y compris potentiellement malveillantes.
- Static Analysis:
- Ensure que l'utilisation de
MODE_WORLD_READABLE
etMODE_WORLD_WRITABLE
soit examinée attentivement. Ces modes peuvent exposer des fichiers à des accès non souhaités ou non autorisés.
- Dynamic Analysis:
- Verify les permissions définies sur les fichiers créés par l'app. En particulier, vérifiez si des fichiers sont rendux lisibles ou modifiables worldwide. Cela peut poser un risque de sécurité important, car cela permettrait à n'importe quelle application installée sur l'appareil, quelle que soit son origine ou son intention, de lire ou modifier ces fichiers.
External Storage
Quand on traite des fichiers sur le external storage, comme les cartes SD, certaines précautions doivent être prises:
- Accessibility:
- Les fichiers sur external storage sont globalement lisibles et modifiables. Cela signifie que toute application ou utilisateur peut y accéder.
- Security Concerns:
- Étant donné la facilité d'accès, il est conseillé de ne pas stocker d'informations sensibles sur l'external storage.
- L'external storage peut être retiré ou accédé par n'importe quelle application, le rendant moins sécurisé.
- Handling Data from External Storage:
- Toujours effectuer une validation des entrées sur les données récupérées depuis l'external storage. C'est crucial car les données proviennent d'une source non fiable.
- Il est fortement déconseillé de stocker des exécutables ou des fichiers de classes sur l'external storage pour un chargement dynamique.
- Si votre application doit impérativement récupérer des fichiers exécutables depuis l'external storage, assurez-vous que ces fichiers soient signés et vérifiés cryptographiquement avant d'être chargés dynamiquement. Cette étape est vitale pour maintenir l'intégrité de la sécurité de votre 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//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//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 également 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é codée en dur/prédictible dans le code. Cela ne devrait pas être fait car du reversing pourrait permettre à des attaquants d'extraire les informations confidentielles.
Utilisation d'algorithmes non sécurisés et/ou obsolètes
Les développeurs ne devraient pas utiliser des deprecated algorithms pour effectuer des authorisation checks, 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, des hashes résistants au brute-force devraient être utilisés avec du salt.
Autres vérifications
- Il est recommandé d'obfusquer l'APK pour rendre le travail de reverse engineering plus difficile pour les attaquants.
- Si l'app est sensible (comme les apps bancaires), elle devrait effectuer ses propres vérifications pour savoir si le mobile est rooté et agir en conséquence.
- Si l'app est sensible (comme les apps bancaires), elle devrait vérifier si un emulator est utilisé.
- Si l'app est sensible (comme les apps bancaires), elle devrait vérifier son intégrité avant de s'exécuter pour vérifier si elle a été modifiée.
- Use APKiD to check which compiler/packer/obfuscator was used to build the APK
React Native Application
Read the following page to learn how to easily access javascript code of React applications:
{{#ref}} react-native-application.md {{#endref}}
Xamarin Applications
Read the following page to learn how to easily access C# code of a xamarin applications:
{{#ref}} ../xamarin-apps.md {{#endref}}
Superpacked Applications
According to this blog post superpacked is a Meta algorithm that compress the content of an application into a single file. The blog talks about the possibility of creating an app that decompress these kind of apps... and a faster way which involves to execute the application and gather the decompressed files from the filesystem.
Automated Static Code Analysis
The tool mariana-trench is capable of finding vulnerabilities by scanning the code of the application. This tool contains a series of known sources (that indicates to the tool the places where the input is controlled by the user), sinks (which indicates to the tool dangerous places where malicious user input could cause damages) and rules. These rules indicates the combination of sources-sinks that indicates a vulnerability.
With this knowledge, mariana-trench will review the code and find possible vulnerabilities on it.
Secrets leaked
An application may contain secrets (API keys, passwords, hidden urls, subdomains...) inside of it that you might be able to discover. You could us a tool such as https://github.com/dwisiswant0/apkleaks
Bypass Biometric Authentication
{{#ref}} bypass-biometric-authentication-android.md {{#endref}}
Other interesting functions
- Code execution:
Runtime.exec(), ProcessBuilder(), native code:system()
- Send SMSs:
sendTextMessage, sendMultipartTestMessage
- Native functions declared as
native
:public native, System.loadLibrary, System.load
- Read this to learn how to reverse native functions
Other tricks
{{#ref}} content-protocol.md {{#endref}}
Analyse dynamique
Tout d'abord, vous avez besoin d'un environnement où vous pouvez installer l'application et tout l'environnement (Burp CA cert, Drozer and Frida mainly). Par conséquent, un appareil rooté (émulé ou non) est fortement recommandé.
Analyse dynamique en ligne
Vous pouvez créer un compte gratuit sur : https://appetize.io/. Cette plateforme permet d'uploader et d'exécuter des APKs, donc elle est utile pour voir le comportement d'un apk.
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 émulateurs.
Analyse dynamique locale
Utiliser un émulateur
- Android Studio (Vous pouvez créer des devices x86 et arm, et d'après this latest x86 versions support ARM libraries without needing an slow arm emulator).
- Apprenez à le configurer sur cette page :
{{#ref}} avd-android-virtual-device.md {{#endref}}
- Genymotion (Free version: Personal Edition, you need to create an account. It's recommend to download the version WITH VirtualBox to avoid potential errors.)
- Nox (Gratuit, mais il ne supporte pas Frida ou Drozer).
Tip
Lors de la création d'un nouvel émulateur sur n'importe quelle plateforme, souvenez-vous que plus l'écran est grand, plus l'émulateur sera lent. Donc, sélectionnez des écrans petits si possible.
Pour installer google services (comme AppStore) dans Genymotion, vous devez cliquer sur le bouton marqué en rouge de l'image suivante :
De plus, notez que dans la configuration de la VM Android dans Genymotion vous pouvez sélectionner le Bridge Network mode (cela sera utile si vous vous connectez à la VM Android depuis une VM différente avec les outils).
Utiliser un appareil physique
Vous devez activer les options de debugging et il est préférable de pouvoir le rooter :
- Settings.
- (FromAndroid 8.0) Select System.
- Select About phone.
- Press Build number 7 times.
- Go back and you will find the Developer options.
Une fois que vous avez installé l'application, la première chose à faire est de l'essayer, d'investiguer 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 comment l'application fonctionne pendant que MobSF capture beaucoup de données intéressantes que vous pourrez consulter ultérieurement.
Fuite de données non intentionnelle
Logging
Les développeurs doivent être prudents quant à l'exposition d'informations de debugging publiquement, car cela peut entraîner des leaks de données sensibles. Les outils pidcat et adb logcat
sont recommandés pour surveiller les logs des applications afin d'identifier et de protéger les informations sensibles. Pidcat est privilégié pour sa facilité d'utilisation et sa lisibilité.
Warning
Notez que depuis later newer than Android 4.0, les applications ne peuvent accéder qu'à leurs propres logs. Ainsi, les applications ne peuvent pas accéder aux logs d'autres apps.
Quoi qu'il en soit, il est toujours recommandé de ne pas logger d'informations sensibles.
Mise en cache du presse-papiers (Copy/Paste Buffer Caching)
Le framework clipboard-based d'Android permet la fonctionnalité de copier-coller dans les apps, mais présente un risque car d'autres applications peuvent accéder au presse-papiers, 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 de prévenir les leaks de données.
Crash Logs
Si une application crashe et sauvegarde des logs, ces logs peuvent aider des attaquants, particulièrement lorsque l'application ne peut pas être reverse-engineered. Pour atténuer ce risque, évitez de logger lors des crashs, et si des logs doivent être transmis sur le réseau, assurez-vous qu'ils sont envoyés via un canal SSL pour la sécurité.
En tant que pentester, essayez de jeter un œil à ces logs.
Analytics Data Sent To 3rd Parties
Les applications intègrent souvent des services comme Google Adsense, qui peuvent involontairement leak sensitive data à cause d'une mauvaise implémentation par les développeurs. Pour identifier de potentielles fuites 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 utilisent des bases de données SQLite internes pour sauvegarder des informations. Pendant le pentest, jetez un œil aux databases créées, aux noms des tables et des colonnes et à toutes les données sauvegardé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 enregistre des informations confidentielles et est encrypted mais que vous pouvez trouver le password à l'intérieur de l'application, c'est toujours une vulnerability.
Énumérez les tables avec .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 is s useful tool to exploit exported activities, exported services and Content Providers as you will learn in the following sections.
Exploiting exported Activities
Read this if you want to refresh what is an Android Activity.
Also remember that the code of an activity starts in the onCreate
method.
Authorisation bypass
When an Activity is exported you can invoke its screen from an external app. Therefore, if an activity with sensitive information is exported you could bypass the authentication mechanisms to access it.
Learn how to exploit exported activities with Drozer.
You can also start an exported activity from 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
Note that an authorisation bypass is not always a vulnerability, it would depend on how the bypass works and which information is exposed.
Fuite d'informations sensibles
Les Activities peuvent aussi renvoyer des résultats. 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 tapjacking n'est pas empêché, vous pourriez abuser de l'activity exportée pour faire effectuer à l'utilisateur des actions inattendues. For more info about 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.
Content providers sont essentiellement utilisés pour partager des données. Si une application possède des content providers disponibles, 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.
Souvenez-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 renvoyer (ou non) une réponse. Donc, si une application exporte des services vous devez vérifier le code pour comprendre ce qu'il fait et tester celui-ci dynamiquement pour extraire des infos confidentielles, bypass des 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.
Souvenez-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 le mobile ouvrira automatiquement l'application appropriée pour 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'App, allez à l'activité appelée par le deeplink et cherchez la fonction onNewIntent
.
Infos sensibles
Chaque fois que vous trouvez un deep link, vérifiez qu'il ne reçoit pas de données sensibles (comme des mots de passe) via des paramètres d'URL, car toute autre application pourrait se faire passer pour le deep link et voler ces données !
Paramètres dans le chemin
Vous devez aussi vérifier si un deep link 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 un path traversal en accédant à quelque chose comme: example://app/users?username=../../unwanted-endpoint%3fparam=value
.
Notez que si vous trouvez les endpoints corrects dans 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 CSRF token et que l'endpoint vuln utilisait la méthode adéquate) et toute autre vuln. More info about this here.
Plus d'exemples
Un interesting bug bounty report intéressant sur les liens (/.well-known/assetlinks.json).
Inspection de la couche transport et échecs de vérification
- Certificates are not always inspected properly par les applications Android. Il est courant que ces applications ignorent les avertissements et acceptent des certificats self-signed ou, dans certains cas, repassent à des connexions HTTP.
- Negotiations during the SSL/TLS handshake are sometimes weak, 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écrypter 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 session cookies ou les détails utilisateur, contre l'interception par des entités malveillantes.
Vérification des certificats
Nous allons nous concentrer sur la certificate verification. L'intégrité du certificat du serveur doit être vérifiée pour renforcer la sécurité. Ceci est crucial car des configurations TLS insecure et la transmission de données sensibles sur des canaux non chiffrés peuvent poser des risques importants. Pour des étapes détaillées sur la vérification des certificats serveur et la remédiation des vulnérabilités, this resource fournit des conseils complets.
SSL Pinning
SSL Pinning est une mesure de sécurité où l'application vérifie le certificat du serveur contre une copie connue stockée dans l'application elle-même. Cette méthode est essentielle pour prévenir les attaques MITM. La mise en œuvre de SSL Pinning est fortement recommandée 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 (par ex., Burp). Sans l'installation de ce certificat, le trafic chiffré pourrait ne pas être visible via le proxy. Pour un guide sur l'installation d'un certificat CA personnalisé, 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é. Pour des instructions sur la modification du Network Security Config, refer to this tutorial.
Si Flutter est utilisé, vous devez suivre les instructions sur this page. En effet, ajouter simplement le certificat dans le store ne fonctionnera pas, car Flutter utilise sa propre liste de CAs valides.
Détection statique du SSL/TLS pinning
Avant d’essayer des contournements runtime, cartographiez rapidement où le pinning est appliqué dans l'APK. La découverte statique vous aide à planifier des hooks/patches et à vous concentrer sur les bons chemins de code.
Outil : SSLPinDetect
- Outil open-source d'analyse statique qui décompile l'APK en Smali (via apktool) et scanne des patterns regex sélectionnés d'implémentations de SSL/TLS pinning.
- Signale 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 personnalisés : 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
Exemples 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 et conseils
- Scan rapide des grandes apps via multi-threading et I/O mappée en mémoire ; les regex précompilées réduisent l'overhead / les faux positifs.
- Pattern collection: https://github.com/aancw/smali-sslpin-patterns
- Cibles typiques à trier ensuite :
- OkHttp: usage de CertificatePinner, setCertificatePinner, références de package okhttp3/okhttp
- TrustManagers personnalisés: javax.net.ssl.X509TrustManager, overrides de checkServerTrusted
- Contexts SSL personnalisés: SSLContext.getInstance + SSLContext.init avec des managers personnalisés
- Pins déclaratifs dans res/xml network security config et références dans le manifest
- Utilisez les emplacements trouvés pour planifier des hooks Frida, des patchs statiques ou des revues de config avant les tests dynamiques.
Contournement de SSL Pinning
Quand SSL Pinning est implémenté, le contourner devient nécessaire pour inspecter le trafic HTTPS. Plusieurs méthodes existent pour cela :
- Modifier automatiquement l'apk pour bypasser SSLPinning avec apk-mitm. Le principal avantage de cette option est que vous n'aurez pas besoin de root pour bypasser le SSL Pinning, mais vous devrez supprimer l'application et réinstaller la nouvelle, et ça ne marche pas toujours.
- Vous pouvez utiliser Frida (discuté ci‑dessous) pour bypasser cette protection. Voici un guide pour utiliser Burp+Frida+Genymotion : https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/
- Vous pouvez aussi essayer de bypasser automatiquement SSL Pinning en utilisant objection** :**
objection --gadget com.package.app explore --startup-command "android sslpinning disable"
- Vous pouvez aussi essayer de bypasser automatiquement SSL Pinning en utilisant MobSF dynamic analysis (expliqué ci‑dessous)
- Si vous pensez toujours qu'il y a du trafic que vous ne capturez pas, vous pouvez essayer de rediriger le trafic vers burp en utilisant iptables. Lire ce blog : https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62
Recherche de vulnérabilités Web courantes
Il est important de rechercher aussi les vulnérabilités web courantes dans l'application. Les informations détaillées pour les identifier et les atténuer dépassent le cadre de ce résumé mais sont largement traitées ailleurs.
Frida
Frida est un toolkit d'instrumentation dynamique pour développeurs, reverse‑engineers et chercheurs en sécurité.
Vous pouvez accéder à l'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 utiliser Frida.
- Apprenez à utiliser Frida : Frida tutorial
- Quelques "GUI" pour actions avec Frida : https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security
- Objection est excellent pour automatiser l'utilisation de Frida : https://github.com/sensepost/objection , https://github.com/dpnishant/appmon
- Vous pouvez trouver des scripts Frida intéressants ici : https://codeshare.frida.re/
- Essayez de bypasser les mécanismes anti-debugging / anti-frida en chargeant Frida comme indiqué dans https://erfur.github.io/blog/dev/code-injection-without-ptrace (outil linjector)
Anti-instrumentation & workflow de contournement SSL pinning
{{#ref}} android-anti-instrumentation-and-ssl-pinning-bypass.md {{#endref}}
Dump mémoire - Fridump
Vérifiez si l'application stocke des informations sensibles en mémoire qu'elle ne devrait pas, comme des mots de passe ou des mnemonics.
Avec Fridump3 vous pouvez dumper la mémoire de l'app avec:
# 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 là vous pouvez 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
Sur Android, le Keystore est le meilleur endroit pour stocker des données sensibles, cependant, avec des privilèges suffisants il est encore possible d'y accéder. Comme les applications ont tendance à stocker ici des données sensibles en clair, les pentests devraient le vérifier en tant que root user, car quelqu'un ayant un accès physique à l'appareil pourrait voler ces données.
Même si une app stocke des données dans le keystore, les données doivent être chiffrées.
Pour accéder aux données à l'intérieur du keystore vous pourriez utiliser ce 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 script Frida suivant, il pourrait être possible de bypass fingerprint authentication que certaines applications Android mettent en œuvre pour protect certain sensitive areas:
frida --codeshare krapgras/android-biometric-bypass-update-android-11 -U -f <app.package>
Images d'arrière-plan
Lorsque vous mettez une application en arrière-plan, Android stocke un instantané de l'application, de sorte que lorsqu'elle est rétablie au premier plan, Android commence à charger l'image avant l'application, donnant l'impression que l'application s'est chargée plus rapidement.
Cependant, si cet instantané contient des informations sensibles, quelqu'un ayant accès à l'instantané pourrait voler ces infos (notez que vous avez besoin de root pour y accéder).
Les instantanés sont généralement stockés à : /data/system_ce/0/snapshots
Android fournit un moyen de prévenir la capture d'écran en définissant le paramètre de layout FLAG_SECURE. En utilisant ce flag, le contenu de la fenêtre est traité comme sécurisé, l'empêchant d'apparaître dans les captures d'écran ou d'être affiché sur des écrans non sécurisés.
getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
Android Application Analyzer
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 proxies comme des activities, services et broadcast receivers qui traitent ces Intents et les transmettent à des méthodes telles que startActivity(...)
ou sendBroadcast(...)
, ce qui peut être risqué.
Le danger réside dans le 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
qui convertit des URLs en objets Intent
via Intent.parseUri(...)
puis les exécute, ce qui peut conduire à des injections d'Intent malveillantes.
Essential Takeaways
- Intent Injection est similaire au problème Open Redirect du web.
- Les exploits impliquent de passer des objets
Intent
en tant qu'extras, qui 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
parWebView
peut faciliter des actions non désirées.
Android Client Side Injections and others
Vous connaissez probablement ce type de vulnérabilités depuis le Web. Vous devez être particulièrement prudent avec ces vulnérabilités dans une application Android :
- SQL Injection: Lors du traitement 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 Plugin est désactivé pour tous les WebViews (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, lorsque l'application Android termine la session, le cookie n'est pas révoqué ou peut même être sauvegardé sur le disque
- Secure Flag in cookies
Automatic Analysis
MobSF
Static analysis
Évaluation des vulnérabilités de l'application via une belle interface web. Vous pouvez aussi 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 vous permet aussi de diff/Compare les analyses et d'intégrer 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 régler VT_UPLOAD
sur False
, dans ce cas le hash sera upload au lieu du fichier.
Assisted Dynamic analysis with MobSF
MobSF peut aussi être très utile pour l'analyse dynamique 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'analyseur dynamique de MobSF peut :
- Dump application data (URLs, logs, clipboard, captures d'écran faites par vous, captures d'écran faites par "Exported Activity Tester", emails, bases de données SQLite, fichiers XML, et autres fichiers créés). Tout ceci 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.
- Capture HTTPS traffic
- Use Frida to obtain runtime information
À partir des versions Android > 5, il démarrera automatiquement Frida et définira 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, prendre des screenshots de celles-ci et les save pour le rapport.
Pour start les tests dynamiques, 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 invocations des méthodes hookées, les arguments passés et les valeurs retournées (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 Frida scripts à MobSF utilisez la fonction send()
). Il contient é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" et appuyer sur "Start Instrumentation" (vous pourrez voir les logs de ces scripts dans "Frida Live Logs").
De plus, vous disposez de quelques fonctionnalités auxiliaires Frida :
- Enumerate Loaded Classes: Il affichera toutes les classes chargées
- Capture Strings: Il affichera toutes les chaînes capturées pendant l'utilisation de l'application (très bruyant)
- Capture String Comparisons: Peut être très utile. Il montrera les 2 chaînes being compared et si le résultat était True or False.
- Enumerate Class Methods: Indiquez le nom de la classe (comme "java.io.File") et il imprimera toutes les méthodes de la classe.
- Search Class Pattern: Recherche des classes par pattern
- Trace Class Methods: Trace une classe entière (voir les entrées et sorties de toutes les méthodes de la classe). Rappelez-vous qu'au départ MobSF trace plusieurs méthodes Android Api intéressantes.
Une fois que vous avez sélectionné le module auxiliaire que vous voulez utiliser, vous devez appuyer sur "Start Intrumentation" et vous verrez toutes les sorties dans "Frida Live Logs".
Shell
MobSF fournit également un shell avec quelques commandes adb, MobSF commands, et des shell commands courantes 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\).
Une fois l'analyse dynamique terminée avec MobSF, vous pouvez cliquer sur "Start Web API Fuzzer" pour fuzz http requests et rechercher des vulnérabilités.
Tip
Après avoir effectué une analyse dynamique avec MobSF, les paramètres proxy peuvent être mal configurés et vous ne pourrez pas les corriger depuis la GUI. Vous pouvez réparer les paramètres proxy en exécutant :
adb shell settings put global http_proxy :0
Assisted Dynamic Analysis with Inspeckage
You can get the tool from Inspeckage.
Cet outil utilise des Hooks pour vous indiquer ce qui se passe dans l'application pendant que vous effectuez une analyse dynamique.
Yaazhini
C'est un excellent outil pour effectuer une analyse statique avec une GUI
Qark
Cet outil est conçu pour rechercher plusieurs security related Android application vulnerabilities, soit dans le source code soit dans des packaged APKs. L'outil est aussi capable of creating a "Proof-of-Concept" deployable APK et des ADB commands, pour exploiter certaines des vulnérabilités trouvées (Exposed activities, intents, tapjacking...). Comme avec Drozer, il n'est pas nécessaire de rooter l'appareil de test.
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 APK en Java et Smali
- Analyse AndroidManifest.xml pour les vulnérabilités et comportements courants
- Analyse statique du code source pour 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 qui peut être utilisée sous Windows, MacOS X et Linux, et qui analyse des .apk files à la recherche de vulnérabilités. Il le fait 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
, et chaque entreprise ou testeur peut créer ses propres règles selon ses besoins.
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 effectuant static code analysis sur les applications mobiles.
Le concept est que vous glissiez-déposiez votre fichier d'application mobile (un fichier .apk ou .ipa) sur l'application StaCoAn et elle 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 les hackers à trouver des vulnérabilités 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'avertir l'utilisateur au sujet de comportements potentiellement malveillants développés par une application Android.
La détection est effectuée par l'analyse statique du Dalvik bytecode de l'application, représenté en Smali, à l'aide de la bibliothèque androguard
.
Cet outil recherche les comportements courants des applications 'malveillantes' comme : 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 Mobile Application Reverse engineering and Analysis Framework. C'est un outil qui regroupe des outils couramment utilisés pour le reverse engineering et l'analyse d'applications mobiles, afin d'assister les tests des applications mobiles contre les menaces de sécurité mobile OWASP. Son objectif est de rendre cette tâche plus simple et plus accessible aux développeurs d'applications mobiles et aux professionnels de la sécurité.
It is able to:
- Extract Java and Smali code using different tools
- Analyze APKs using: smalisca, ClassyShark, androbugs, androwarn, APKiD
- Extract private information from the APK using regexps.
- Analyze the Manifest.
- Analyze found domains using: pyssltest, testssl and whatweb
- Deobfuscate APK via apk-deguard.com
Koodous
Utile pour détecter les malware: https://koodous.com/
Obfuscating/Deobfuscating code
Notez que, selon le service et la configuration que vous utilisez pour obfuscate le code, les secrets peuvent ou non rester obfuscated.
ProGuard
From Wikipedia: ProGuard is an open source command-line tool that shrinks, optimizes and obfuscates Java code. Il est capable d'optimiser le bytecode ainsi que de détecter et supprimer les instructions non utilisées. ProGuard est un logiciel libre distribué sous la GNU General Public License, version 2.
ProGuard is distributed as part of the Android SDK and runs when building the application in release mode.
DexGuard
Find a step-by-step guide to deobfuscate the apk in https://blog.lexfo.fr/dexguard.html
(From that guide) Last time we checked, the Dexguard mode of operation was:
- load a resource as an InputStream;
- feed the result to a class inheriting from FilterInputStream to decrypt it;
- do some useless obfuscation to waste a few minutes of time from a reverser;
- feed the decrypted result to a ZipInputStream to get a DEX file;
- finally load the resulting DEX as a Resource using the
loadDex
method.
DeGuard
DeGuard reverses the process of obfuscation performed by Android obfuscation tools. This enables numerous security analyses, including code inspection and predicting libraries.
Vous pouvez uploader un APK obfuscated sur leur plateforme.
[Deobfuscate android App]https://github.com/In3tinct/deobfuscate-android-app
This is a LLM tool to find any potential security vulnerabilities in android apps and deobfuscate android app code. Uses Google's Gemini public API.
Simplify
It is a generic android deobfuscator. Simplify virtually executes an app to understand its behavior and then tries to optimize the code so it behaves identically but is easier for a human to understand. Each optimization type is simple and generic, so it doesn't matter what the specific type of obfuscation is used.
APKiD
APKiD gives you information about how an APK was made. It identifies many compilers, packers, obfuscators, and other weird stuff. It's PEiD for Android.
Manual
Read this tutorial to learn some tricks on how to reverse custom obfuscation
Laboratoires
Androl4b
AndroL4b est une virtual machine de sécurité Android basée sur ubuntu-mate qui inclut une collection des derniers frameworks, tutoriels et labs provenant de différents experts en sécurité et chercheurs pour le reverse engineering et l'analyse de malware.
Références
- https://owasp.org/www-project-mobile-app-security/
- https://appsecwiki.com/#/ C'est une excellente liste de ressources
- https://maddiestone.github.io/AndroidAppRE/ Android quick course
- https://manifestsecurity.com/android-application-security/
- https://github.com/Ralireza/Android-Security-Teryaagh
- https://www.youtube.com/watch?v=PMKnPaGWxtg&feature=youtu.be&ab_channel=B3nacSec
- SSLPinDetect: Advanced SSL Pinning Detection for Android Security Analysis
- SSLPinDetect GitHub
- smali-sslpin-patterns
À essayer
{{#include ../../banners/hacktricks-training.md}}