Install Burp Certificate

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

Na virtuelnoj mašini

Prvo morate preuzeti Der sertifikat sa Burp-a. To možete uraditi u Proxy --> Options --> Import / Export CA certificate

Izvezite sertifikat u Der formatu i pretvorite ga u oblik koji će Android moći da razume. Imajte na umu da kako biste konfigurisali burp sertifikat na Android mašini u AVD-u morate pokrenuti ovu 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 burpov sertifikat 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

Kada mašina završi ponovno pokretanje, sertifikat burp će biti u upotrebi!

Korišćenje Magiska

Ako ste rutirali uređaj pomoću Magiska (možda emulator), i ne možete pratiti prethodne korake za instalaciju Burp sertifikata jer je datotečni sistem samo za čitanje i ne možete ga ponovo montirati kao zapisiv, postoji drugi način.

Objašnjeno u ovom videu trebate:

  1. Instalirati CA sertifikat: Samo prevucite i otpustite DER Burp sertifikat menjajući ekstenziju u .crt na mobilnom uređaju tako da bude smešten u fascikli za preuzimanje i idite na Instaliraj sertifikat -> CA sertifikat

  • Proverite da li je sertifikat pravilno smešten odlaskom na Poverljivi certifikati -> KORISNIK

  1. Učinite ga sistemski poverljivim: Preuzmite Magisk modul MagiskTrustUserCerts (.zip datoteka), prevucite i otpustite je na telefon, idite na Magisk aplikaciju na telefonu u odeljku Moduli, kliknite na Instaliraj sa skladišta, izaberite .zip modul i jednom kada se instalira, ponovo pokrenite telefon:

  • Nakon ponovnog pokretanja, idite na Poverljivi certifikati -> SISTEM i proverite da li je Postswigger sertifikat tamo

Nakon Android 14

U najnovijem Android 14 izdanju, primećen je značajan pomak u rukovanju sistemski poverljivim sertifikatima sertifikacionih tela (CA). Ranije su ovi sertifikati bili smešteni u /system/etc/security/cacerts/, pristupačni i modifikovani od strane korisnika sa administratorskim privilegijama, što je omogućavalo trenutnu primenu širom sistema. Međutim, sa Androidom 14, lokacija skladištenja je premeštena u /apex/com.android.conscrypt/cacerts, direktorijum unutar putanje /apex, koji je po prirodi nepromenljiv.

Pokušaji ponovnog montiranja APEX cacerts putanje kao zapisive se susreću sa neuspehom, jer sistem ne dozvoljava takve operacije. Čak i pokušaji demontiranja ili preklapanja direktorijuma sa privremenim fajl sistemom (tmpfs) ne zaobilaze nepromenljivost; aplikacije i dalje pristupaju originalnim podacima sertifikata bez obzira na promene na nivou fajl sistema. Ova otpornost je posledica toga što je montiranje /apex konfigurisano sa PRIVATNOM propagacijom, osiguravajući da bilo kakve modifikacije unutar direktorijuma /apex ne utiču na druge procese.

Inicijalizacija Androida uključuje init proces, koji, prilikom pokretanja operativnog sistema, takođe pokreće Zygote proces. Ovaj proces je odgovoran za pokretanje procesa aplikacija sa novim montažnim prostorom koji uključuje privatno montiranje /apex, čime se izoluju promene u ovom direktorijumu od drugih procesa.

Ipak, postoji način za one koji trebaju da modifikuju sistemski poverljive CA sertifikate unutar direktorijuma /apex. To uključuje ručno ponovno montiranje /apex kako bi se uklonila PRIVATNA propagacija, čime se čini zapisivim. Proces uključuje kopiranje sadržaja /apex/com.android.conscrypt na drugu lokaciju, demontiranje direktorijuma /apex/com.android.conscrypt kako bi se eliminisalo ograničenje samo za čitanje, a zatim vraćanje sadržaja na originalnu lokaciju unutar /apex. Ovaj pristup zahteva brzu akciju kako bi se izbegli padovi sistema. Da bi se osigurala sistematska primena ovih promena, preporučuje se ponovno pokretanje system_server, što efikasno ponovo pokreće 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-montiranje putem NSEnter

  1. Postavljanje direktorijuma za pisanje: Prvo se uspostavlja direktorijum za pisanje montiranjem tmpfs preko postojećeg direktorijuma za sistemske sertifikate koji nisu APEX. To se postiže sledećom komandom:

mount -t tmpfs tmpfs /system/etc/security/cacerts
  1. Priprema CA sertifikata: Nakon podešavanja upisivog direktorijuma, CA sertifikati koje nameravate koristiti treba da budu kopirani u ovaj direktorijum. To može uključivati kopiranje podrazumevanih sertifikata iz /apex/com.android.conscrypt/cacerts/. Bitno je prilagoditi dozvole i SELinux oznake ovih sertifikata prema potrebi.

  2. Bind montiranje za Zygote: Korišćenjem nsenter, ulazi se u Zygote-ov namespace za montiranje. Zygote, kao proces odgovoran za pokretanje Android aplikacija, zahteva ovaj korak kako bi se osiguralo da sve aplikacije pokrenute od tog trenutka koriste novo konfigurisane CA sertifikate. Komanda koja se koristi je:

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

Ovo osigurava da će svaka nova pokrenuta aplikacija poštovati ažurirani CA sertifikat setup.

  1. Primenjivanje promena na pokrenute aplikacije: Da biste primenili promene na već pokrenute aplikacije, ponovo se koristi nsenter da biste pojedinačno ušli u namespace svake aplikacije i izvršili sličan bind mount. Neophodna 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 uključuje izvođenje bind mounta na init procesu (PID 1), praćeno soft restartovanjem operativnog sistema pomoću stop && start komandi. Ovaj pristup će proširiti promene preko svih namespace-ova, izbegavajući potrebu da se pojedinačno adresiraju svaka pokrenuta aplikacija. Međutim, ovaj metod je generalno manje preferiran zbog neugodnosti restartovanja.

Reference

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

Last updated