Burp-Zertifikat installieren

Reading time: 9 minutes

Systemweiter Proxy über ADB

Konfiguriere einen globalen HTTP-Proxy, sodass sämtlicher App-Traffic durch deinen Interceptor (Burp/mitmproxy) geleitet wird:

# Set proxy (device/emulator must reach your host IP)
adb shell settings put global http_proxy 192.168.1.2:8080

# Clear proxy
adb shell settings put global http_proxy :0

Tipp: In Burp binde deinen Listener an 0.0.0.0, damit Geräte im LAN eine Verbindung herstellen können (Proxy -> Options -> Proxy Listeners).

Auf einer virtuellen Maschine

Zuerst musst du das Der-Zertifikat von Burp herunterladen. Du kannst dies in Proxy --> Options --> Import / Export CA certificate tun.

Export the certificate in Der format und lass uns es in eine Form transformieren, die Android verstehen kann. Beachte, dass um das Burp-Zertifikat auf der Android-Maschine in AVD zu konfigurieren du diese Maschine mit der Option -writable-system starten musst.
Zum Beispiel kannst du sie so starten:

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

Dann, um burps certificate zu konfigurieren, führe Folgendes aus:

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

Sobald die Maschine den Neustart abgeschlossen hat, wird das Burp-Zertifikat von ihr verwendet!

Verwendung von Magisc

Wenn Sie Ihr Gerät mit Magisc gerootet haben (vielleicht ein Emulator) und Sie die vorherigen Schritte zum Installieren des Burp-Zertifikats nicht ausführen können, weil das Dateisystem read-only ist und Sie es nicht als schreibbar remounten können, gibt es einen anderen Weg.

Erklärt in diesem Video müssen Sie:

1. Install a CA certificate: Ziehen Sie einfach das DER Burp-Zertifikat per Drag&Drop auf das Mobilgerät, ändern Sie die Erweiterung zu .crt, sodass es im Downloads-Ordner gespeichert wird, und gehen Sie zu Install a certificate -> CA certificate

• Überprüfen Sie, dass das Zertifikat korrekt gespeichert wurde, indem Sie zu Trusted credentials -> USER gehen

2. Make it System trusted: Laden Sie das Magisc-Modul MagiskTrustUserCerts (eine .zip-Datei) herunter, ziehen Sie es per Drag&Drop aufs Telefon, öffnen Sie die Magics-App auf dem Telefon und gehen Sie in den Modules-Bereich, klicken Sie auf Install from storage, wählen Sie das .zip-Modul aus und starten Sie nach der Installation das Telefon neu:

• Nach dem Neustart gehen Sie zu Trusted credentials -> SYSTEM und überprüfen, ob das Postswigger-Zertifikat dort vorhanden ist

Lernen, wie man ein Magisc-Modul erstellt

Siehe https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437

Nach Android 14

In der neuesten Android-14-Version wurde eine bedeutende Änderung im Umgang mit system-trusteten Certificate Authority (CA)-Zertifikaten festgestellt. Früher wurden diese Zertifikate in /system/etc/security/cacerts/ abgelegt, waren mit Root-Rechten zugänglich und modifizierbar, wodurch sie sofort systemweit angewendet wurden. Mit Android 14 wurde der Speicherort jedoch nach /apex/com.android.conscrypt/cacerts verschoben, ein Verzeichnis innerhalb des /apex-Pfads, das von Natur aus unveränderlich ist.

Versuche, den APEX cacerts path als schreibbar zu remounten, schlagen fehl, da das System solche Operationen nicht zulässt. Selbst Versuche, das Verzeichnis zu unmounten oder mit einem temporären Dateisystem (tmpfs) zu überlagern, umgehen die Unveränderlichkeit nicht; Anwendungen greifen weiterhin auf die ursprünglichen Zertifikatsdaten zu, unabhängig von Änderungen auf Dateisystemebene. Diese Robustheit ergibt sich daraus, dass das /apex-Mount mit PRIVATE propagation konfiguriert ist, wodurch Änderungen innerhalb des /apex-Verzeichnisses andere Prozesse nicht beeinflussen.

Die Initialisierung von Android umfasst den init-Prozess, der beim Start des Betriebssystems auch den Zygote-Prozess startet. Dieser Prozess ist dafür verantwortlich, Anwendungsprozesse mit einem neuen mount namespace zu starten, der ein privates /apex-Mount enthält und somit Änderungen an diesem Verzeichnis von anderen Prozessen isoliert.

Nichtsdestotrotz gibt es einen Workaround für diejenigen, die die system-trusteten CA-Zertifikate innerhalb des /apex-Verzeichnisses ändern müssen. Dies beinhaltet das manuelle Remounten von /apex, um die PRIVATE propagation zu entfernen und es dadurch schreibbar zu machen. Der Prozess umfasst das Kopieren des Inhalts von /apex/com.android.conscrypt an einen anderen Ort, das Unmounten des Verzeichnisses /apex/com.android.conscrypt, um die Read-Only-Einschränkung zu beseitigen, und anschließend das Wiederherstellen des Inhalts an seinen ursprünglichen Ort innerhalb von /apex. Dieser Ansatz erfordert schnelles Handeln, um Systemabstürze zu vermeiden. Um sicherzustellen, dass diese Änderungen systemweit angewendet werden, wird empfohlen, den system_server neu zu starten, was effektiv alle Anwendungen neu startet und das System in einen konsistenten Zustand bringt.

# 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. Ein beschreibbares Verzeichnis einrichten: Zunächst wird ein beschreibbares Verzeichnis erstellt, indem ein tmpfs über das bestehende non-APEX System-Zertifikat-Verzeichnis gemountet wird. Dies geschieht mit dem folgenden Befehl:

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

2. Vorbereiten der CA-Zertifikate: Nach dem Anlegen des beschreibbaren Verzeichnisses sollten die CA-Zertifikate, die verwendet werden sollen, in dieses Verzeichnis kopiert werden. Das kann das Kopieren der Standardzertifikate aus /apex/com.android.conscrypt/cacerts/ beinhalten. Es ist wichtig, die Berechtigungen und SELinux-Labels dieser Zertifikate entsprechend anzupassen.
3. Bind Mounting for Zygote: Unter Verwendung von nsenter betritt man den Mount-Namespace von Zygote. Zygote, der Prozess, der für das Starten von Android-Anwendungen verantwortlich ist, erfordert diesen Schritt, um sicherzustellen, dass alle anschließend gestarteten Anwendungen die neu konfigurierten CA-Zertifikate verwenden. Der verwendete Befehl ist:

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

Dies stellt sicher, dass jede neu gestartete App dem aktualisierten CA certificates-Setup folgt.

4. Änderungen auf bereits laufende Apps anwenden: Um die Änderungen auf bereits laufende Anwendungen anzuwenden, wird nsenter erneut verwendet, um einzeln in den Namespace jeder App zu wechseln und ein ähnliches bind mount durchzuführen. Der erforderliche Befehl lautet:

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

5. Alternative Approach - Soft Reboot: Eine alternative Methode besteht darin, das bind mount am init Prozess (PID 1) durchzuführen, gefolgt von einem Soft Reboot des Betriebssystems mit den stop && start Befehlen. Dieser Ansatz würde die Änderungen über alle namespaces hinweg propagieren und erspart es, jede laufende App einzeln zu adressieren. Allerdings ist diese Methode im Allgemeinen weniger bevorzugt, da das Rebooten unpraktisch ist.

Referenzen

• Android 14: Install a system CA certificate on a rooted device
• Build a Repeatable Android Bug Bounty Lab: Emulator vs Magisk, Burp, Frida, and Medusa