Installeer Burp-sertifikaat

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Blaai deur die volledige HackTricks Training-katalogus vir die assesseringsroetes (ARTA/GRTA/AzRTA) en Linux Hacking Expert (LHE).

Ondersteun HackTricks

Sisteemwye proxy deur ADB

Konfigureer ’n globale HTTP proxy sodat al die apps hul verkeer deur jou interceptor (Burp/mitmproxy) stuur:

# Set proxy (device/emulator must reach your host IP)
adb shell settings put global http_proxy 192.168.1.2:8080

# Clear proxy
adb shell settings put global http_proxy :0

Wenk: In Burp, bind your listener to 0.0.0.0 so devices on the LAN can connect (Proxy -> Options -> Proxy Listeners).

Op ’n Virtuele Masjien

Eerstens moet jy die Der certificate van Burp aflaai. Jy kan dit doen in Proxy –> Options –> Import / Export CA certificate

Export the certificate in Der format en laat ons dit transform na ’n formaat wat Android sal kan begryp. Neem kennis dat om die burp certificate op die Android masjien in AVD te konfigureer jy hierdie masjien met die -writable-system opsie moet run.
Byvoorbeeld kan jy dit soos volg run:

C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system

Dan, om burps sertifikaat te konfigureer, doen:

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

Sodra die machine klaar herbegin het sal die Burp-sertifikaat deur dit gebruik word!

Using Magisk

If you rooted your device with Magisk (maybe an emulator), and you can’t follow the previous steps to install the Burp cert because the filesystem is read-only and you cannot remount it writable, there is another way.

Explained in this video you need to:

  1. Installeer ’n CA-sertifikaat: Sleep en laat val die DER Burp-sertifikaat en verander die uitbreiding na .crt op die mobiele toestel sodat dit in die Downloads-lêer gestoor word en gaan na Install a certificate -> CA certificate
  • Kontroleer dat die sertifikaat korrek gestoor is deur na Trusted credentials -> USER te gaan
  1. Maak dit System trusted: Laai die Magisk-module MagiskTrustUserCerts (‘.zip’ lêer) af, sleep dit na die foon, open die Magisk-app op die foon na die Modules-afdeling, klik op Install from storage, kies die .zip-module en sodra dit geïnstalleer is, herbegin die foon:
  • Nadat jy herbegin het, gaan na Trusted credentials -> SYSTEM en kontroleer dat die Postswigger-sertifikaat daar is

Alternative: AlwaysTrustUserCerts (Android 7-16 Beta)

If you’re on Android 14+ (or on older devices that received Conscrypt Mainline updates and now use /apex/com.android.conscrypt/cacerts), the Magisk module AlwaysTrustUserCerts automates the bind-mounting required for system trust. It mirrors user CAs into system trust and injects mounts into Zygote/app namespaces so apps see the certs without manual nsenter work.

  1. Installeer eers die Burp CA as ’n user-sertifikaat.
  2. Installeer die module en herbegin.
  3. As die module ’n keuse bied, verkies --rbind wanneer jy /system/etc/security/cacerts inbind na /apex/com.android.conscrypt/cacerts sodat geneste mounts (van ander modules) sigbaar bly.

Learn how to create a Magisk module

Kyk na https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437

Post Android 14

In die nuutste Android 14-weergawe is daar ’n beduidende verskuiwing waargeneem in die hantering van system-trusted Certificate Authority (CA) sertifikate.

Note: Some Android 12/13 devices that received Conscrypt Mainline updates already use /apex/com.android.conscrypt/cacerts. If that directory exists on your device, you must use the same APEX injection technique described below.

Voorheen was hierdie sertifikate in /system/etc/security/cacerts/ gehuisves, toeganklik en wysigbaar deur gebruikers met root-privilegies, wat onmiddellike stelselwye toepassing toegelaat het. Met Android 14 is die bergingsplek egter verskuif na /apex/com.android.conscrypt/cacerts, ’n gids binne die /apex-pad, wat per definisie onveranderlik is.

