12 KiB
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!
- Holen Sie sich das offizielle PEASS & HackTricks-Merch
- Entdecken Sie The PEASS Family, unsere Sammlung exklusiver NFTs
- Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @carlospolopm.
- Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die HackTricks und 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
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" %}
C:\Users\<UserName>\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" %}
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 erklärt, müssen Sie:
- Installieren Sie ein CA-Zertifikat: Ziehen Sie einfach das DER-Burp-Zertifikat mit Änderung der Erweiterung in
.crtauf das Mobilgerät, sodass 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->BENUTZERgehen
- Machen Sie es systemweit vertrauenswürdig: Laden Sie das Magisc-Modul 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 aufVon 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->SYSTEMund ü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.
# 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
- 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
- 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. - Bind-Mounting für Zygote: Unter Verwendung von
nsentertritt 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
Dies stellt sicher, dass jede neue App, die gestartet wird, der aktualisierten CA-Zertifikatskonfiguration entspricht.
- Änderungen auf laufende Apps anwenden: Um die Änderungen auf bereits laufende Anwendungen anzuwenden, wird erneut
nsenterverwendet, um in den Namespace 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
- 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 Befehlenstop && 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.