Installiere Burp-Zertifikat
Reading time: 8 minutes
tip
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Unterstützen Sie HackTricks
- Überprüfen Sie die Abonnementpläne!
- Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
- Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.
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 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:
C:\Users\<UserName>\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:
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 müssen Sie:
- 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 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 aufVon 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.
# 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
- 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:
mount -t tmpfs tmpfs /system/etc/security/cacerts
- 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 fortan gestarteten Anwendungen die neu konfigurierten CA-Zertifikate verwenden. Der verwendete Befehl ist:
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.
- Ä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:
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
- 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 denstop && 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
tip
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Unterstützen Sie HackTricks
- Überprüfen Sie die Abonnementpläne!
- Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
- Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.