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

Sakinisha Cheti cha Burp

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

Njia nyingine za kusaidia HackTricks:

• Ikiwa unataka kuona kampuni yako ikitangazwa kwenye HackTricks au kupakua HackTricks kwa PDF Angalia MIPANGO YA USAJILI!
• Pata bidhaa rasmi za PEASS & HackTricks
• Gundua Familia ya PEASS, mkusanyiko wetu wa NFTs za kipekee
• Jiunge na 💬 Kikundi cha Discord au kikundi cha telegram au tufuate kwenye Twitter 🐦 @carlospolopm.
• Shiriki mbinu zako za kuhack kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.

{% embed url="https://websec.nl/" %}

Kwenye Mashine ya Virtual

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

Toa cheti kwa muundo wa Der na litumie kwenye mfumo 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 mfumo wa faili ni wa kusoma tu na huwezi kuurudisha kuwa waandishi, kuna njia nyingine.

Iliyoelezwa katika video hii unahitaji:

1. Sakinisha cheti cha CA: Tu vuta na angusha cheti cha DER cha Burp ukibadilisha kificho kuwa .crt kwenye simu ili iwekwe kwenye folda ya Upakuaji na nenda kwa Sakinisha cheti -> Cheti cha CA

• Hakikisha cheti kimehifadhiwa kwa usahihi kwa kwenda kwa Imani credentials -> MTUMIAJI

2. Fanya iwe ya kuaminika kwa Mfumo: 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 baada ya kusakinishwa anzisha upya simu:

• Baada ya kuanza upya, nenda kwa Imani credentials -> MFUMO na hakikisha cheti cha Postswigger kipo hapo

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. Hata hivyo, na Android 14, eneo la kuhifadhi limehamishwa kwenda /apex/com.android.conscrypt/cacerts, saraka ndani ya njia ya /apex, ambayo ni isiyo ya kubadilika kwa asili.

Jaribio la kuirudisha tena njia ya APEX cacerts kuwa ya kuandishi hukutana na kushindikana, kwani mfumo hauruhusu operesheni kama hizo. Hata jaribio la kufuta au kufunika saraka hiyo na mfumo wa faili wa muda (tmpfs) hauzuili ubadilishaji; programu zinaendelea kupata data ya cheti ya asili bila kujali mabadiliko kwenye kiwango cha mfumo wa faili. Uimara huu unatokana na njia ya /apex kuwa imewekwa na usambazaji wa KIBINA binafsi, ikihakikisha kuwa mabadiliko yoyote ndani ya saraka 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 binafsi wa /apex, hivyo kufanya mabadiliko kwenye saraka hii kutengwa na michakato mingine.

Hata hivyo, njia mbadala ipo kwa wale wanaohitaji kuhariri vyeti vya CA vilivyothibitishwa na mfumo ndani ya saraka ya /apex. Hii inahusisha kuirudisha tena /apex ili kuondoa usambazaji wa KIBINA, hivyo kuifanya iwe ya kuandishi. Mchakato huu unajumuisha kunakili maudhui ya /apex/com.android.conscrypt kwenda mahali pengine, kufuta saraka ya /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 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"

Kufunga kupitia NSEnter

1. Kuanzisha Directory Inayoweza Kuandikwa: Kwanza, directory inayoweza kuandikwa inaanzishwa kwa kufunga tmpfs juu ya directory ya vyeti ya mfumo isiyo-APEX iliyopo. Hii inafanikishwa kwa kutumia amri ifuatayo:

mount -t tmpfs tmpfs /system/etc/security/cacerts

2. 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.
3. Bind Mounting kwa Zygote: Kwa kutumia nsenter, mtu anaingia kwenye nafasi ya mlima ya Zygote. Zygote, ikiwa ni mchakato unayehusika na kuzindua programu za Android, inahitaji hatua hii ili kuhakikisha kuwa programu zote zinazoanzishwa baadaye zinatumia vyeti vya CA vilivyoconfigure vizuri. Amri inayotumiwa ni:

nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

Hii inahakikisha kwamba kila programu mpya iliyozinduliwa itazingatia usanidi wa vyeti vya CA ulioboreshwa.

4. Kutekeleza Mabadiliko kwa Programu Zinazoendeshwa: Ili kutumia mabadiliko kwa programu zinazoendeshwa tayari, nsenter inatumika tena kuingia kwenye kila anga ya programu kwa kujitegemea na kutekeleza 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

5. Njia Mbadala - Kuzindua Upya Kwa Programu: Mbinu mbadala inahusisha kufanya bind mount kwenye mchakato wa init (PID 1) ikifuatiwa na kuzindua upya laini wa mfumo wa uendeshaji kwa kutumia amri za stop && start. Mbinu hii itasambaza mabadiliko katika vigezo vyote, ikiepuka haja ya kushughulikia kila programu inayotumika kivyake. Hata hivyo, mbinu hii kwa ujumla hupendelewa kidogo kutokana na usumbufu wa kuzindua upya.

Marejeo

• https://httptoolkit.com/blog/android-14-install-system-ca-certificate/

{% embed url="https://websec.nl/" %}

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

Njia nyingine za kusaidia HackTricks:

• Ikiwa unataka kuona kampuni yako ikitangazwa kwenye HackTricks au kupakua HackTricks kwa PDF Angalia MIPANGO YA KUJIUNGA!
• Pata bidhaa rasmi za PEASS & HackTricks
• Gundua Familia ya PEASS, mkusanyiko wetu wa NFTs ya kipekee
• Jiunge na 💬 Kikundi cha Discord au kikundi cha telegram au tufuate kwenye Twitter 🐦 @carlospolopm.
• Shiriki mbinu zako za kudukua kwa kuwasilisha PRs kwenye HackTricks na HackTricks Cloud repos za github.