Burp-Zertifikat installieren

Reading time: 9 minutes

Systemweiter Proxy über ADB

Konfiguriere einen globalen HTTP-Proxy, sodass alle Apps ihren Traffic über deinen Interceptor (Burp/mitmproxy) leiten:

# 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: Binde in Burp deinen Listener an 0.0.0.0, damit Geräte im LAN sich verbinden können (Proxy -> Options -> Proxy Listeners).

In einer virtuellen Maschine

Zuerst musst du das DER-Zertifikat aus Burp herunterladen. Das geht unter Proxy --> Options --> Import / Export CA certificate

Exportiere das Zertifikat im DER-Format und konvertiere es in ein Format, das Android verstehen kann. Beachte, dass du um das Burp-Zertifikat auf der Android-Maschine im AVD zu konfigurieren, 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 das Burp-Zertifikat 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 machine finish rebooting das System neu gestartet hat, wird das Burp-Zertifikat von ihm verwendet!

Using Magisc

Wenn du dein Gerät mit Magisc gerootet hast (vielleicht ein Emulator) und du die vorherigen Schritte zum Installieren des Burp-Zertifikats nicht ausführen kannst, weil das Filesystem read-only ist und du es nicht als schreibbar remounten kannst, gibt es eine andere Möglichkeit.

Erklärt in this video musst du:

1. Install a CA certificate: Ziehe per drag&drop das DER Burp-Zertifikat und ändere die Erweiterung zu .crt, sodass es im mobilen Gerät im Downloads-Ordner gespeichert wird, und gehe zu Install a certificate -> CA certificate

• Prüfe, dass das Zertifikat korrekt gespeichert wurde, indem du zu Trusted credentials -> USER gehst

2. Make it System trusted: Lade das Magisc-Modul MagiskTrustUserCerts (eine .zip-Datei) herunter, drag&drop es auf das Telefon, öffne die Magics-App auf dem Telefon im Bereich Modules, klicke auf Install from storage, wähle das .zip-Modul aus und starte das Telefon nach der Installation neu:

• Nach dem Neustart gehe zu Trusted credentials -> SYSTEM und überprüfe, ob das Postswigger-Zertifikat vorhanden ist

Learn how to create a Magisc module

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

Post Android 14

In der neuesten Android-14-Version wurde ein signifikanter Wandel in der Handhabung system-trusteter Certificate Authority (CA)-Zertifikate beobachtet. Früher wurden diese Zertifikate in /system/etc/security/cacerts/ abgelegt, was für Benutzer mit Root-Rechten zugänglich und änderbar war und eine sofortige Anwendung im gesamten System ermöglichte. Mit Android 14 wurde der Speicherort jedoch nach /apex/com.android.conscrypt/cacerts verschoben, einem Verzeichnis innerhalb des /apex-Pfads, das von Natur aus immutable 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 Zertifikatdaten zu, unabhängig von Änderungen auf Dateisystemebene. Diese Belastbarkeit liegt daran, dass der /apex-Mount mit PRIVATE propagation konfiguriert ist, wodurch Änderungen innerhalb des /apex-Verzeichnisses andere Prozesse nicht beeinflussen.

Die Initialisierung von Android beinhaltet 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 einen privaten /apex-Mount enthält und somit Änderungen an diesem Verzeichnis von anderen Prozessen isoliert.

Dennoch existiert ein Workaround für diejenigen, die die system-trusteten CA-Zertifikate im /apex-Verzeichnis ändern müssen. Dieser besteht darin, /apex manuell so zu remounten, dass die PRIVATE propagation entfernt wird, und es damit 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 seinem ursprünglichen Ort innerhalb von /apex. Dieser Ansatz erfordert schnelles Handeln, um Systemabstürze zu vermeiden. Um eine systemweite Anwendung dieser Änderungen sicherzustellen, 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. Einrichten eines beschreibbaren Verzeichnisses: Zunächst wird ein beschreibbares Verzeichnis eingerichtet, indem ein tmpfs über das bestehende non-APEX System-Zertifikatsverzeichnis gemountet wird. Dies wird mit dem folgenden Befehl erreicht:

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

2. Vorbereiten der CA-Zertifikate: Nachdem das beschreibbare Verzeichnis eingerichtet wurde, sollten die CA-Zertifikate, die verwendet werden sollen, in dieses Verzeichnis kopiert werden. Dies 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 für Zygote: Mit nsenter tritt man in das Mount-Namespace von Zygote ein. Zygote, der Prozess, der für das Starten von Android-Anwendungen verantwortlich ist, erfordert diesen Schritt, um sicherzustellen, dass alle künftig gestarteten Anwendungen die neu konfigurierten CA-Zertifikate verwenden. Der verwendete Befehl lautet:

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 die aktualisierte CA certificates-Einrichtung verwendet.

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

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

5. Alternative Vorgehensweise - Soft Reboot: Eine alternative Methode besteht darin, den bind mount am init-Prozess (PID 1) durchzuführen, gefolgt von einem Soft Reboot des Betriebssystems mit den Befehlen stop && start. Dieser Ansatz würde die Änderungen auf alle Namespaces übertragen und die Notwendigkeit vermeiden, jede laufende App einzeln zu adressieren. Diese Methode wird jedoch allgemein weniger bevorzugt, da der Neustart 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