Burp-Zertifikat installieren

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Durchsuche den vollständigen HackTricks Training-Katalog nach den Assessment-Tracks (ARTA/GRTA/AzRTA) und Linux Hacking Expert (LHE).

Support HackTricks

Systemweiter Proxy via ADB

Konfiguriere einen systemweiten 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 eine Verbindung herstellen können (Proxy -> Options -> Proxy Listeners).

In einer virtuellen Maschine

Zuerst musst du das DER-Zertifikat von Burp herunterladen. Du kannst das in Proxy –> Options –> Import / Export CA certificate machen

Exportiere das Zertifikat im DER-Format und lass es uns transformieren, in ein Format, das Android verstehen kann. Beachte, dass um das Burp-Zertifikat auf der Android-Maschine in AVD zu konfigurieren du diese Maschine mit der -writable-system Option 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ühren Sie 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 Magisk

Wenn du dein Gerät mit Magisk gerootet hast (z. B. einen Emulator), und du die vorherigen Schritte zur Installation des Burp-Zertifikats nicht ausführen kannst, weil das Dateisystem schreibgeschützt ist und du es nicht remounten kannst, gibt es einen anderen Weg.

Erklärt in diesem Video musst du:

  1. Installiere ein CA-Zertifikat: Einfach das DER Burp-Zertifikat per Drag&Drop auf das Mobilgerät kopieren und dabei die Dateiendung in .crt ändern, sodass es 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
  1. Als System vertrauenswürdig machen: Lade das Magisk-Modul MagiskTrustUserCerts (eine .zip-Datei) herunter, per Drag&Drop auf das Telefon übertragen, öffne die Magisk app auf dem Telefon, gehe zum Bereich Modules, klicke auf Install from storage, wähle das .zip-Modul aus und starte nach der Installation das Telefon neu:
  • Nach dem Neustart gehe zu Trusted credentials -> SYSTEM und prüfe, dass das Postswigger-Zertifikat dort vorhanden ist

Alternative: AlwaysTrustUserCerts (Android 7-16 Beta)

Wenn du Android 14+ verwendest (oder ältere Geräte, die Conscrypt Mainline-Updates erhalten haben und jetzt /apex/com.android.conscrypt/cacerts nutzen), automatisiert das Magisk-Modul AlwaysTrustUserCerts das für Systemvertrauen erforderliche Bind-Mounting. Es spiegelt Benutzer-CAs in das Systemvertrauen und injiziert Mounts in die Zygote/app-Namespaces, sodass Apps die Zertifikate sehen, ohne manuelle nsenter-Arbeit.

  1. Installiere die Burp-CA zuerst als user-Zertifikat.
  2. Installiere das Modul und starte neu.
  3. Wenn das Modul eine Auswahl anbietet, bevorzuge --rbind beim Mounten von /system/etc/security/cacerts nach /apex/com.android.conscrypt/cacerts, um sicherzustellen, dass verschachtelte Mounts (von anderen Modulen) sichtbar sind.

Lerne, wie man ein Magisk-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 Veränderung bei der Handhabung systemweit vertrauenswürdiger Certificate Authority (CA)-Zertifikate festgestellt.

Hinweis: Einige Android 12/13 Geräte, die Conscrypt Mainline-Updates erhielten, verwenden bereits /apex/com.android.conscrypt/cacerts. Wenn dieses Verzeichnis auf deinem Gerät existiert, musst du die unten beschriebene gleiche APEX-Injektionstechnik verwenden.

Früher wurden diese Zertifikate in /system/etc/security/cacerts/ gespeichert, waren für Benutzer mit Root-Rechten zugänglich und änderbar, wodurch sie sofort systemweit angewendet werden konnten. 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 beschreibbar neu einzuhängen, 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 beruht darauf, dass der /apex-Mount mit PRIVATE-Propagation konfiguriert ist, was sicherstellt, dass Ä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 dadurch Änderungen an diesem Verzeichnis von anderen Prozessen isoliert.

Trotzdem gibt es einen Workaround für diejenigen, die die systemweit vertrauenswürdigen CA-Zertifikate innerhalb des /apex-Verzeichnisses ändern müssen. Dies beinhaltet ein manuelles Remounten von /apex, um die PRIVATE-Propagation zu entfernen und es damit beschreibbar zu machen. Der Vorgang umfasst das Kopieren des Inhalts von /apex/com.android.conscrypt an einen anderen Ort, das Unmounten des Verzeichnisses /apex/com.android.conscrypt, um die Schreibschutzbeschränkung aufzuheben, 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 wirksam werden, wird empfohlen, den system_server neu zu starten, was effektiv alle Anwendungen neu startet und das System in einen konsistenten Zustand versetzt.

# 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 durch NSEnter

  1. Einrichten eines beschreibbaren Verzeichnisses: Zunächst wird ein beschreibbares Verzeichnis eingerichtet, indem ein tmpfs über das vorhandene non-APEX System-Zertifikatsverzeichnis gemountet wird. Dies wird mit folgendem Befehl erreicht:
mount -t tmpfs tmpfs /system/etc/security/cacerts
  1. Vorbereiten von CA-Zertifikaten: Nach dem Einrichten 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.
  2. Bind Mounting für Zygote: Mit nsenter betritt man den Mount-Namespace von Zygote. Zygote, der Prozess, der für das Starten von Android-Anwendungen verantwortlich ist, erfordert diesen Schritt, damit alle künftig gestarteten Anwendungen die neu konfigurierten CA-Zertifikate verwenden. Der verwendete Befehl ist:

Tipp: Wenn /system/etc/security/cacerts verschachtelte Mounts enthält (häufig bei Magisk-Modulen), verwenden Sie --rbind statt --bind, damit diese Mounts in die App-Namespaces weitergereicht werden.

nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
# If /system/etc/security/cacerts includes nested mounts, prefer --rbind
nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --rbind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

Dies stellt sicher, dass jede neu gestartete App die aktualisierte CA-Zertifikatskonfiguration verwendet.

  1. Änderungen auf bereits laufende Apps anwenden: Um die Änderungen auf bereits laufende Anwendungen anzuwenden, wird erneut nsenter verwendet, um jeweils in den Namespace jeder App einzutreten und einen ähnlichen 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
  1. Alternative Approach - 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 über alle namespaces hinweg propagieren, sodass es nicht nötig ist, jede laufende App einzeln anzusprechen. Diese Methode ist jedoch allgemein weniger bevorzugt, da der Neustart unpraktisch ist.

Referenzen

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Durchsuche den vollständigen HackTricks Training-Katalog nach den Assessment-Tracks (ARTA/GRTA/AzRTA) und Linux Hacking Expert (LHE).

Support HackTricks