Install Burp Certificate

Podržite HackTricks

Na Virtuelnoj Mašini

Prvo što treba da uradite je da preuzmete Der sertifikat sa Burp-a. To možete uraditi u Proxy --> Options --> Import / Export CA certificate

Izvezite sertifikat u Der formatu i hajde da transformišemo to u oblik koji Android može da razume. Imajte na umu da da biste konfigurisali burp sertifikat na Android mašini u AVD-u morate pokrenuti ovu mašinu sa -writable-system opcijom. 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 konfigurišete burp 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 sa ponovnim pokretanjem, Burp sertifikat će biti u upotrebi!

Korišćenje Magisc

Ako ste rootovali svoj uređaj sa Magisc (možda emulator), i ne možete da pratite prethodne korake za instalaciju Burp certifikata jer je fajl sistem samo za čitanje i ne možete ga ponovo montirati kao zapisiv, postoji drugi način.

Objašnjeno u ovom videu potrebno je da:

  1. Instalirate CA sertifikat: Samo prevucite i ispustite DER Burp sertifikat menjajući ekstenziju u .crt na mobilnom uređaju tako da bude smešten u Downloads folder i idite na Instaliraj sertifikat -> CA sertifikat

  • Proverite da li je sertifikat ispravno smešten odlaskom na Poverljivi podaci -> KORISNIK

  1. Učinite ga sistemski poverljivim: Preuzmite Magisc modul MagiskTrustUserCerts (zip fajl), prevucite i ispustite ga na telefon, idite na Magics aplikaciju na telefonu u Module sekciju, kliknite na Instaliraj iz skladišta, izaberite .zip modul i nakon instalacije ponovo pokrenite telefon:

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

Post Android 14

U najnovijem izdanju Android 14, primećen je značajan pomak u upravljanju sistemski poverljivim sertifikatima sertifikacione vlasti (CA). Prethodno su ovi sertifikati bili smešteni u /system/etc/security/cacerts/, dostupni i modifikovani od strane korisnika sa root privilegijama, što je omogućavalo trenutnu primenu širom sistema. Međutim, sa Android 14, lokacija skladištenja je premestena u /apex/com.android.conscrypt/cacerts, direktorijum unutar /apex putanje, 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 ni pokušaji da se direktorijum odmontira ili preklopi sa privremenim fajl sistemom (tmpfs) ne zaobilaze nepromenljivost; aplikacije nastavljaju da pristupaju originalnim podacima sertifikata bez obzira na promene na nivou fajl sistema. Ova otpornost je rezultat toga što je /apex montiranje konfigurisano sa PRIVATE propagacijom, osiguravajući da bilo kakve izmene unutar /apex direktorijuma ne utiču na druge procese.

Inicijalizacija Android-a uključuje init proces, koji, prilikom pokretanja operativnog sistema, takođe pokreće Zygote proces. Ovaj proces je odgovoran za pokretanje aplikacionih procesa sa novim montiranim imenskim prostorom koji uključuje privatno /apex montiranje, čime se izoluje promene u ovom direktorijumu od drugih procesa.

Ipak, postoji rešenje za one koji trebaju da modifikuju sistemski poverljive CA sertifikate unutar /apex direktorijuma. Ovo uključuje ručno ponovo montiranje /apex kako bi se uklonila PRIVATE propagacija, čime se omogućava zapisivanje. Proces uključuje kopiranje sadržaja /apex/com.android.conscrypt na drugo mesto, odmontiranje /apex/com.android.conscrypt direktorijuma kako bi se eliminisala ograničenja samo za čitanje, a zatim vraćanje sadržaja na njihovu originalnu lokaciju unutar /apex. Ovaj pristup zahteva brzu akciju kako bi se izbegli padovi sistema. Da bi se osigurala sistemska primena ovih izmena, preporučuje se ponovo pokretanje system_server, što efikasno ponovo pokreće sve aplikacije i dovodi sistem u dosledno 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. Postavljanje pisivog direktorijuma: U početku, pisivi direktorijum se uspostavlja montiranjem tmpfs preko postojećeg direktorijuma sa sistemskim sertifikatima koji nije APEX. Ovo se postiže sledećom komandom:

mount -t tmpfs tmpfs /system/etc/security/cacerts
  1. Priprema CA sertifikata: Nakon postavljanja zapisive direktorijuma, CA sertifikate koje nameravate da koristite treba kopirati u ovaj direktorijum. To može uključivati kopiranje podrazumevanih sertifikata iz /apex/com.android.conscrypt/cacerts/. Važno je prilagoditi dozvole i SELinux oznake ovih sertifikata u skladu s tim.

  2. Bind Mounting za Zygote: Korišćenjem nsenter, ulazi se u Zygote-ov mount namespace. Zygote, kao proces odgovoran za pokretanje Android aplikacija, zahteva ovaj korak kako bi se osiguralo da sve aplikacije pokrenute od sada 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 aplikacija koja se pokrene poštovati ažuriranu postavku CA sertifikata.

  1. Primena promena na aktivnim aplikacijama: Da bi se promene primenile na već pokrenutim aplikacijama, nsenter se ponovo koristi da uđe u namespace svake aplikacije pojedinačno i izvrši 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 mount-a na init procesu (PID 1) nakon čega sledi soft reboot operativnog sistema sa stop && start komandama. Ovaj pristup bi propagirao promene kroz sve namespace-ove, izbegavajući potrebu da se pojedinačno obrađuje svaka aplikacija koja se izvršava. Međutim, ova metoda se generalno manje preferira zbog neprijatnosti reboot-a.

Reference

Support HackTricks

Last updated