Instalirajte Burp sertifikat

Tip

Nauči i vežbaj AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Nauči i vežbaj GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Nauči i vežbaj Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Pregledaj kompletan HackTricks Training katalog za assessment tracks (ARTA/GRTA/AzRTA) i Linux Hacking Expert (LHE).

Podrži HackTricks

Sistemski proxy putem ADB-a

Konfigurišite globalni HTTP proxy tako da sav saobraćaj aplikacija prolazi kroz vaš interceptor (Burp/mitmproxy):

# 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

Savet: U Burp podesite listener da sluša na 0.0.0.0 tako da uređaji na LAN-u mogu da se povežu (Proxy -> Options -> Proxy Listeners).

Na virtuelnoj mašini

Prvo treba da preuzmete Der sertifikat iz Burp-a. To možete uraditi u Proxy –> Options –> Import / Export CA certificate

Izvezite sertifikat u Der formatu i hajde da ga pretvorimo u oblik koji će Android moći da razume. Imajte na umu da, kako biste konfigurisali burp sertifikat na Android mašini u AVD, morate pokrenuti tu mašinu sa opcijom -writable-system.
Na primer, možete je pokrenuti ovako:

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

Zatim, da biste konfigurisali burps certificate, uradite:

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

Once the machine finish rebooting the Burp certificate will be in use by it!

Korišćenje Magisk-a

Ako ste rooted your device with Magisk (možda emulator), i can’t follow prethodne steps za instalaciju Burp cert zato što je filesystem is read-only i ne možete da ga remount-ujete kao writable, postoji drugi način.

Objašnjeno u this video potrebno je da:

  1. Install a CA certificate: Jednostavno drag&drop DER Burp certificate menjajući ekstenziju u .crt na mobilnom uređaju tako da bude smešten u Downloads folder i idite na Install a certificate -> CA certificate
  • Proverite da li je sertifikat ispravno sačuvan odlaskom na Trusted credentials -> USER
  1. Make it System trusted: Preuzmite Magisk modul MagiskTrustUserCerts (a .zip file), drag&drop ga na telefon, otvorite Magisk app na telefonu u sekciju Modules, kliknite na Install from storage, izaberite .zip modul i kada je instaliran reboot telefon:
  • Nakon reboot-ovanja, idite na Trusted credentials -> SYSTEM i proverite da li je Postswigger cert prisutan

Alternativa: AlwaysTrustUserCerts (Android 7-16 Beta)

Ako ste na Android 14+ (ili na starijim uređajima koji su dobili Conscrypt Mainline update i sada koriste /apex/com.android.conscrypt/cacerts), Magisk modul AlwaysTrustUserCerts automatizuje bind-mounting potreban za system trust. On preslikava user CA u system trust i ubacuje mount-ove u Zygote/app namespaces tako da aplikacije vide sertifikate bez ručnog nsenter rada.

  1. Instalirajte Burp CA prvo kao user cert.
  2. Instalirajte modul i reboot-ujte.
  3. Ako modul nudi opciju, preferirajte --rbind prilikom mount-ovanja /system/etc/security/cacerts u /apex/com.android.conscrypt/cacerts kako biste osigurali vidljivost ugnježdenih mount-ova (od drugih modula).

Naučite kako kreirati Magisk modul

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

Post Android 14

U najnovijem Android 14 izdanju primećen je značajan pomak u načinu rukovanja system-trusted Certificate Authority (CA) sertifikatima.

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.

Ranije su ovi sertifikati bili smešteni u /system/etc/security/cacerts/, dostupni i izmenljivi korisnicima sa root privilegijama, što je omogućavalo njihovu trenutnu primenu kroz ceo sistem. Međutim, sa Android 14, mesto za skladištenje je premesteno u /apex/com.android.conscrypt/cacerts, direktorijum unutar /apex puta, koji je po prirodi immutable.

