Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/mobile-pentesting/android-app-pentesting/install-burp-certificate.md

12 KiB
Raw Blame History

Installeer Burp-sertifikaat

Leer AWS-hacking vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Op 'n Virtuele Masjien

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

Voer die sertifikaat uit in Der-formaat en laat ons dit omskep na 'n vorm wat Android gaan verstaan. Let daarop dat om die burp-sertifikaat op die Android-masjien in AVD te konfigureer jy die masjien met die -writable-system-opsie moet hardloop.
Byvoorbeeld kan jy dit so laat loop:

{% 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 %}

Vervolgens, om Burp se sertifikaat te konfigureer, doen die volgende:

{% 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 %}

Sodra die rekenaar klaar herlaai het, sal die burp-sertifikaat deur dit gebruik word!

Gebruik van 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 nie omdat die lêersisteem skryfbeskerming is en jy dit nie kan oorskryf nie, is daar 'n ander manier.

Uitgelê in hierdie video moet jy:

  1. Installeer 'n CA-sertifikaat: Net sleep en laat val die DER Burp-sertifikaat terwyl jy die uitbreiding verander na .crt op die mobiele toestel sodat dit gestoor word in die Aflaaibestand en gaan na Installeer 'n sertifikaat -> CA-sertifikaat
  • Kontroleer dat die sertifikaat korrek gestoor is deur te gaan na Vertroude geloofsbriewe -> GEBRUIKER
  1. Maak dit Sisteem vertrou: Laai die Magisc-module MagiskTrustUserCerts af (‘n .zip-lêer), sleep en laat val dit op die foon, gaan na die Magics-toep op die foon na die Modules-afdeling, klik op Installeer vanaf stoor, kies die .zip-module en sodra dit geïnstalleer is, herlaai die foon:
  • Na herlaaiing, gaan na Vertroude geloofsbriewe -> SISTEEM en kontroleer of die Postswigger-sertifikaat daar is

Na Android 14

In die nuutste Android 14 vrystelling is 'n beduidende skuif waargeneem in die hantering van die sertifisering van die sisteem-vertroude Certificate Authority (CA) sertifikate. Voorheen was hierdie sertifikate gehuisves in /system/etc/security/cacerts/, toeganklik en aanpasbaar deur gebruikers met wortelregte, wat onmiddellike toepassing oor die hele stelsel moontlik gemaak het. Met Android 14 is die berging van die ligging verplaas na /apex/com.android.conscrypt/cacerts, 'n gids binne die /apex-pad, wat van nature onveranderlik is.

Pogings om die APEX cacerts-pad as skryfbaar te hermonteer, word met mislukking ontmoet, aangesien die stelsel sulke operasies nie toelaat nie. Selfs pogings om die gids te ontmonteer of te oorlê met 'n tydelike lêersisteem (tmpfs) omseil nie die onveranderlikheid nie; programme bly voortgaan om die oorspronklike sertifikaatdata te benader ongeag veranderinge op die lêersisteemvlak. Hierdie veerkragtigheid is te danke aan die /apex-berg wat gekonfigureer is met PRIVATE propagasie, 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 begin van aansoekprosesse met 'n nuwe bergnaamruimte wat 'n private /apex-berg insluit, wat veranderinge aan hierdie gids van ander prosesse isoleer.

Nietemin bestaan daar 'n omweg vir diegene wat die sisteem-vertroude CA-sertifikate binne die /apex-gids wil wysig. Dit behels die handmatige hermonteer van /apex om die PRIVATE propagasie te verwyder, wat dit skryfbaar maak. Die proses behels die kopie van die inhoud van /apex/com.android.conscrypt na 'n ander plek, die ontmonteer van die /apex/com.android.conscrypt-gids om die skryfbeskerming te verwyder, en dan die herstel van die inhoud na hul oorspronklike plek binne /apex. Hierdie benadering vereis vinnige optrede om stelselstortings te voorkom. Om te verseker dat hierdie veranderinge wydverspreid in die stelsel toegepas word, word dit aanbeveel om die system_server te herlaai, wat alle aansoeke herlaai 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 opgestel deur 'n tmpfs oor die bestaande nie-APEX-sisteemsertifikaatgids te bind. Dit word bereik met die volgende bevel:
mount -t tmpfs tmpfs /system/etc/security/cacerts
  1. Voorbereiding van CA-sertifikate: Na die opstel van die skryfbare gids, moet die CA-sertifikate wat jy van plan is om te gebruik, in hierdie gids gekopieer word. Dit mag die kopieer van die verstek sertifikate vanaf /apex/com.android.conscrypt/cacerts/ insluit. Dit is noodsaaklik om die regte toestemmings en SELinux-etikette van hierdie sertifikate dienooreenkomstig aan te pas.
  2. Bind Montering vir Zygote: Deur nsenter te gebruik, tree 'n persoon die Zygote se bergnaamspasie binne. Zygote, as die proses verantwoordelik vir die begin van Android-toepassings, vereis hierdie stap om te verseker dat alle toepassings wat hierna geïnisieer word, die nuut gekonfigureerde CA-sertifikate gebruik. Die gebruikte bevel 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, sal voldoen aan die opgedateerde CA-sertifikaatopstelling.

  1. Veranderinge Toepas op Lopende Apps: Om die veranderinge op reeds lopende toepassings toe te pas, word nsenter weer gebruik om in elke toepassing se namespace individueel in te gaan en 'n soortgelyke bindmount uit te voer. Die nodige bevel 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 uitvoer van die bind mount op die init proses (PID 1) gevolg deur 'n sagte herlaai van die bedryfstelsel met die stop && start bevele. Hierdie benadering sal die veranderinge oor al die namespaces versprei, wat die noodsaaklikheid om elke lopende program individueel aan te spreek, vermy. Hierdie metode word egter gewoonlik minder verkies weens die ongerief van die herlaai.

Verwysings

Leer AWS hak vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun: