# Burp-Zertifikat installieren
Erlernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)! Andere Möglichkeiten, HackTricks zu unterstützen: * Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks im PDF-Format herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)! * Holen Sie sich das [**offizielle PEASS & HackTricks-Merch**](https://peass.creator-spring.com) * Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family) * **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.** * **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories senden.
## Auf einer virtuellen Maschine Zunächst müssen Sie das Der-Zertifikat von Burp herunterladen. Dies können Sie unter _**Proxy**_ --> _**Optionen**_ --> _**CA-Zertifikat importieren/exportieren**_ tun ![](<../../.gitbook/assets/image (367).png>) **Exportieren Sie das Zertifikat im Der-Format** und wandeln Sie es in eine Form um, die **Android** verstehen kann. Beachten Sie, dass **um das Burp-Zertifikat auf der Android-Maschine in AVD zu konfigurieren**, Sie diese Maschine **mit** der Option **`-writable-system`** starten müssen.\ Sie können sie beispielsweise wie folgt starten: {% code overflow="wrap" %} ```bash C:\Users\\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system ``` {% endcode %} Dann, um **das Zertifikat von Burp zu konfigurieren**, führen Sie Folgendes aus: {% code overflow="wrap" %} ```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 ``` {% endcode %} Nachdem die **Maschine neu gestartet** wurde, wird das Burp-Zertifikat von ihr verwendet! ## Verwendung von Magisc Wenn Sie Ihr Gerät mit Magisc **gerootet haben** (vielleicht einen Emulator) und Sie den vorherigen **Schritten** zum Installieren des Burp-Zertifikats nicht folgen können, weil das **Dateisystem schreibgeschützt ist** und Sie es nicht beschreibbar neu einhängen können, gibt es einen anderen Weg. Wie in [**diesem Video**](https://www.youtube.com/watch?v=qQicUW0svB8) erklärt, müssen Sie: 1. **Installieren Sie ein CA-Zertifikat**: Ziehen Sie einfach das DER-Burp-Zertifikat **mit Änderung der Erweiterung** in `.crt` auf das Mobilgerät, sodass es im Download-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. **Machen Sie es systemweit vertrauenswürdig**: Laden Sie das Magisc-Modul [MagiskTrustUserCerts](https://github.com/NVISOsecurity/MagiskTrustUserCerts) (eine .zip-Datei) herunter, **ziehen Sie es** auf das Telefon, gehen Sie in der Magics-App auf dem Telefon zum Abschnitt **`Module`**, klicken Sie auf **`Von Speicher installieren`**, wählen Sie das `.zip`-Modul aus und nach der Installation **starten Sie** das Telefon neu:
* Nach dem Neustart gehen Sie zu `Vertrauenswürdige Anmeldeinformationen` -> `SYSTEM` und überprüfen, ob das Postswigger-Zertifikat vorhanden ist
## Nach Android 14 Mit der neuesten Veröffentlichung von Android 14 wurde eine signifikante Veränderung im Umgang mit systemweit vertrauenswürdigen Zertifizierungsstellen (CA) beobachtet. Zuvor waren diese Zertifikate in **`/system/etc/security/cacerts/`** untergebracht, zugänglich und modifizierbar von Benutzern mit Root-Rechten, 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`**-Pfads, der von Natur aus unveränderlich ist. Versuche, den **APEX-Cacerts-Pfad** als beschreibbar neu einzuhängen, scheitern, da das System solche Operationen nicht zulässt. Selbst der Versuch, das Verzeichnis mit einem temporären Dateisystem (tmpfs) zu demontieren oder zu überlagern, umgeht nicht die Unveränderlichkeit; Anwendungen greifen weiterhin auf die ursprünglichen Zertifikatsdaten zu, unabhängig von Änderungen auf Dateisystemebene. Diese Widerstandsfähigkeit beruht darauf, dass das **`/apex`**-Mount mit PRIVATE-Propagation konfiguriert ist, was sicherstellt, dass Änderungen innerhalb des **`/apex`**-Verzeichnisses keine Auswirkungen auf andere Prozesse haben. Die Initialisierung von Android beinhaltet den `init`-Prozess, der beim Starten des Betriebssystems auch den Zygote-Prozess initiiert. Dieser Prozess ist dafür verantwortlich, Anwendungsprozesse mit einem neuen Mount-Namespace zu starten, der ein privates **`/apex`**-Mount enthält, wodurch Änderungen in diesem Verzeichnis von anderen Prozessen isoliert werden. Dennoch existiert eine Lösung für diejenigen, die die systemweit vertrauenswürdigen CA-Zertifikate im **`/apex`**-Verzeichnis ändern müssen. Dies beinhaltet das manuelle Neu-Einhängen 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 Aushängen des **`/apex/com.android.conscrypt`**-Verzeichnisses, um die schreibgeschützte Einschränkung zu beseitigen, und dann das Wiederherstellen des Inhalts an ihren ursprünglichen Ort innerhalb von **`/apex`**. Dieser Ansatz erfordert schnelles Handeln, um Systemabstürze zu vermeiden. Um die systemweite Anwendung dieser Änderungen sicherzustellen, wird empfohlen, den `system_server` neu zu starten, was alle Anwendungen neu startet und das System in einen konsistenten Zustand versetzt. ```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. **Einrichten 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. **Vorbereitung von CA-Zertifikaten**: Nachdem das beschreibbare Verzeichnis eingerichtet wurde, sollten die CA-Zertifikate, die man verwenden möchte, in dieses Verzeichnis kopiert werden. Dies kann das Kopieren der Standardzertifikate von `/apex/com.android.conscrypt/cacerts/` umfassen. Es ist wichtig, die Berechtigungen und SELinux-Labels dieser Zertifikate entsprechend anzupassen. 3. **Bind-Mounting für Zygote**: Unter Verwendung von `nsenter` tritt man in den Mount-Namensraum von Zygote ein. Da Zygote der Prozess ist, der für das Starten von Android-Anwendungen verantwortlich ist, ist dieser Schritt erforderlich, um sicherzustellen, dass alle anschließend initiierten Anwendungen die neu konfigurierten CA-Zertifikate verwenden. Der verwendete Befehl lautet: ```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 neue App, die gestartet wird, der aktualisierten CA-Zertifikatskonfiguration entspricht. 4. **Änderungen auf laufende Apps anwenden**: Um die Änderungen auf bereits laufende Anwendungen anzuwenden, wird erneut `nsenter` verwendet, um in den Namespace jeder App einzutreten und einen ähnlichen Bind-Mount durchzuführen. Der erforderliche Befehl lautet: ```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**: Eine alternative Methode besteht darin, das 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 und die Notwendigkeit beseitigen, jede laufende App einzeln anzusprechen. Allerdings wird diese Methode im Allgemeinen weniger bevorzugt, aufgrund der Unannehmlichkeiten eines Neustarts. ## Referenzen * [https://httptoolkit.com/blog/android-14-install-system-ca-certificate/](https://httptoolkit.com/blog/android-14-install-system-ca-certificate/)