Sakinisha Cheti cha Burp
Reading time: 9 minutes
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 Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Support HackTricks
- Angalia mpango wa usajili!
- Jiunge na 💬 kikundi cha Discord au kikundi cha telegram au tufuatilie kwenye Twitter 🐦 @hacktricks_live.
- Shiriki mbinu za hacking kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.
Proxy ya mfumo mzima kupitia ADB
Sanidi proxy ya HTTP ya mfumo mzima ili programu zote zipitie 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
Vidokezo: Katika Burp, weka listener yako kwenye 0.0.0.0 ili vifaa kwenye LAN viweze kuungana (Proxy -> Options -> Proxy Listeners).
Kwenye Mashine Pepe
Kwanza kabisa unahitaji kupakua cheti cha Der kutoka Burp. Unaweza kufanya hivyo katika Proxy --> Options --> Import / Export CA certificate
Hamisha cheti kwa muundo wa Der na tuibadilishe kuwa fomu ambayo Android itaweza kuelewa. Kumbuka kwamba ili kusanidi cheti cha burp kwenye mashine ya Android katika AVD unahitaji kuendesha mashine hii kwa chaguo -writable-system
.
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 configure burps certificate, 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 mashine itakapomaliza kuanzisha upya cheti cha Burp kitakuwa kinatumika!
Kutumia Magisc
Ikiwa ume rooted kifaa chako kwa Magisc (labda emulator), na huwezi kufuata hatua zilizotangulia za kusanidua Burp cert kwa sababu filesystem ni read-only na huwezi kuiremount ili iwe writable, kuna njia nyingine.
Imeelezewa katika video hii unahitaji:
- Install a CA certificate: Ingiza tu kwa drag&drop cheti cha DER cha Burp ukibadilisha extension hadi
.crt
kwenye simu ili kihifadhiwe kwenye folda ya Downloads na uendeInstall a certificate
->CA certificate
.png)
- Hakikisha kuwa cheti kimehifadhiwa kwa usahihi kwa kwenda
Trusted credentials
->USER
.png)
- Make it System trusted: Pakua module ya Magisc MagiskTrustUserCerts (ni faili .zip), drag&drop kwenye simu, nenda kwenye app ya Magics kwenye simu kwa sehemu ya
Modules
, bonyezaInstall from storage
, chagua module ya.zip
na mara imewekwa reboot simu:
.png)
- Baada ya ku-reboot, nenda
Trusted credentials
->SYSTEM
na hakikisha cheti cha Postswigger kipo hapo
.png)
Jifunze jinsi ya kuunda module ya Magisc
Baada ya Android 14
Katika toleo jipya la Android 14, kumetokea mabadiliko makubwa katika jinsi Certificate Authority (CA) certificates zinazoaminika na mfumo zinavyoshughulikiwa. Hadi sasa, vyote vilihifadhiwa katika /system/etc/security/cacerts/
, ambavyo vilikuwa vinapatikana na kuweza kubadilishwa na watumiaji walio na root privileges, jambo ambalo liliwezesha mabadiliko kutumika mara moja kwenye mfumo mzima. Hata hivyo, kwa Android 14, mahali pa kuhifadhi yamehamishwa hadi /apex/com.android.conscrypt/cacerts
, saraka ndani ya /apex
, ambayo kwa asili ni immutable.
Jaribio la ku-remount APEX cacerts path ili liwe writable hutumbukia kushindwa, kwa sababu mfumo haukuruhusu operesheni kama hiyo. Hata jaribio la ku-unmount au ku-overlay saraka hiyo kwa filesystem ya muda (tmpfs) halitatenga hali ya immutable; applications zinaendelea kufikia data ya cheti ya awali bila kujali mabadiliko kwenye ngazi ya filesystem. Ustahimilivu huu unatokana na mount ya /apex
kuwa imesanifiwa na PRIVATE propagation, ikihakikisha kwamba mabadiliko yoyote ndani ya saraka ya /apex
hayathiri michakato mingine.
Uanzishaji wa Android unahusisha mchakato wa init
, ambao, anapoanzisha operating system, pia huanzisha mchakato wa Zygote. Mchakato huu unawajibika kwa kuzindua michakato ya application yenye mount namespace mpya inayojumuisha mount ya kibinafsi ya /apex
, hivyo kutenga mabadiliko ya saraka hii kutoka kwa michakato mingine.
Hata hivyo, kuna njia mbadala kwa wale wanaohitaji kubadilisha CA certificates zinazoaminika na mfumo ndani ya saraka ya /apex
. Hii inahusisha ku-remount kwa mkono /apex
ili kuondoa PRIVATE propagation, na hivyo kuifanya iwe writable. Mchakato huo unajumuisha kunakili yaliyomo ya /apex/com.android.conscrypt
hadi sehemu nyingine, ku-unmount saraka ya /apex/com.android.conscrypt
ili kuondoa kikomo cha read-only, na kisha kurejesha yaliyomo kwenye mahali pake asilia ndani ya /apex
. Njia hii inahitaji hatua za haraka ili kuepuka crash za mfumo. Ili kuhakikisha mabadiliko haya yanatumika kwenye mfumo mzima, inashauriwa kuwasha upya system_server
, ambayo kwa ufanisi inarestart applications zote na kuleta mfumo katika hali thabiti.
# 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 kupitia NSEnter
- Kusanidi Saraka Inayoweza Kuandikwa: Awali, saraka inayoweza kuandikwa inaundwa kwa mounting ya
tmpfs
juu ya saraka ya vyeti ya mfumo ya non-APEX iliyopo. Hii inafikiwa kwa amri ifuatayo:
mount -t tmpfs tmpfs /system/etc/security/cacerts
- Kutayarisha Vyeti vya CA: Baada ya kuandaa directory inayoweza kuandikwa, vyeti vya CA ambavyo mtu anataka kutumia vinapaswa kunakiliwa ndani ya directory hii. Hii inaweza kuhusisha kunakili vyeti vya default kutoka
/apex/com.android.conscrypt/cacerts/
. Ni muhimu kurekebisha ruhusa na lebo za SELinux za vyeti hivi ipasavyo. - Bind Mounting for Zygote: Kwa kutumia
nsenter
, mtu anaingia kwenye mount namespace ya Zygote. Zygote, ikiwa ni mchakato unaehusika na kuanzisha programu za Android, inahitaji hatua hii ili kuhakikisha kwamba programu zote zitakazoanzishwa baadaye zinatumia vyeti vya CA vilivyosanidiwa hivi sasa. Amri inayotumika ni:
nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
Hii inahakikisha kwamba kila app mpya itakayozinduliwa itafuata usanidi uliosasishwa wa vyeti vya CA.
- Kutekeleza Mabadiliko kwa Programu Zinazoendesha: Ili kutekeleza mabadiliko kwa programu ambazo tayari zinaendeshwa,
nsenter
inatumiwa tena kuingia kwenye 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
- Njia Mbadala - Soft Reboot: Njia mbadala inahusisha kufanya bind mount kwenye
init
process (PID 1) ikifuatiwa na soft reboot ya mfumo wa uendeshaji kwa amri zastop && start
. Njia hii itaeneza mabadiliko kwa namespaces zote, ikiepuka hitaji la kushughulikia kila app kimoja kimoja. Hata hivyo, njia hii kwa ujumla haipendekezwi kwa sababu ya usumbufu wa rebooting.
Marejeleo
- 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
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 Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Support HackTricks
- Angalia mpango wa usajili!
- Jiunge na 💬 kikundi cha Discord au kikundi cha telegram au tufuatilie kwenye Twitter 🐦 @hacktricks_live.
- Shiriki mbinu za hacking kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.