Chinese - Ht
HackTricks Training Twitter Linkedin Sponsor

Install Burp Certificate

从零开始学习AWS黑客技术，成为专家 htARTE（HackTricks AWS Red Team Expert）！

支持HackTricks的其他方式：

在虚拟机上

首先，您需要从Burp下载Der证书。您可以在 Proxy --> Options --> Import / Export CA certificate 中执行此操作

以Der格式导出证书，然后将其转换为Android能够理解的形式。请注意，为了在AVD中的Android机器上配置burp证书，您需要使用**-writable-system选项运行**此机器。 例如，您可以这样运行：

C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system

然后，配置Burp证书：

openssl x509 -inform DER -in burp_cacert.der -out burp_cacert.pem
CERTHASHNAME="`openssl x509 -inform PEM -subject_hash_old -in burp_cacert.pem | head -1`.0"
mv burp_cacert.pem $CERTHASHNAME #Correct name
adb root && sleep 2 && adb remount #Allow to write on /syste
adb push $CERTHASHNAME /sdcard/ #Upload certificate
adb shell mv /sdcard/$CERTHASHNAME /system/etc/security/cacerts/ #Move to correct location
adb shell chmod 644 /system/etc/security/cacerts/$CERTHASHNAME #Assign privileges
adb reboot #Now, reboot the machine

一旦机器完成重新启动，Burp 证书将被其使用！

使用 Magisc

如果您使用 Magisc（可能是模拟器）对设备进行了 root 处理，并且由于文件系统是只读的且无法将其重新挂载为可写状态，因此无法按照之前的步骤安装 Burp 证书，那么还有另一种方法。

在此视频中有详细说明，您需要：

  1. 安装 CA 证书：只需将 DER Burp 证书拖放到移动设备上，将扩展名更改为.crt，以便将其存储在下载文件夹中，然后转到安装证书 -> CA 证书

  • 检查证书是否正确存储，转到受信任的凭据 -> 用户

  1. 使其成为系统信任的证书：下载 Magisc 模块MagiskTrustUserCerts（一个.zip 文件），将其拖放到手机中，在手机上打开 Magics 应用程序，转到**模块部分，点击从存储安装，选择.zip 模块，安装后重新启动**手机：

  • 重新启动后，转到受信任的凭据 -> 系统，检查 Postswigger 证书是否存在

Android 14 之后

在最新的 Android 14 发布版中，观察到了系统信任的证书颁发机构（CA）证书处理方式的重大变化。以前，这些证书存储在**/system/etc/security/cacerts/中，可供具有 root 权限的用户访问和修改，从而允许立即在系统中应用。然而，Android 14 将存储位置移至/apex/com.android.conscrypt/cacerts，这是/apex**路径内的一个目录，具有不可变性。

尝试将APEX cacerts 路径重新挂载为可写会失败，因为系统不允许此类操作。即使尝试卸载或使用临时文件系统（tmpfs）覆盖目录，也无法规避不可变性；应用程序继续访问原始证书数据，而不考虑文件系统级别的更改。这种弹性是由于**/apex** 挂载配置为私有传播，确保**/apex** 目录内的任何修改不会影响其他进程。

Android 的初始化涉及init 进程，该进程在启动操作系统时还会启动 Zygote 进程。该进程负责使用包含私有**/apex** 挂载的新挂载命名空间启动应用程序进程，从而将对该目录的更改与其他进程隔离开来。

然而，对于需要修改**/apex** 目录内系统信任的 CA 证书的人来说，存在一种解决方法。这涉及手动重新挂载**/apex** 以去除私有传播，从而使其可写。该过程包括将**/apex/com.android.conscrypt** 的内容复制到另一个位置，卸载**/apex/com.android.conscrypt** 目录以消除只读约束，然后将内容恢复到**/apex** 中的原始位置。这种方法需要迅速行动，以避免系统崩溃。为了确保这些更改在整个系统范围内应用，建议重新启动system_server，这将有效地重新启动所有应用程序，并使系统处于一致状态。

