Burp सर्टिफिकेट इंस्टॉल करें

Reading time: 10 minutes

ADB के माध्यम से सिस्टम-व्यापी प्रॉक्सी

एक वैश्विक HTTP प्रॉक्सी कॉन्फ़िगर करें ताकि सभी ऐप्स का ट्रैफ़िक आपके इंटरसेप्टर (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

टिप: Burp में अपना listener 0.0.0.0 से bind करें ताकि LAN पर डिवाइस कनेक्ट कर सकें (Proxy -> Options -> Proxy Listeners).

एक वर्चुअल मशीन पर

सबसे पहले आपको Burp से Der certificate डाउनलोड करना होगा। आप यह Proxy --> Options --> Import / Export CA certificate में कर सकते हैं।

Der फॉर्मेट में certificate export करें और चलिए इसे उस फॉर्म में बदलते हैं जिसे Android समझ सके। ध्यान दें कि AVD में Android मशीन पर burp certificate configure करने के लिए आपको यह मशीन -writable-system विकल्प के साथ run करना होगा।
उदाहरण के लिए आप इसे इस तरह चला सकते हैं:

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

फिर, burps certificate को कॉन्फ़िगर करने के लिए:

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

जब मशीन का पुनरारंभ पूरा होने के बाद तो Burp प्रमाणपत्र इसका उपयोग करने लगेगा!

Magisc का उपयोग

यदि आपने अपना डिवाइस Magisc के साथ rooted किया है (शायद एक emulator), और आप पिछले steps का पालन करके Burp cert इंस्टॉल नहीं कर पा रहे क्योंकि filesystem is read-only है और आप उसे writable के लिए remount नहीं कर सकते, तो एक और तरीका है।

जैसा कि this video में बताया गया है, आपको यह करना होगा:

1. Install a CA certificate: बस मोबाइल में DER Burp certificate को drag&drop करें और इसकी extension .crt में बदलें ताकि यह Downloads फोल्डर में सेव हो जाए और फिर Install a certificate -> CA certificate पर जाएँ

• पुष्टि करें कि प्रमाणपत्र सही तरीके से संग्रहित हुआ है: Trusted credentials -> USER पर जाएँ

2. Make it System trusted: Magisc मॉड्यूल MagiskTrustUserCerts (.zip फ़ाइल) डाउनलोड करें, उसे फोन में drag&drop करें, फोन में Magics app खोलें और Modules सेक्शन में जाएँ, Install from storage पर क्लिक करें, .zip मॉड्यूल चुनें और इंस्टॉल होने के बाद फोन को reboot करें:

• रीबूट के बाद, Trusted credentials -> SYSTEM पर जाएँ और जाँच करें कि Postswigger cert वहाँ है

Magisc मॉड्यूल कैसे बनाना सीखें

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

Android 14 के बाद

हाल के Android 14 रिलीज़ में system-trusted Certificate Authority (CA) प्रमाणपत्रों के हैंडलिंग में एक बड़ा बदलाव देखा गया है। पहले ये प्रमाणपत्र /system/etc/security/cacerts/ में रखे जाते थे, जिन्हें root privileges वाले उपयोगकर्ता एक्सेस और मॉडिफाई कर सकते थे, जिससे ये तुरंत पूरे सिस्टम में प्रभावी होते थे। हालांकि, Android 14 में इनका स्टोरेज स्थान /apex/com.android.conscrypt/cacerts पर शिफ्ट कर दिया गया है, जो /apex पाथ के भीतर का एक डायरेक्टरी है और प्रकृतिगत रूप से immutable है।

APEX cacerts path को writable के रूप में remount करने के प्रयास विफल होते हैं, क्योंकि सिस्टम ऐसे ऑपरेशन की अनुमति नहीं देता। डायरेक्टरी को unmount करने या temporary file system (tmpfs) के साथ overlay करने के प्रयास भी immutability को पार नहीं कर पाते; एप्लिकेशन फ़ाइल सिस्टम स्तर पर किए गए बदलावों के बावजूद मूल प्रमाणपत्र डेटा तक पहुँचती रहती हैं। यह लचीलापन इसलिए है क्योंकि /apex माउंट को PRIVATE propagation के साथ कॉन्फ़िगर किया गया है, जिससे /apex डायरेक्टरी के भीतर किसी भी संशोधन का अन्य प्रक्रियाओं पर प्रभाव नहीं पड़ता।

Android की initialization में init प्रक्रिया शामिल होती है, जो ऑपरेटिंग सिस्टम शुरू होने पर Zygote प्रक्रिया भी शुरू करती है। यह प्रक्रिया application processes को एक नए mount namespace के साथ लॉन्च करने के लिए जिम्मेदार है, जिसमें एक private /apex mount शामिल होता है, इस तरह इस डायरेक्टरी में किए गए परिवर्तन अन्य प्रक्रियाओं से अलग हो जाते हैं।

फिर भी, जिन लोगों को /apex डायरेक्टरी के भीतर system-trusted CA प्रमाणपत्रों में संशोधन करना आवश्यक है उनके लिए एक workaround मौजूद है। इसमें PRIVATE propagation हटाने के लिए मैन्युअली /apex को remount करना शामिल है, जिससे यह writable बन जाता है। प्रक्रिया में /apex/com.android.conscrypt की सामग्री को किसी अन्य स्थान पर कॉपी करना, /apex/com.android.conscrypt डायरेक्टरी को unmount करना ताकि read-only बाधा हटे, और फिर सामग्री को उसके मूल स्थान पर वापस restore करना शामिल है। इस तरीके के लिए तेज़ कार्रवाई की आवश्यकता होती है ताकि system crashes से बचा जा सके। इन परिवर्तनों को सिस्टम-व्यापी प्रभावी करने के लिए system_server को restart करने की सलाह दी जाती है, जो प्रभावी रूप से सभी एप्लिकेशन को restart करता है और सिस्टम को एक consistent स्थिति में लाता है।

# 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. Setting Up a Writable Directory: शुरुआत में, मौजूदा non-APEX system certificate डायरेक्टरी के ऊपर tmpfs माउंट करके एक लिखने योग्य डायरेक्टरी बनाई जाती है। इसे निम्नलिखित कमांड से किया जाता है:

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

2. Preparing CA Certificates: लिखने योग्य निर्देशिका सेट अप करने के बाद, जिन CA प्रमाणपत्रों का उपयोग करना हो उन्हें इस निर्देशिका में कॉपी करना चाहिए। इसमें संभवतः /apex/com.android.conscrypt/cacerts/ से डिफ़ॉल्ट प्रमाणपत्रों को कॉपी करना शामिल होगा। इन प्रमाणपत्रों की permissions और SELinux labels को उपयुक्त रूप से समायोजित करना आवश्यक है।
3. Bind Mounting for Zygote: nsenter का उपयोग करते हुए, कोई Zygote के mount namespace में प्रवेश करता है। Zygote, जो Android applications लॉन्च करने के लिए जिम्मेदार प्रक्रिया है, इस कदम की आवश्यकता इसलिए होती है ताकि आगे से शुरू होने वाली सभी एप्लिकेशन नए कॉन्फ़िगर किए गए CA प्रमाणपत्रों का उपयोग करें। उपयोग किया जाने वाला कमांड है:

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

यह सुनिश्चित करता है कि शुरू होने वाला हर नया ऐप अपडेट किए गए CA प्रमाणपत्र सेटअप का पालन करेगा।

4. चल रहे ऐप्स पर परिवर्तन लागू करना: पहले से चल रहे applications पर परिवर्तन लागू करने के लिए, nsenter का फिर से उपयोग प्रत्येक ऐप के namespace में अलग-अलग प्रवेश करने और समान bind mount करने के लिए किया जाता है। आवश्यक कमांड है:

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

5. वैकल्पिक तरीका - Soft Reboot: एक वैकल्पिक विधि में init process (PID 1) पर bind mount करना शामिल है, और उसके बाद ऑपरेटिंग सिस्टम को stop && start कमांड से soft reboot करना। यह तरीका सभी namespaces में बदलाव फैलाएगा, जिससे प्रत्येक चल रही app को अलग से संबोधित करने की आवश्यकता नहीं पड़ेगी। हालांकि, इस विधि को आमतौर पर कम पसंद किया जाता है क्योंकि reboot करने में असुविधा होती है।

References

• 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