Japanese - Ht

Install Burp Certificate

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でデバイスをルート化した（おそらくエミュレーター）、そして前の手順に従ってBurp証明書をインストールできない場合、ファイルシステムが読み取り専用であり、書き込み可能に再マウントできない場合、別の方法があります。

このビデオで説明されているように、次のことを行う必要があります：

  1. CA証明書をインストールする：DER Burp証明書をドラッグ＆ドロップして、モバイルで拡張子を.crtに変更し、ダウンロードフォルダーに保存し、証明書をインストール -> CA証明書に進みます。

  • 信頼できる資格情報 -> ユーザーに進んで、証明書が正しく保存されていることを確認します。

  1. システム信頼にする：MagiscモジュールMagiskTrustUserCerts（.zipファイル）をダウンロードし、ドラッグ＆ドロップして電話に移動し、電話のMagicsアプリの**モジュールセクションに行き、ストレージからインストールをクリックし、.zipモジュールを選択し、インストール後に再起動**します：

  • 再起動後、信頼できる資格情報 -> システムに進み、Postswigger証明書がそこにあることを確認します。

Android 14以降

最新のAndroid 14リリースでは、システム信頼の証明書機関（CA）証明書の取り扱いに大きな変化が見られました。以前は、これらの証明書は**/system/etc/security/cacerts/に格納されており、ルート権限を持つユーザーによってアクセスおよび変更可能で、システム全体に即座に適用されていました。しかし、Android 14では、ストレージの場所が/apex/com.android.conscrypt/cacertsに移動され、これは/apex**パス内のディレクトリであり、本質的に不変です。

APEX cacertsパスを読み書き可能として再マウントしようとすると失敗します。システムはそのような操作を許可しません。一時ファイルシステム（tmpfs）でディレクトリをアンマウントまたはオーバーレイしようとする試みも不変性を回避することはできず、アプリケーションはファイルシステムレベルでの変更に関係なく、元の証明書データにアクセスし続けます。この耐性は、**/apexマウントがPRIVATE伝播で構成されているためであり、/apex**ディレクトリ内の変更が他のプロセスに影響を与えないことを保証します。

Androidの初期化にはinitプロセスが関与しており、オペレーティングシステムを起動すると同時にZygoteプロセスも開始されます。このプロセスは、新しいマウントネームスペースを持つアプリケーションプロセスを起動する責任があり、プライベートな**/apex**マウントを含むため、このディレクトリへの変更を他のプロセスから隔離します。

それでも、**/apexディレクトリ内のシステム信頼のCA証明書を変更する必要がある場合の回避策があります。これは、PRIVATE伝播を削除するために/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"

Bind-mounting through 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コマンドでオペレーティングシステムをソフトリブートすることを含みます。このアプローチは、すべてのネームスペースに変更を伝播させ、各実行中のアプリを個別に対処する必要を回避します。しかし、この方法はリブートの不便さから一般的にはあまり好まれません。

参考文献

Support HackTricks
PreviousGoogle CTF 2018 - Shall We Play a Game?NextIntent Injection

Last updated