Install Burp Certificate

Websec | Uw Cybersecurity Specialist

Op 'n Virtuele Masjien

Eerstens moet jy die Der sertifikaat van Burp aflaai. Jy kan dit doen in Proxy --> Opsies --> Importeer / Eksporteer CA sertifikaat

Eksporteer die sertifikaat in Der formaat en laat ons transformeer dit na 'n vorm wat Android gaan kan begryp. Let daarop dat om die burp sertifikaat op die Android masjien in AVD te konfigureer jy moet die masjien met die -writable-system opsie hardloop. Byvoorbeeld, jy kan dit soos volg hardloop:

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

Dan, om burp se sertifikaat te konfigureer:

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 herlaai het, sal die burp sertifikaat in gebruik wees!

Gebruik Magisc

As jy jou toestel met Magisc ge-root het (miskien 'n emulator), en jy kan nie volg die vorige stappe om die Burp sertifikaat te installeer nie omdat die lêerstelsel lees-alleen is en jy dit nie weer kan monteer nie, is daar 'n ander manier.

Verduidelik in hierdie video moet jy:

1. Installeer 'n CA sertifikaat: Net sleep&laat die DER Burp sertifikaat verander die uitbreiding na .crt op die mobiele toestel sodat dit in die Downloads-gids gestoor word en gaan na Installeer 'n sertifikaat -> CA sertifikaat

• Kontroleer dat die sertifikaat korrek gestoor is deur na Vertroude geloofsbriewe -> GEBRUIKER te gaan

1. Maak dit Stelsel vertrou: Laai die Magisc module MagiskTrustUserCerts (n .zip lêer) af, sleep&laat dit in die telefoon, gaan na die Magics app in die telefoon na die Modules afdeling, klik op Installeer vanaf stoor, kies die .zip module en sodra dit geïnstalleer is, herlaai die telefoon:

• Na herlaai, gaan na Vertroude geloofsbriewe -> STELSEL en kontroleer of die Postswigger sertifikaat daar is

Post Android 14

In die nuutste Android 14 vrystelling is 'n beduidende verskuiwing waargeneem in die hantering van stelsel-vertroude Sertifikaat Owerheid (CA) sertifikate. Voorheen was hierdie sertifikate in /system/etc/security/cacerts/ gehuisves, toeganklik en aanpasbaar deur gebruikers met wortelregte, wat onmiddellike toepassing oor die stelsel moontlik gemaak het. Met Android 14 is die stoorplek egter na /apex/com.android.conscrypt/cacerts verskuif, 'n gids binne die /apex pad, wat van nature onveranderlik is.

Pogings om die APEX cacerts pad as skryfbaar te monteer, misluk, aangesien die stelsel sulke operasies nie toelaat nie. Selfs pogings om die gids te ontkoppel of te oorlaai met 'n tydelike lêerstelsel (tmpfs) om die onveranderlikheid te omseil, slaag nie; toepassings bly toegang tot die oorspronklike sertifikaatdata, ongeag veranderinge op die lêerstelselniveau. Hierdie veerkragtigheid is te danke aan die /apex monteer wat met PRIVATE propagasie geconfigureer is, wat verseker dat enige aanpassings 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 bekendstelling van toepassingsprosesse met 'n nuwe monteernaamruimte wat 'n private /apex monteer insluit, wat dus veranderinge aan hierdie gids van ander prosesse isoleer.

Nietemin, 'n omseiling bestaan vir diegene wat die stelsel-vertroude CA sertifikate binne die /apex gids moet aanpas. Dit behels die handmatige hermontering van /apex om die PRIVATE propagasie te verwyder, wat dit skryfbaar maak. Die proses sluit in om die inhoud van /apex/com.android.conscrypt na 'n ander plek te kopieer, die /apex/com.android.conscrypt gids te ontkoppel om die lees-alleen beperking te verwyder, en dan die inhoud na hul oorspronklike plek binne /apex te herstel. Hierdie benadering vereis vinnige aksie om stelselinbrake te voorkom. Om stelselsgewys toepassing van hierdie veranderinge te verseker, 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 through NSEnter

1. Stel 'n Skryfbare Gids Op: Aanvanklik word 'n skryfbare gids gevestig deur 'n tmpfs oor die bestaande nie-APEX stelselsertifikaatgids te monteer. Dit word bereik met die volgende opdrag:

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

1. Voorbereiding van CA Sertifikate: Na die opstelling van die skryfbare gids, moet die CA sertifikate wat gebruik gaan word, in hierdie gids gekopieer word. Dit kan behels dat die standaard sertifikate van /apex/com.android.conscrypt/cacerts/ gekopieer word. Dit is noodsaaklik om die toestemmings en SELinux etikette van hierdie sertifikate dienooreenkomstig aan te pas.

2. Bind Mounting vir Zygote: Deur nsenter te gebruik, betree mens die Zygote se monteer naamruimte. Zygote, wat die proses is wat verantwoordelik is vir die bekendstelling van Android toepassings, vereis hierdie stap om te verseker dat alle toepassings wat vanaf nou af begin, die nuut geconfigureerde CA sertifikate 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 toepassing wat begin, sal voldoen aan die opgedateerde CA sertifikaat opstelling.

1. Toepassing van Veranderinge op Loopende Toepassings: Om die veranderinge toe te pas op reeds lopende toepassings, word nsenter weer gebruik om elke toepassing se naamruimte 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

1. Alternatiewe Benadering - Sagte Herlaai: 'n Alternatiewe metode behels die uitvoering van die bind mount op die init proses (PID 1) gevolg deur 'n sagte herlaai van die bedryfstelsel met stop && start opdragte. Hierdie benadering sal die veranderinge oor alle namespaces versprei, wat die behoefte om elke lopende app individueel aan te spreek, vermy. Hierdie metode word egter oor die algemeen minder verkies weens die ongerief van herlaai.

Verwysings

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

Websec | Uw Cybersecurity Specialist