Install Burp Certificate

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE) GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks 지원하기

• 구독 계획 확인하기!

• **💬 Discord 그룹 또는 텔레그램 그룹에 참여하거나 Twitter 🐦 @hacktricks_live를 팔로우하세요.

• HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 팁을 공유하세요.

Websec | Uw Cybersecurity Specialist

가상 머신에서

먼저 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로 변경하여 다운로드 폴더에 저장하고 Install a certificate -> CA certificate로 이동합니다.

• Trusted credentials -> USER로 가서 인증서가 올바르게 저장되었는지 확인합니다.

1. 시스템 신뢰로 만들기: Magisc 모듈 MagiskTrustUserCerts (zip 파일)을 다운로드하고, 드래그 앤 드롭하여 전화기에 넣고, 전화기의 Magics 앱에서 Modules 섹션으로 이동하여 **Install from storage**를 클릭하고, .zip 모듈을 선택한 후 설치가 완료되면 재부팅합니다:

• 재부팅 후 Trusted credentials -> SYSTEM으로 가서 Postswigger 인증서가 있는지 확인합니다.

Android 14 이후

최신 Android 14 릴리스에서는 시스템 신뢰 CA 인증서 처리 방식에 중대한 변화가 관찰되었습니다. 이전에는 이러한 인증서가 **/system/etc/security/cacerts/**에 저장되어 루트 권한을 가진 사용자가 접근하고 수정할 수 있었으며, 이를 통해 시스템 전반에 즉시 적용할 수 있었습니다. 그러나 Android 14에서는 저장 위치가 **/apex/com.android.conscrypt/cacerts**로 이동하였으며, 이는 본질적으로 변경 불가능한 디렉토리입니다.

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 명령어로 운영 체제를 소프트 재부팅하는 것입니다. 이 접근법은 모든 네임스페이스에 걸쳐 변경 사항을 전파하여 각 실행 중인 앱을 개별적으로 처리할 필요가 없습니다. 그러나 이 방법은 재부팅의 불편함으로 인해 일반적으로 덜 선호됩니다.

References

• https://httptoolkit.com/blog/android-14-install-system-ca-certificate/

Websec | Uw Cybersecurity Specialist

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.