Install Burp Certificate
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Auf einer Virtuellen Maschine
Zuerst musst du das Der-Zertifikat von Burp herunterladen. Du kannst dies in Proxy --> Optionen --> CA-Zertifikat importieren/exportieren
Exportiere das Zertifikat im Der-Format und lass uns es umwandeln, damit Android es 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:
Dann, um das Zertifikat von Burp zu konfigurieren:
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 wird erklärt, dass Sie:
Ein CA-Zertifikat installieren: Ziehen Sie einfach das DER Burp-Zertifikat und ändern Sie die Erweiterung in
.crt
auf dem Mobilgerät, damit es im Download-Ordner gespeichert wird, und gehen Sie zuZertifikat installieren
->CA-Zertifikat
Überprüfen Sie, ob das Zertifikat korrekt gespeichert wurde, indem Sie zu
Vertrauenswürdige Anmeldeinformationen
->BENUTZER
gehen
Es systemvertrauenswürdig machen: Laden Sie das Magisc-Modul 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 aufAus 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 PRIVATEN Propagation konfiguriert ist, was sicherstellt, dass Änderungen im /apex
-Verzeichnis 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 Einbindungs-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 die 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.
Bind-mounting through NSEnter
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:
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.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 Anwendungen, die fortan gestartet werden, die neu konfigurierten CA-Zertifikate verwenden. Der verwendete Befehl ist:
Dies stellt sicher, dass jede neu gestartete App den aktualisierten CA-Zertifikats-Setup entspricht.
Ä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:
Alternative Methode - Soft Reboot: Eine alternative Methode besteht darin, das Bind-Mount auf dem
init
-Prozess (PID 1) durchzuführen, gefolgt von einem Soft-Reboot des Betriebssystems mit denstop && start
-Befehlen. Dieser Ansatz würde die Änderungen über alle Namespaces propagieren und die Notwendigkeit vermeiden, jede laufende App einzeln anzusprechen. Diese Methode wird jedoch im Allgemeinen weniger bevorzugt, da der Neustart unpraktisch ist.
Referenzen
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Last updated