Pogings om die APEX cacerts path as herskryfbaar te remount misluk, aangesien die stelsel sulke operasies nie toelaat nie. Selfs pogings om die gids te unmount of te oorlaai met ’n tydelike lêerstelsel (tmpfs) om die onveranderlikheid te omseil, werk nie; toepassings bly die oorspronklike sertifikaatdata benader ongeag veranderinge op lêerstelselvlak. Hierdie veerkragtigheid is te wyte aan die feit dat die /apex-mount met PRIVATE propagation gekonfigureer is, wat verseker dat enige wysigings binne die /apex-gids nie ander prosesse beïnvloed nie.

Die init-proses van Android, wat die bedryfstelsel opstart, aktiveer ook die Zygote-proses. Hierdie proses is verantwoordelik vir die begin van toepassingsprosesse met ’n nuwe mount-namespace wat ’n private /apex-mount insluit, en sodoende veranderings aan hierdie gids van ander prosesse isoleer.

Nietemin bestaan daar ’n ompad vir dié wat die system-trusted CA-sertifikate binne die /apex-gids moet wysig. Dit behels handmatig die remount van /apex om die PRIVATE propagation te verwyder, sodat dit herskryfbaar word. Die proses sluit in om die inhoud van /apex/com.android.conscrypt na ’n ander ligging te kopieer, die /apex/com.android.conscrypt-gids te unmount om die slegs-lees-beperking te verwyder, en dan die inhoud na hul oorspronklike ligging binne /apex terug te herstel. Hierdie benadering vereis vinnige aksie om stelselongelukke te voorkom. Om seker te maak dat die veranderinge stelselwyd toegepas word, word aanbeveel om die system_server te herbegin, wat effektief al die toepassings herbegin en die stelsel na ’n konsekwente toestand bring.

# 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 deur NSEnter

  1. Instel van ’n Skryfbare Gids: Eerstens word ’n skryfbare gids geskep deur ’n tmpfs bo-op die bestaande non-APEX stelsel-sertifikaatgids te monteer. Dit word bereik met die volgende opdrag:
mount -t tmpfs tmpfs /system/etc/security/cacerts
  1. Voorbereiding van CA-sertifikate: Nadat die skryfbare gids opgestel is, moet die CA-sertifikate wat gebruik gaan word na hierdie gids gekopieer word. Dit kan behels dat die standaardsertifikate vanaf /apex/com.android.conscrypt/cacerts/ gekopieer word. Dit is noodsaaklik om die permissies en SELinux-etikette van hierdie sertifikate ooreenkomstig aan te pas.
  2. Bind-mounting vir Zygote: Deur nsenter te gebruik, betree mens die mount-namespace van Zygote. Zygote, die proses wat verantwoordelik is vir die begin van Android-toepassings, vereis hierdie stap om te verseker dat alle toepassings wat van nou af begin die nuut gekonfigureerde CA-sertifikate gebruik. Die opdrag wat gebruik word, is:

Wenk: As /system/etc/security/cacerts geneste mounts bevat (algemeen met Magisk-modules), gebruik --rbind in plaas van --bind sodat daardie mounts in app namespaces voortplant.

nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
# If /system/etc/security/cacerts includes nested mounts, prefer --rbind
nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --rbind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

Dit verseker dat elke nuwe app wat gestart word, aan die opgedateerde CA-sertifikate-opstelling sal voldoen.

  1. Veranderings op lopende apps toepas: Om die veranderings op reeds lopende toepassings toe te pas, word nsenter weer gebruik om elke app se namespace afsonderlik te betree en ’n soortgelyke bind mount uit te voer. Die nodige opdrag is:
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
  1. Alternatiewe benadering - Sagte herbegin: ’n Alternatiewe metode behels om die bind mount op die init-proses (PID 1) uit te voer, gevolg deur ’n sagte herbegin van die bedryfstelsel met die stop && start-opdragte. Hierdie benadering sal die veranderinge oor alle namespaces versprei, en so die behoefte verhoed om elke lopende app individueel te hanteer. Hierdie metode word egter oor die algemeen minder verkies weens die ongerief van herbegin.

Verwysings

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Blaai deur die volledige HackTricks Training-katalogus vir die assesseringsroetes (ARTA/GRTA/AzRTA) en Linux Hacking Expert (LHE).

Ondersteun HackTricks