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)

Unterstütze HackTricks

• Überprüfe die Abonnementpläne!

• Tritt der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folge uns auf Twitter 🐦 @hacktricks_live.

• Teile Hacking-Tricks, indem du PRs an die HackTricks und HackTricks Cloud GitHub-Repos einreichst.

Websec | Uw Cybersecurity Specialist

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:

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:

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 wird erklärt, dass Sie:

1. 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 zu Zertifikat installieren -> CA-Zertifikat

• Überprüfen Sie, ob das Zertifikat korrekt gespeichert wurde, indem Sie zu Vertrauenswürdige Anmeldeinformationen -> BENUTZER gehen

1. 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 auf Aus 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.

# 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 through 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:

mount -t tmpfs tmpfs /system/etc/security/cacerts

1. 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.

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, benötigt diesen Schritt, um sicherzustellen, dass alle Anwendungen, die fortan gestartet werden, 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.

1. Ä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

1. 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 den stop && 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

• https://httptoolkit.com/blog/android-14-install-system-ca-certificate/

Websec | Uw Cybersecurity Specialist

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Unterstütze HackTricks

• Überprüfe die Abonnementpläne!

• Tritt der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folge uns auf Twitter 🐦 @hacktricks_live.

• Teile Hacking-Tricks, indem du PRs zu den HackTricks und HackTricks Cloud GitHub-Repos einreichst.