Instalirajte Burp sertifikat
Reading time: 9 minutes
tip
Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Učite i vežbajte Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Podržite HackTricks
- Proverite planove pretplate!
- Pridružite se 💬 Discord grupi ili telegram grupi ili pratite nas na Twitteru 🐦 @hacktricks_live.
- Podelite hakerske trikove slanjem PR-ova na HackTricks i HackTricks Cloud github repozitorijume.
Sistemski proxy preko ADB
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-u povežite listener 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 morate da preuzmete Der sertifikat iz Burp-a. To možete uraditi u Proxy --> Options --> Import / Export CA certificate
Export the certificate in Der format i hajde da ga transformišemo u format koji će Android moći da razume. Imajte na umu da da biste konfigurisali burp certificate na Android mašini u AVD-u 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 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
Once the machine finish rebooting the Burp certificate will be in use by it!
Korišćenje Magisc
If you rooted your device with Magisc (maybe an emulator), and you can't follow the previous steps to install the Burp cert because the filesystem is read-only and you cannot remount it writable, there is another way.
Explained in ovaj video you need to:
- Install a CA certificate: Just drag&drop the DER Burp certificate changing the extension to
.crt
in the mobile so it's stored in the Downloads folder and go toInstall a certificate
->CA certificate
.png)
- Check that the certificate was correctly stored going to
Trusted credentials
->USER
.png)
- Neka bude sistemski poveren: Download the Magisc module MagiskTrustUserCerts (a .zip file), drag&drop it in the phone, go to the Magics app in the phone to the
Modules
section, click onInstall from storage
, select the.zip
module and once installed reboot the phone:
.png)
- After rebooting, go to
Trusted credentials
->SYSTEM
and check the Postswigger cert is there
.png)
Naučite kako da kreirate Magisc modul
Posle Android 14
In the latest Android 14 release, a significant shift has been observed in the handling of system-trusted Certificate Authority (CA) certificates. Previously, these certificates were housed in /system/etc/security/cacerts/
, accessible and modifiable by users with root privileges, which allowed immediate application across the system. However, with Android 14, the storage location has been moved to /apex/com.android.conscrypt/cacerts
, a directory within the /apex
path, which is immutable by nature.
Attempts to remount the APEX cacerts path as writable are met with failure, as the system does not allow such operations. Even attempts to unmount or overlay the directory with a temporary file system (tmpfs) do not circumvent the immutability; applications continue to access the original certificate data regardless of changes at the file system level. This resilience is due to the /apex
mount being configured with PRIVATE propagation, ensuring that any modifications within the /apex
directory do not affect other processes.
The initialization of Android involves the init
process, which, upon starting the operating system, also initiates the Zygote process. This process is responsible for launching application processes with a new mount namespace that includes a private /apex
mount, thus isolating changes to this directory from other processes.
Nevertheless, a workaround exists for those needing to modify the system-trusted CA certificates within the /apex
directory. This involves manually remounting /apex
to remove the PRIVATE propagation, thereby making it writable. The process includes copying the contents of /apex/com.android.conscrypt
to another location, unmounting the /apex/com.android.conscrypt
directory to eliminate the read-only constraint, and then restoring the contents to their original location within /apex
. This approach requires swift action to avoid system crashes. To ensure system-wide application of these changes, it is recommended to restart the system_server
, which effectively restarts all applications and brings the system to a consistent state.
# 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 pomoću NSEnter
- Podešavanje direktorijuma sa mogućnošću pisanja: U početku se uspostavlja direktorijum u koji je moguće pisati tako što se
tmpfs
montira preko postojećeg non-APEX direktorijuma sistemskih sertifikata. To se postiže sledećom komandom:
mount -t tmpfs tmpfs /system/etc/security/cacerts
- Priprema CA sertifikata: Nakon podešavanja direktorijuma za pisanje, CA sertifikati koje želite da koristite treba da budu kopirani u taj direktorijum. Ovo može uključivati kopiranje podrazumevanih sertifikata iz
/apex/com.android.conscrypt/cacerts/
. Neophodno je prilagoditi dozvole i SELinux oznake ovih sertifikata u skladu s tim. - Bind mount za Zygote: Koristeći
nsenter
, ulazi se u mount namespace Zygote-a. Zygote, proces koji je odgovoran za pokretanje Android aplikacija, zahteva ovaj korak kako bi se osiguralo da sve aplikacije pokrenute ubuduće 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 obezbeđuje da će svaka nova aplikacija koja se pokrene poštovati ažuriranu konfiguraciju CA sertifikata.
- Primena izmena na već pokrenute aplikacije: Da biste primenili izmene na aplikacije koje su već pokrenute, ponovo se koristi
nsenter
da se uđe u namespace svake aplikacije pojedinačno i izvrši 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
- Alternativni pristup - Soft Reboot: Alternativna metoda uključuje izvršavanje bind mount na
init
procesu (PID 1), nakon čega sledi soft reboot operativnog sistema pomoću komandistop && start
. Ovaj pristup bi propagirao promene kroz sve namespaces, izbegavajući potrebu da se pojedinačno adresira svaka pokrenuta app. Međutim, ova metoda je generalno manje poželjna zbog neprijatnosti restartovanja.
Izvori
- Android 14: Install a system CA certificate on a rooted device
- Build a Repeatable Android Bug Bounty Lab: Emulator vs Magisk, Burp, Frida, and Medusa
tip
Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Učite i vežbajte Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Podržite HackTricks
- Proverite planove pretplate!
- Pridružite se 💬 Discord grupi ili telegram grupi ili pratite nas na Twitteru 🐦 @hacktricks_live.
- Podelite hakerske trikove slanjem PR-ova na HackTricks i HackTricks Cloud github repozitorijume.