Installeer Burp-sertifikaat

Reading time: 9 minutes

Stelselwye proxy via ADB

Konfigureer 'n globale HTTP-proxy sodat alle apps verkeer deur jou interceptor (Burp/mitmproxy) gaan:

# 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

Tip: In Burp bind jou listener aan 0.0.0.0 sodat toestelle op die LAN kan koppel (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 kom ons transformeer dit na 'n vorm wat Android gaan kan begryp. Neem kennis dat in order to configure the burp certificate on the Android machine in AVD jy hierdie masjien moet run with die -writable-system opsie.
Byvoorbeeld kan jy dit soos volg begin:

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 masjien klaar herbegin het sal die Burp-sertifikaat deur dit gebruik word!

Using Magisc

As jy jou toestel met Magisc geroot het (miskien 'n emulator), en jy kan nie die vorige stappe volg om die Burp-sertifikaat te installeer omdat die lêerstelsel is read-only en jy dit nie na skryfbaar kan heraanmerk nie, is daar 'n ander manier.

Soos verduidelik in this video moet jy:

1. Install a CA certificate: Just drag&drop the DER Burp certificate changing the extension to .crt in the mobile so it's stored in the Downloads folder and go to Install a certificate -> CA certificate

• Kontroleer dat die sertifikaat korrek gestoor is deur na Trusted credentials -> USER te gaan

2. Make it System trusted: Download the Magisc module MagiskTrustUserCerts (a .zip file), drag&drop it in the phone, go to the Magics app in the phone to the Modules section, click on Install from storage, select the .zip module and once installed reboot the phone:

• Na die herbegin, gaan na Trusted credentials -> SYSTEM en kontroleer of die Postswigger-sertifikaat daar is

Learn how to create a Magisc module

Check 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 vrystelling is daar 'n beduidende verskuiwing in die hantering van stelsel-vertroude Certificate Authority (CA) sertifikate. Voorheen is hierdie sertifikate in /system/etc/security/cacerts/ gehou, toeganklik en veranderbaar deur gebruikers met root-regte, wat onmiddellike toepassing oor die stelsel toegelaat het. Met Android 14 is die stoorplek egter verskuif na /apex/com.android.conscrypt/cacerts, 'n gids binne die /apex-pad, wat van aard onveranderlik is.

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

Die inisialisering van Android behels die init-proses wat, wanneer die bedryfstelsel begin, ook die Zygote-proses inisieer. Hierdie proses is verantwoordelik vir die loods van toepassingsprosesse met 'n nuwe mount namespace wat 'n private /apex-mount insluit, en sodoende veranderinge aan hierdie gids van ander prosesse isoleer.

Nietemin bestaan daar 'n workaround vir dié wat die stelsel-vertroude CA-sertifikate binne die /apex-gids wil wysig. Dit behels die handmatige heraanmerking van /apex om die PRIVATE propagation te verwyder, sodat dit skryfbaar 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 read-only beperking op te hef, en daarna die inhoud terug te sit na hul oorspronklike ligging binne /apex. Hierdie benadering vereis vinnige optrede om stelselbotsings te vermy. Om te verseker dat die veranderinge stelselwyd toegepas word, word dit aanbeveel om die system_server te herbegin, wat effektief alle 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. Opstel van 'n Skryfbare Gids: Aanvanklik word 'n skryfbare gids geskep deur 'n tmpfs oor die bestaande non-APEX stelsel sertifikaatgids te mount. Dit word bereik met die volgende opdrag:

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

2. Voorbereiding van CA certificates: Na die opstel van die skryfbare gids moet die CA certificates wat jy wil gebruik na hierdie gids gekopieer word. Dit kan behels dat jy die standaard sertifikate van /apex/com.android.conscrypt/cacerts/ kopieer. Dit is noodsaaklik om die toestemmings en SELinux-labels van hierdie sertifikate dienooreenkomstig aan te pas.
3. Bind Mounting vir Zygote: Deur nsenter te gebruik, betree 'n mens Zygote se mount namespace. 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 certificates gebruik. Die opdrag wat gebruik word is:

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

Dit verseker dat elke nuwe app wat begin, die opgedateerde CA certificates-opstelling sal volg.

4. Wysigings op lopende apps toepas: Om die wysigings op reeds lopende apps toe te pas, word nsenter weer gebruik om elke app se namespace individueel binne te gaan 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

5. 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-kommando's. Hierdie benadering sal die veranderinge oor alle namespaces toepas, en die behoefte om elke lopende app individueel aan te spreek, vermy. Hierdie metode is egter oor die algemeen minder verkies weens die ongerief van herbegin.

References

• Android 14: Install a system CA certificate on a rooted device
• Build a Repeatable Android Bug Bounty Lab: Emulator vs Magisk, Burp, Frida, and Medusa