hacktricks/mobile-pentesting/android-app-pentesting/install-burp-certificate.md

10 KiB

Sakinisha Cheti cha Burp

Jifunze kuhusu kudukua AWS kutoka sifuri hadi shujaa na htARTE (Mtaalam wa Timu Nyekundu ya AWS ya HackTricks)!

Njia nyingine za kusaidia HackTricks:

Kwenye Mashine ya Kivitual

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

Eksporti cheti kwa muundo wa Der na acha kilibadilishe kuwa muundo ambao Android itaweza kuelewa. Kumbuka kwamba ili kusanidi cheti cha burp kwenye mashine ya Android kwenye AVD unahitaji kuendesha mashine hii na chaguo la -writable-system.
Kwa mfano unaweza kuendesha kama:

{% code overflow="wrap" %}

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

{% endcode %}

Kisha, configure cheti cha burp kufanya:

{% code overflow="wrap" %}

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

{% endcode %}

Baada ya mashine kukamilisha kuanza upya cheti cha burp kitatumika nayo!

Kutumia Magisc

Ikiwa umefanya root kifaa chako na Magisc (labda emulator), na huwezi kufuata hatua za awali za kusakinisha cheti cha Burp kwa sababu filesystem ni read-only na huwezi kuirekebisha kuwa inayoweza kuandikwa, kuna njia nyingine.

Iliyoelezwa katika video hii unahitaji:

  1. Kusakinisha cheti cha CA: Tu vuta na angusha cheti cha DER cha Burp ukiibadilisha kielezo kuwa .crt kwenye simu ili iwekwe kwenye folda ya Upakuaji na nenda kwa Sakinisha cheti -> Cheti cha CA
  • Hakikisha kuwa cheti kimehifadhiwa kwa usahihi kwa kwenda kwa Imani credentials -> MTUMIAJI
  1. Fanya iwe ya kuaminika kwa System: Pakua moduli ya Magisc MagiskTrustUserCerts (faili ya .zip), vuta na angusha kwenye simu, nenda kwa programu ya Magics kwenye simu kwenye sehemu ya Moduli, bonyeza Sakinisha kutoka kwa uhifadhi, chagua moduli ya .zip na mara baada ya kusakinishwa anzisha upya simu:
  • Baada ya kuanza upya, nenda kwa Imani credentials -> SYSTEM na hakikisha cheti cha Postswigger kipo

Baada ya Android 14

Katika toleo jipya la Android 14, mabadiliko muhimu yameonekana katika kushughulikia vyeti vya Mamlaka ya Cheti (CA) vilivyothibitishwa na mfumo. Awali, vyeti hivi vilikuwa vimehifadhiwa katika /system/etc/security/cacerts/, vinavyoweza kufikiwa na kuhaririwa na watumiaji wenye mamlaka ya msingi, ambayo iliruhusu matumizi mara moja kote kwenye mfumo. Walakini, na Android 14, eneo la kuhifadhi limehamishwa kwenda /apex/com.android.conscrypt/cacerts, folda ndani ya njia ya /apex, ambayo ni isiyo ya kubadilika kwa asili.

Jaribio la kurekebisha tena njia ya APEX cacerts kama inayoweza kuandikwa hukutana na kushindikana, kwani mfumo hauruhusu shughuli kama hizo. Hata majaribio ya kufuta au kufunika folda na mfumo wa faili wa muda (tmpfs) hayapitishi kizuizi cha kusoma tu; programu zinaendelea kupata data ya cheti ya asili bila kujali mabadiliko kwenye kiwango cha mfumo wa faili. Uimara huu unatokana na mlima wa /apex ukiwa umewekwa na usambazaji wa KIBINA binafsi, kuhakikisha kuwa mabadiliko yoyote ndani ya /apex hayawaathiri michakato mingine.

Uanzishaji wa Android unajumuisha mchakato wa init, ambao, baada ya kuanza mfumo wa uendeshaji, pia huanzisha mchakato wa Zygote. Mchakato huu unahusika na kuzindua michakato ya programu na uwanja mpya wa mlima ambao una pamoja na mlima wa kibinafsi wa /apex, hivyo kufanya mabadiliko kwenye folda hii kuwa tofauti na michakato mingine.

Walakini, njia mbadala ipo kwa wale wanaohitaji kurekebisha vyeti vya CA vilivyothibitishwa na mfumo ndani ya /apex. Hii inahusisha kurekebisha tena /apex kwa kuondoa usambazaji wa KIBINA, hivyo kuifanya iweze kuandikwa. Mchakato huu unajumuisha kunakili maudhui ya /apex/com.android.conscrypt kwenda eneo lingine, kufuta mlima wa /apex/com.android.conscrypt ili kuondoa kizuizi cha kusoma tu, na kisha kurudisha maudhui kwenye eneo lao la asili ndani ya /apex. Hatua hii inahitaji hatua za haraka ili kuepuka kuharibika kwa mfumo. Ili kuhakikisha matumizi ya mabadiliko haya kote kwenye mfumo, inashauriwa kuanzisha upya system_server, ambayo kimsingi inaanzisha upya programu zote na kuweka 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"

Kufunga kupitia NSEnter

  1. Kuanzisha Daktari wa Kuandika: Kwanza, daktari wa kuandika unawekwa kwa kufunga tmpfs juu ya daktari wa vyeti wa mfumo wa sasa usio wa APEX. Hii inafanikiwa kwa amri ifuatayo:
mount -t tmpfs tmpfs /system/etc/security/cacerts
  1. Kujiandaa na Vyeti vya CA: Baada ya kuweka saraka inayoweza kuandikwa, vyeti vya CA ambavyo mtu anapanga kutumia vinapaswa kunakiliwa kwenye saraka hii. Hii inaweza kuhusisha kunakili vyeti vya msingi kutoka /apex/com.android.conscrypt/cacerts/. Ni muhimu kurekebisha ruhusa na lebo za SELinux za vyeti hivi kulingana na hali.
  2. Bind Mounting kwa Zygote: Kwa kutumia nsenter, mtu anaingia kwenye nafasi ya mlima ya Zygote. Zygote, ikiwa ni mchakato unaohusika na kuzindua programu za Android, inahitaji hatua hii ili kuhakikisha kuwa programu zote zinazoanzishwa baadaye zinatumia vyeti vya CA vilivyoconfigure upya. Amri inayotumiwa ni:
nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

Hii inahakikisha kuwa kila programu mpya iliyozinduliwa itazingatia usanidi wa vyeti vya CA uliyo boreshwa.

  1. Kutekeleza Mabadiliko kwa Programu Zinazoendeshwa: Ili kutumia mabadiliko kwa programu zinazoendeshwa tayari, nsenter inatumika tena kuingia kwenye kila anga ya programu kwa kujitegemea na kufanya bind mount kama hiyo. Amri inayohitajika ni:
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
  1. Njia Mbadala - Kuanzisha Upya Kwa Programu: Mbinu mbadala inahusisha kufanya bind mount kwenye mchakato wa init (PID 1) ikifuatiwa na kuanzisha upya laini wa mfumo wa uendeshaji kwa kutumia amri za stop && start. Mbinu hii itasambaza mabadiliko katika maeneo yote, ikiepuka haja ya kushughulikia kila programu inayotumika kwa kujitegemea. Hata hivyo, mbinu hii kwa ujumla hupendelewa kidogo kutokana na usumbufu wa kuanzisha upya.

Marejeo