Sakinisha Cheti cha Burp

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na fanya mazoezi ya Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Vinjari katalogi kamili ya HackTricks Training kwa ajili ya njia za assessment (ARTA/GRTA/AzRTA) na Linux Hacking Expert (LHE).

Support HackTricks

Proxy ya mfumo mzima kupitia ADB

Sanidi proxy ya HTTP ya kimataifa ili programu zote zitume trafiki kupitia interceptor yako (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

Ushauri: Katika Burp, weka listener yako kwa 0.0.0.0 ili vifaa kwenye LAN waweze kuungana (Proxy -> Options -> Proxy Listeners).

Kwenye Mashine ya Virtual

Kwanza kabisa unahitaji kupakua cheti cha Der kutoka Burp. Unaweza kufanya hivi katika Proxy –> Options –> Import / Export CA certificate

Toa cheti kwa muundo wa Der na tufanye kubadilisha hadi iwe katika fomati ambayo Android itakayoweza kuelewa. Kumbuka kwamba ili kusanidi burp certificate kwenye mashine ya Android katika AVD unahitaji kuendesha mashine hii na chaguo la -writable-system option.
Kwa mfano unaweza kuiendesha kama:

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

Kisha, ili kusanidi cheti cha Burp, fanya:

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

Mara tu machine imekamilisha rebooting cheti cha Burp kitakuwa kinatumika!

Kutumia Magisk

Ikiwa ume-rooted kifaa chako na Magisk (labda emulator), na huwezi kufuata hatua zilizotangulia za kusakinisha cheti cha Burp kwa sababu filesystem ni read-only na huwezi ku-remount kuwa writable, kuna njia nyingine.

Imefafanuliwa katika video hii unahitaji:

  1. Install a CA certificate: Just drag&drop the DER Burp certificate changing the extension to .crt kwenye simu ili iwe imehifadhiwa katika Downloads folder na nenda kwenye Install a certificate -> CA certificate
  • Angalia kwamba cheti kimehifadhiwa kikamilifu kwa kwenda Trusted credentials -> USER
  1. Make it System trusted: Download the Magisk module MagiskTrustUserCerts (a .zip file), drag&drop it kwenye simu, nenda kwenye Magisk app kwenye simu kwenye sehemu ya Modules, bonyeza Install from storage, chagua module ya .zip na mara baada ya kusakinishwa reboot simu:
  • Baada ya rebooting, nenda Trusted credentials -> SYSTEM na angalia cheti ya Postswigger iko hapo

Njia mbadala: AlwaysTrustUserCerts (Android 7-16 Beta)

Ikiwa uko kwenye Android 14+ (au kwenye vifaa vya zamani vilivyopokea Conscrypt Mainline updates na sasa vinatumia /apex/com.android.conscrypt/cacerts), Magisk module AlwaysTrustUserCerts inafanya automate ya bind-mounting inayohitajika kwa system trust. Inamirrors user CAs katika system trust na huingiza mounts kwenye Zygote/app namespaces ili apps ziweze kuona certs bila kazi ya mkono ya nsenter.

  1. Sakinisha Burp CA kama cheti cha user kwanza.
  2. Sakinisha module na reboot.
  3. Ikiwa module inatoa chaguo, pendelea --rbind wakati wa ku-mount /system/etc/security/cacerts ndani ya /apex/com.android.conscrypt/cacerts ili kuhakikisha nested mounts (kutoka modules nyingine) zinaonekana.

Jifunze jinsi ya kuunda Magisk module

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

Baada ya Android 14

Katika release ya hivi karibuni ya Android 14, kumetokea mabadiliko makubwa katika jinsi system-trusted Certificate Authority (CA) certificates zinavyoshughulikiwa.

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.

Hapo awali, cheti hizi zilihifadhiwa katika /system/etc/security/cacerts/, zikiwa zinapatikana na zinaweza kubadilishwa na watumiaji wenye root privileges, jambo ambalo liliwezesha matumizi mara moja katika mfumo mzima. Hata hivyo, katika Android 14, mahali pa kuhifadhi pamehamishwa kwenda /apex/com.android.conscrypt/cacerts, directory ndani ya /apex, ambayo ni isiyoweza kubadilishwa kwa asili.

Jaribio la ku-remount APEX cacerts path kama writable yanakumbana na kushindwa, kwani system haisiruhusu operesheni hizo. Hata jaribio la ku-unmount au ku-overlay directory kwa temporary file system (tmpfs) halivunji immutability; applications zinaendelea kufikia data asli ya cheti bila kujali mabadiliko kwenye kiwango cha file system. Ustahimilivu huu unatokana na mount ya /apex kuwa imewezeshwa kwa PRIVATE propagation, kuhakikisha kwamba mabadiliko yoyote ndani ya directory ya /apex hayataathiri process nyingine.

Kuanzishwa kwa Android kunahusisha process ya init, ambayo, inapokuwa inaanzisha operating system, pia inaanzisha process ya Zygote. Process hii inawajibika kwa kuanzisha application processes na mount namespace mpya inayojumuisha private /apex mount, hivyo kutenganisha mabadiliko kwenye directory hii kutoka kwa process nyingine.

Hata hivyo, kuna workaround kwa wale wanaohitaji kubadilisha system-trusted CA certificates ndani ya /apex directory. Hii inahusisha manual remounting ya /apex ili kuondoa PRIVATE propagation, kwa hivyo kuifanya writable. Mchakato unajumuisha kunakili yaliyomo ya /apex/com.android.conscrypt kwenda mahali pengine, ku-unmount directory ya /apex/com.android.conscrypt ili kuondoa kikomo cha read-only, kisha kurejesha yaliyomo kwenye eneo lao asilia ndani ya /apex. Mbinu hii inahitaji hatua za haraka ili kuepuka system crashes. Ili kuhakikisha mabadiliko haya yanaonekana katika mfumo mzima, inashauriwa ku-restart system_server, ambayo kwa ufanisi inarestart applications zote na kuleta system katika state iliyokamilishwa.

# 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. Kuanzisha saraka inayoweza kuandikwa: Awali, saraka inayoweza kuandikwa inaanzishwa kwa ku-mount tmpfs juu ya saraka ya cheti ya mfumo iliyopo isiyo-APEX. Hii inafikiwa kwa amri ifuatayo:
mount -t tmpfs tmpfs /system/etc/security/cacerts
  1. Kuandaa Vyeti vya CA: Baada ya kuanzisha saraka inayoweza kuandikwa, vyeti vya CA ambavyo mtu anataka kutumia vinapaswa kunakiliwa ndani ya saraka hii. Hii inaweza kuhusisha kunakili vyeti za chaguo-msingi kutoka /apex/com.android.conscrypt/cacerts/. Ni muhimu kurekebisha ruhusa na lebo za SELinux za vyeti hivi ipasavyo.
  2. Bind Mounting kwa Zygote: Kutumia nsenter, mtu anaingia kwenye mount namespace ya Zygote. Zygote, ikiwa ndio mchakato unaowajibika kuanzisha programu za Android, inahitaji hatua hii ili kuhakikisha kwamba programu zote zinazoanzishwa kuanzia sasa zitumia vyeti vya CA vilivyosanifiwa vipya. Amri inayotumika ni:

Vidokezo: Ikiwa /system/etc/security/cacerts ina nested mounts (kawaida na Magisk modules), tumia --rbind badala ya --bind ili mounts hizo zitangazwe ndani ya app namespaces.

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

Hii inahakikisha kwamba kila app mpya itakayozinduliwa itaendana na usanidi wa CA certificates uliosasishwa.

  1. Kutekeleza Mabadiliko kwa Apps Zinazofanya Kazi: Ili kutekeleza mabadiliko kwa apps ambazo tayari zinafanya kazi, nsenter hutumika tena kuingia namespace ya kila app mmoja mmoja na kufanya bind mount sawa. Amri inayohitajika ni:
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
  1. Mbinu Mbadala - Reboot Laini: Njia mbadala inahusisha kufanya bind mount kwenye mchakato wa init (PID 1) kisha kufanya reboot laini ya mfumo wa uendeshaji kwa amri za stop && start. Njia hii itasambaza mabadiliko kwenye namespaces zote, kuepuka haja ya kushughulikia kila app inayokimbia mmoja mmoja. Hata hivyo, njia hii kwa ujumla haipendwi kutokana na usumbufu wa kufanya reboot.

References

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na fanya mazoezi ya Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Vinjari katalogi kamili ya HackTricks Training kwa ajili ya njia za assessment (ARTA/GRTA/AzRTA) na Linux Hacking Expert (LHE).

Support HackTricks