Burp証明書のインストール
Reading time: 12 minutes
tip
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する:HackTricks Training GCP Red Team Expert (GRTE)
Azureハッキングを学び、実践する:
HackTricks Training Azure Red Team Expert (AzRTE)
HackTricksをサポートする
- サブスクリプションプランを確認してください!
- **💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
- HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。
仮想マシンで
まず最初に、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証明書をインストールできない場合、ファイルシステムが読み取り専用で書き込み可能に再マウントできない場合、別の方法があります。
このビデオで説明されているように、次のことを行う必要があります:
- CA証明書をインストールする:DER Burp証明書をドラッグ&ドロップし、モバイルで拡張子を
.crt
に変更してダウンロードフォルダーに保存し、証明書をインストール
->CA証明書
に進みます。
.png)
信頼できる資格情報
->ユーザー
に進んで、証明書が正しく保存されていることを確認します。
.png)
- システム信頼にする:MagiscモジュールMagiskTrustUserCerts(.zipファイル)をダウンロードし、ドラッグ&ドロップして電話に移動し、電話のMagicsアプリの**
モジュール
セクションに行き、ストレージからインストール
をクリックし、.zip
モジュールを選択してインストール後に再起動**します:
.png)
- 再起動後、
信頼できる資格情報
->システム
に進み、Postswigger証明書がそこにあることを確認します。
.png)
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"
NSEnterを通じたバインドマウント
- 書き込み可能なディレクトリの設定: 最初に、既存の非APEXシステム証明書ディレクトリの上に
tmpfs
をマウントすることで、書き込み可能なディレクトリが確立されます。これは次のコマンドで実現されます:
mount -t tmpfs tmpfs /system/etc/security/cacerts
- CA証明書の準備: 書き込み可能なディレクトリのセットアップに続いて、使用する予定のCA証明書をこのディレクトリにコピーする必要があります。これには、
/apex/com.android.conscrypt/cacerts/
からデフォルトの証明書をコピーすることが含まれる場合があります。これらの証明書の権限とSELinuxラベルを適切に調整することが重要です。 - 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証明書の設定に従うことが保証されます。
- 実行中のアプリへの変更の適用: 既に実行中のアプリケーションに変更を適用するには、
nsenter
を再度使用して各アプリの名前空間に個別に入り、同様のバインドマウントを実行します。必要なコマンドは:
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
- 代替アプローチ - ソフトリブート: 代替手法は、
init
プロセス(PID 1)でバインドマウントを行い、その後stop && start
コマンドでオペレーティングシステムをソフトリブートすることです。このアプローチは、すべてのネームスペースに変更を伝播させ、各実行中のアプリを個別に対処する必要を回避します。しかし、この方法はリブートの不便さから一般的にはあまり好まれません。
参考文献
tip
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する:HackTricks Training GCP Red Team Expert (GRTE)
Azureハッキングを学び、実践する:
HackTricks Training Azure Red Team Expert (AzRTE)
HackTricksをサポートする
- サブスクリプションプランを確認してください!
- **💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
- HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。