# Installiere Burp-Zertifikat {{#include ../../banners/hacktricks-training.md}} ## Auf einer virtuellen Maschine Zuerst musst du das Der-Zertifikat von Burp herunterladen. Du kannst dies in _**Proxy**_ --> _**Optionen**_ --> _**CA-Zertifikat importieren/exportieren**_ ![](<../../images/image (367).png>) **Exportiere das Zertifikat im Der-Format** und lass uns **es** in eine Form **transformieren**, die **Android** **verstehen** kann. Beachte, dass du **um das Burp-Zertifikat auf der Android-Maschine in AVD zu konfigurieren**, diese Maschine **mit** der **`-writable-system`** Option **ausführen** musst.\ Zum Beispiel kannst du es so ausführen: ```bash C:\Users\\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system ``` Dann, um **das Zertifikat von Burp zu konfigurieren, tun Sie**: ```bash 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 mit dem Neustart fertig ist**, wird das Burp-Zertifikat verwendet! ## Verwendung von Magisc Wenn Sie Ihr **Gerät mit Magisc gerootet haben** (vielleicht ein Emulator) und Sie die vorherigen **Schritte** zur Installation des Burp-Zertifikats nicht **befolgen können**, weil das **Dateisystem schreibgeschützt** ist und Sie es nicht beschreibbar remounten können, gibt es einen anderen Weg. In [**diesem Video**](https://www.youtube.com/watch?v=qQicUW0svB8) müssen Sie: 1. **Ein CA-Zertifikat installieren**: Ziehen Sie einfach das DER Burp-Zertifikat **und ändern Sie die Erweiterung** in `.crt` auf dem Mobilgerät, sodass es im Downloads-Ordner gespeichert wird, und gehen Sie zu `Zertifikat installieren` -> `CA-Zertifikat`
- Überprüfen Sie, ob das Zertifikat korrekt gespeichert wurde, indem Sie zu `Vertrauenswürdige Anmeldeinformationen` -> `BENUTZER` gehen
2. **Es systemvertrauenswürdig machen**: Laden Sie das Magisc-Modul [MagiskTrustUserCerts](https://github.com/NVISOsecurity/MagiskTrustUserCerts) (eine .zip-Datei) herunter, **ziehen Sie es** auf das Telefon, gehen Sie zur **Magics-App** auf dem Telefon in den **`Module`**-Bereich, klicken Sie auf **`Von Speicher installieren`**, wählen Sie das `.zip`-Modul aus und starten Sie das Telefon nach der Installation **neu**:
- Nach dem Neustart gehen Sie zu `Vertrauenswürdige Anmeldeinformationen` -> `SYSTEM` und überprüfen Sie, ob das Postswigger-Zertifikat vorhanden ist
## Nach Android 14 In der neuesten Android 14-Version wurde ein signifikanter Wandel im Umgang mit systemvertrauenswürdigen Zertifizierungsstellen (CA)-Zertifikaten beobachtet. Zuvor waren diese Zertifikate in **`/system/etc/security/cacerts/`** untergebracht, die von Benutzern mit Root-Rechten zugänglich und modifizierbar waren, was eine sofortige Anwendung im gesamten System ermöglichte. Mit Android 14 wurde der Speicherort jedoch in **`/apex/com.android.conscrypt/cacerts`** verschoben, ein Verzeichnis innerhalb des **`/apex`**-Pfades, das von Natur aus unveränderlich ist. Versuche, den **APEX cacerts-Pfad** als beschreibbar zu remounten, scheitern, da das System solche Operationen nicht zulässt. Selbst Versuche, das Verzeichnis mit einem temporären Dateisystem (tmpfs) zu unmounten oder zu überlagern, umgehen nicht die Unveränderlichkeit; Anwendungen greifen weiterhin auf die ursprünglichen Zertifikatsdaten zu, unabhängig von Änderungen auf Dateisystemebene. Diese Widerstandsfähigkeit ist darauf zurückzuführen, dass die **`/apex`**-Einbindung mit PRIVATE-Propagation konfiguriert ist, was sicherstellt, dass Ä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 initiiert. Dieser Prozess ist verantwortlich für das Starten von Anwendungsprozessen mit einem neuen Einhänge-Namensraum, der eine private **`/apex`**-Einbindung umfasst, wodurch Änderungen an diesem Verzeichnis von anderen Prozessen isoliert werden. Dennoch gibt es einen Workaround für diejenigen, die die systemvertrauenswürdigen CA-Zertifikate im **`/apex`**-Verzeichnis ändern müssen. Dies beinhaltet das manuelle Remounten von **`/apex`**, um die PRIVATE-Propagation zu entfernen und es beschreibbar zu machen. Der Prozess umfasst das Kopieren des Inhalts von **`/apex/com.android.conscrypt`** an einen anderen Ort, das Unmounten des **`/apex/com.android.conscrypt`**-Verzeichnisses, um die schreibgeschützte Einschränkung zu beseitigen, und dann das Wiederherstellen des Inhalts an seinen 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. ```bash # 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. **Einrichtungs eines beschreibbaren Verzeichnisses**: Zunächst wird ein beschreibbares Verzeichnis eingerichtet, indem ein `tmpfs` über das vorhandene nicht-APEX-Systemzertifikatsverzeichnis gemountet wird. Dies wird mit dem folgenden Befehl erreicht: ```bash mount -t tmpfs tmpfs /system/etc/security/cacerts ``` 2. **Vorbereiten der CA-Zertifikate**: Nach der Einrichtung des beschreibbaren Verzeichnisses sollten die CA-Zertifikate, die man verwenden möchte, 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` betritt man den Mount-Namespace von Zygote. Zygote, der Prozess, der für das Starten von Android-Anwendungen verantwortlich ist, benötigt diesen Schritt, um sicherzustellen, dass alle fortan gestarteten Anwendungen die neu konfigurierten CA-Zertifikate verwenden. Der verwendete Befehl ist: ```bash 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 den aktualisierten CA-Zertifikats-Setup entspricht. 4. **Änderungen auf laufende Apps anwenden**: Um die Änderungen auf bereits laufende Anwendungen anzuwenden, wird `nsenter` erneut verwendet, um in den Namespace jeder App einzutreten und eine ähnliche Bind-Mount durchzuführen. Der notwendige Befehl ist: ```bash nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts ``` 5. **Alternative Ansatz - Soft Reboot**: Ein alternativer Ansatz besteht darin, das Bind-Mount auf dem `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 propagieren und die Notwendigkeit vermeiden, jede laufende App einzeln anzusprechen. Dieser Ansatz wird jedoch im Allgemeinen weniger bevorzugt, da das Neustarten unpraktisch ist. ## References - [https://httptoolkit.com/blog/android-14-install-system-ca-certificate/](https://httptoolkit.com/blog/android-14-install-system-ca-certificate/) {{#include ../../banners/hacktricks-training.md}}