# Create a separate temp directory, to hold the current certificates
# Otherwise, when we add the mount we can't read the current certs anymore.
mkdir -p -m 700 /data/local/tmp/tmp-ca-copy

# Copy out the existing certificates
cp /apex/com.android.conscrypt/cacerts/* /data/local/tmp/tmp-ca-copy/

# Create the in-memory mount on top of the system certs folder
mount -t tmpfs tmpfs /system/etc/security/cacerts

# Copy the existing certs back into the tmpfs, so we keep trusting them
mv /data/local/tmp/tmp-ca-copy/* /system/etc/security/cacerts/

# Copy our new cert in, so we trust that too
mv $CERTIFICATE_PATH /system/etc/security/cacerts/

# Update the perms & selinux context labels
chown root:root /system/etc/security/cacerts/*
chmod 644 /system/etc/security/cacerts/*
chcon u:object_r:system_file:s0 /system/etc/security/cacerts/*

# Deal with the APEX overrides, which need injecting into each namespace:

# First we get the Zygote process(es), which launch each app
ZYGOTE_PID=$(pidof zygote || true)
ZYGOTE64_PID=$(pidof zygote64 || true)
# N.b. some devices appear to have both!

# Apps inherit the Zygote's mounts at startup, so we inject here to ensure
# all newly started apps will see these certs straight away:
for Z_PID in "$ZYGOTE_PID" "$ZYGOTE64_PID"; do
if [ -n "$Z_PID" ]; then
nsenter --mount=/proc/$Z_PID/ns/mnt -- \
/bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
fi
done

# Then we inject the mount into all already running apps, so they
# too see these CA certs immediately:

# Get the PID of every process whose parent is one of the Zygotes:
APP_PIDS=$(
echo "$ZYGOTE_PID $ZYGOTE64_PID" | \
xargs -n1 ps -o 'PID' -P | \
grep -v PID
)

# Inject into the mount namespace of each of those apps:
for PID in $APP_PIDS; do
nsenter --mount=/proc/$PID/ns/mnt -- \
/bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts &
done
wait # Launched in parallel - wait for completion here

echo "System certificate injected"

通过 NSEnter 进行绑定挂载

  1. 设置可写目录：首先，通过在现有的非 APEX 系统证书目录上挂载 tmpfs 来建立一个可写目录。可以使用以下命令实现：

mount -t tmpfs tmpfs /system/etc/security/cacerts

  1. 准备 CA 证书：在设置可写目录之后，应将打算使用的 CA 证书复制到该目录中。这可能涉及从 /apex/com.android.conscrypt/cacerts/ 复制默认证书。必须相应地调整这些证书的权限和 SELinux 标签。

  2. 为 Zygote 进行绑定挂载：利用 nsenter，进入 Zygote 的挂载命名空间。Zygote 是负责启动 Android 应用程序的进程，需要执行此步骤以确保此后启动的所有应用程序都使用新配置的 CA 证书。使用的命令如下：

nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

这将确保每个新启动的应用程序都将遵守更新后的 CA 证书设置。

  1. 将更改应用于正在运行的应用程序：要将更改应用于已经运行的应用程序，再次使用 nsenter 逐个进入每个应用程序的命名空间，并执行类似的绑定挂载。必要的命令是：

nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

  1. 替代方法 - 软重启：另一种方法涉及在init进程（PID 1）上执行绑定挂载，然后使用stop && start命令对操作系统进行软重启。这种方法将在所有命名空间中传播更改，避免了需要单独处理每个正在运行的应用程序的需求。然而，由于重新启动的不便，通常不太偏好使用这种方法。

参考

从零开始学习AWS黑客技术，成为专家 htARTE（HackTricks AWS Red Team Expert）！

支持HackTricks的其他方式：

上一页Google CTF 2018 - Shall We Play a Game?下一页Intent Injection

最后更新于