German - Ht
HackTricks Training Twitter Linkedin Sponsor

Install Burp Certificate

Erlernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

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

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 so starten:

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, führen Sie Folgendes aus:

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

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 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, 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. Machen Sie es systemvertraut: Laden Sie das Magisc-Modul MagiskTrustUserCerts (eine .zip-Datei) herunter, ziehen Sie es auf das Telefon, gehen Sie zur 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

Bei der neuesten Veröffentlichung von Android 14 wurde eine signifikante Veränderung im Umgang mit systemvertrauten 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 Pfads /apex, das 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 Versuche, das Verzeichnis mit einem temporären Dateisystem (tmpfs) zu demontieren 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 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 an diesem Verzeichnis von anderen Prozessen isoliert werden.

Dennoch gibt es eine Lösung für diejenigen, die die systemvertrauten 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 effektiv neu startet und das System in einen konsistenten Zustand versetzt.

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

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

  1. 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/ beinhalten. Es ist wichtig, die Berechtigungen und SELinux-Label dieser Zertifikate entsprechend anzupassen.

  2. 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:

nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

Das stellt sicher, dass jede neue App, die gestartet wird, den aktualisierten CA-Zertifikats-Setup einhält.

  1. Änderungen auf laufende Apps anwenden: Um die Änderungen auf bereits laufende Anwendungen anzuwenden, wird erneut nsenter verwendet, um in den Namensraum jeder App einzutreten und einen ähnlichen Bind-Mount durchzuführen. Der erforderliche Befehl lautet:

nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

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

Erlernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

PreviousGoogle CTF 2018 - Shall We Play a Game?NextIntent Injection

Last updated