Pokušaji da se APEX cacerts put učini writable remount-ovanjem završavaju neuspehom, jer sistem ne dozvoljava takve operacije. Čak i pokušaji da se unmount-uje ili overlay-uje direktorijum privremenim fajl sistemom (tmpfs) ne zaobilaze immutable svojstvo; aplikacije nastavljaju da koriste originalne podatke sertifikata bez obzira na promene na nivou fajl sistema. Ova otpornost je posledica toga što je /apex mount konfigurisana sa PRIVATE propagation, što osigurava da bilo kakve izmene unutar /apex direktorijuma ne utiču na druge procese.

Inicijalizacija Android-a uključuje init proces, koji pri pokretanju operativnog sistema takođe pokreće Zygote proces. Ovaj proces je odgovoran za pokretanje application procesa sa novim mount namespace-om koji uključuje privatni /apex mount, čime se izoluje promene u ovom direktorijumu od drugih procesa.

Ipak, postoji workaround za one kojima je potrebno da izmene system-trusted CA sertifikate unutar /apex direktorijuma. To podrazumeva ručno remount-ovanje /apex kako bi se uklonila PRIVATE propagation, čime se direktorijum čini writable. Proces uključuje kopiranje sadržaja /apex/com.android.conscrypt na drugo mesto, unmount-ovanje /apex/com.android.conscrypt direktorijuma da bi se uklonilo read-only ograničenje, i zatim vraćanje sadržaja na originalnu lokaciju unutar /apex. Ovaj pristup zahteva brzu akciju kako bi se izbegli sistemski crash-ovi. Da bi se osigurala sistemska primena ovih izmena, preporučuje se restartovanje system_server, što efikasno restartuje sve aplikacije i dovodi sistem u konzistentno stanje.

# 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. Podešavanje direktorijuma sa pravom pisanja: Prvo se uspostavlja direktorijum u koji se može pisati tako što se montira tmpfs preko postojećeg non-APEX sistemskog direktorijuma sertifikata. To se postiže sledećom komandom:
mount -t tmpfs tmpfs /system/etc/security/cacerts

  1. Preparing CA Certificates: Nakon podešavanja direktorijuma koji dozvoljava pisanje, CA sertifikate koje želite da koristite treba kopirati u ovaj direktorijum. To može uključivati kopiranje podrazumevanih sertifikata iz /apex/com.android.conscrypt/cacerts/. Važno je odgovarajuće podesiti permisije i SELinux labele tih sertifikata.

  2. Bind Mounting for Zygote: Korišćenjem nsenter ulazi se u mount namespace Zygote-a. Zygote, proces odgovoran za pokretanje Android aplikacija, zahteva ovaj korak kako bi sve aplikacije koje se od sada pokreću koristile novokonfigurisane CA sertifikate. Komanda koja se koristi je:

Tip: Ako /system/etc/security/cacerts sadrži ugnježdene mount-ove (uobičajeno kod Magisk modula), koristite --rbind umesto --bind kako bi se ti mount-ovi propagirali u namespace-ove aplikacija.

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

Ovo osigurava da će svaka nova aplikacija koja se pokrene poštovati ažuriranu konfiguraciju CA sertifikata.

  1. Primena izmena na pokrenute aplikacije: Da bi se izmene primenile na već pokrenute aplikacije, nsenter se ponovo koristi da bi se ušlo u namespace svake aplikacije pojedinačno i izvršio sličan bind mount. Potrebna komanda je:
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
  1. Alternativni pristup - Soft Reboot: Alternativna metoda podrazumeva izvršavanje bind mount-a na procesu init (PID 1), praćeno soft reboot-om operativnog sistema pomoću komandi stop && start. Ovaj pristup bi propagirao izmene kroz sve namespaces, izbegavajući potrebu da se pojedinačno obrađuje svaka aktivna app. Međutim, ovaj metod je generalno manje poželjan zbog nepraktičnosti ponovnog pokretanja.

Reference

Tip

Nauči i vežbaj AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Nauči i vežbaj GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Nauči i vežbaj Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Pregledaj kompletan HackTricks Training katalog za assessment tracks (ARTA/GRTA/AzRTA) i Linux Hacking Expert (LHE).

Podrži HackTricks