Burp Sertifikasını Yükle

Tip

AWS Hacking öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE) Değerlendirme yolları (ARTA/GRTA/AzRTA) ve Linux Hacking Expert (LHE) için tam HackTricks Training kataloğuna göz atın.

HackTricks'i Destekleyin

ADB üzerinden sistem genelinde proxy

Tüm uygulamaların trafiğini interceptor’ünüz (Burp/mitmproxy) üzerinden yönlendirmek için sistem genelinde bir HTTP proxy yapılandırın:

# 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

İpucu: Burp’ta dinleyicinizi 0.0.0.0 adresine bağlayın, böylece LAN’daki cihazlar bağlanabilir (Proxy -> Options -> Proxy Listeners).

Sanal Makinede

Her şeyden önce Burp’tan Der sertifikasını indirmeniz gerekiyor. Bunu Proxy –> Options –> Import / Export CA certificate içinde yapabilirsiniz.

Sertifikayı Der formatında dışa aktarın ve bunu dönüştürelim, Android’in anlayabileceği bir formata. Dikkat: AVD içindeki Android makinesine Burp sertifikasını yapılandırmak için bu makineyi çalıştırmanız ile -writable-system seçeneğini kullanmanız gerekiyor.
Örneğin şöyle çalıştırabilirsiniz:

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

Ardından, burps certificate’i yapılandırmak için:

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

Once the makine yeniden başlatmayı bitirdiğinde burp sertifikası bundan sonra kullanılacaktır!

Magisk Kullanımı

Eğer cihazınızı Magisk ile rootladıysanız (belki bir emulator) ve önceki adımları Burp sertifikasını yüklemek için takip edemiyorsanız çünkü dosya sistemi salt okunur ve yeniden yazılabilir hale getiremiyorsanız, başka bir yol var.

Explained in this video you need to:

  1. Install a CA certificate: Just drag&drop the DER Burp certificate changing the extension to .crt in the mobile so it’s stored in the Downloads folder and go to Install a certificate -> CA certificate
  • Sertifikanın doğru şekilde saklandığını kontrol etmek için Trusted credentials -> USER’e gidin
  1. Make it System trusted: Download the Magisk module MagiskTrustUserCerts (a .zip file), drag&drop it in the phone, go to the Magisk app in the phone to the Modules section, click on Install from storage, select the .zip module and once installed reboot the phone:
  • Yeniden başlattıktan sonra Trusted credentials -> SYSTEM’e gidin ve Postswigger sertifikasının orada olduğunu doğrulayın

Alternatif: AlwaysTrustUserCerts (Android 7-16 Beta)

Eğer Android 14+ kullanıyorsanız (veya Conscrypt Mainline güncellemeleri almış ve şimdi /apex/com.android.conscrypt/cacerts kullanan daha eski cihazlardaysanız), Magisk modülü AlwaysTrustUserCerts sistem güveni için gereken bind-mounting işlemini otomatikleştirir. Kullanıcı CA’larını sistem güvenine yansıtır ve uygulamaların sertifikaları görmek için elle nsenter çalıştırmaya gerek kalmadan Zygote/app ad alanlarına mount ekler.

  1. Önce Burp CA’yı bir user sertifikası olarak yükleyin.
  2. Modülü yükleyin ve yeniden başlatın.
  3. Modül bir seçenek sunuyorsa, /system/etc/security/cacerts’i /apex/com.android.conscrypt/cacerts içine monte ederken iç içe mount’ların (diğer modüllerden gelen) görünür olmasını sağlamak için /rbind yerine --rbind tercih edin.

Magisk modülü nasıl oluşturulur

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

Android 14 Sonrası

En son Android 14 sürümünde, sistem tarafından güvenilen Certificate Authority (CA) sertifikalarının yönetiminde önemli bir değişim gözlemlendi.

Not: Conscrypt Mainline güncellemeleri alan bazı Android 12/13 cihazları zaten /apex/com.android.conscrypt/cacerts kullanıyor. Cihazınızda bu dizin varsa, aşağıda açıklanan aynı APEX injection tekniğini kullanmanız gerekir.

Önceden bu sertifikalar /system/etc/security/cacerts/ içinde tutuluyor ve root ayrıcalığına sahip kullanıcılar tarafından erişilip değiştirilebiliyorlardı; bu da değişikliklerin sistem genelinde anında uygulanmasını sağlıyordu. Ancak Android 14 ile birlikte depolama yeri /apex/com.android.conscrypt/cacerts olarak taşındı; bu dizin /apex yolunun bir parçası olup doğası gereği değiştirilemez (immutable).

APEX cacerts yolunu yazılabilir yapmak için yeniden mount etmeye çalışmak başarısız olur; sistem böyle işlemlere izin vermez. Dizin üzerinde unmount yapmaya veya geçici bir dosya sistemi (tmpfs) ile overlay etmeye yönelik denemeler bile değişmezliği aşamaz; uygulamalar dosya sistemi düzeyindeki değişikliklerden bağımsız olarak orijinal sertifika verisini okumaya devam eder. Bunun nedeni /apex mount’unun PRIVATE propagation ile yapılandırılmış olmasıdır; bu, /apex dizinindeki değişikliklerin diğer süreçleri etkilememesini garanti eder.

Android’in başlatılması sırasında init süreci işletim sistemini başlatırken aynı zamanda Zygote sürecini de başlatır. Bu süreç, uygulama süreçlerini yeni bir mount ad alanı ile başlatmaktan sorumludur; bu ad alanı içinde özel bir /apex mount bulunur ve böylece bu dizindeki değişiklikler diğer süreçlerden izole edilir.

Yine de, /apex dizini içindeki sistem tarafından güvenilen CA sertifikalarını değiştirmesi gerekenler için bir çözüm yolu vardır. Bu, PRIVATE propagation’ı kaldırmak için manuel olarak /apex’in yeniden mount edilmesini içerir; süreç, /apex/com.android.conscrypt içeriğini başka bir yere kopyalamayı, /apex/com.android.conscrypt dizinini unmount ederek salt okunur kısıtlamasını ortadan kaldırmayı ve ardından içeriği tekrar orijinal konumuna geri yüklemeyi kapsar. Sistem çökmelerini önlemek için bu işlemin hızlı yapılması gerekir. Değişikliklerin sistem genelinde uygulanmasını sağlamak için system_server’ın yeniden başlatılması önerilir; bu, tüm uygulamaları etkili bir şekilde yeniden başlatır ve sistemi tutarlı bir duruma getirir.

# 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. Yazılabilir Dizin Oluşturma: Başlangıçta, var olan non-APEX sistem sertifika dizininin üzerine bir tmpfs bağlayarak yazılabilir bir dizin oluşturulur. Bu, aşağıdaki komutla gerçekleştirilir:
mount -t tmpfs tmpfs /system/etc/security/cacerts
  1. CA Sertifikalarının Hazırlanması: Yazılabilir dizin ayarlandıktan sonra kullanılmak istenen CA sertifikaları bu dizine kopyalanmalıdır. Bu, varsayılan sertifikaların /apex/com.android.conscrypt/cacerts/’den kopyalanmasını içerebilir. Bu sertifikaların izinlerinin ve SELinux etiketlerinin buna göre ayarlanması çok önemlidir.
  2. Zygote için Bind Mount: nsenter kullanılarak Zygote’un mount namespace’ine girilir. Zygote, Android uygulamalarını başlatmaktan sorumlu süreç olduğundan, bundan sonra başlatılacak tüm uygulamaların yeni yapılandırılmış CA sertifikalarını kullanmasını sağlamak için bu adım gereklidir. Kullanılan komut:

Tip: Eğer /system/etc/security/cacerts iç içe mountlar (nested mounts) içeriyorsa (Magisk modüllerinde yaygındır), bu mountların uygulama namespace’lerine aktarılması için --rbind yerine --bind kullanmayıp --rbind kullanın.

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

Bu, başlatılan her yeni uygulamanın güncellenmiş CA sertifikaları yapılandırmasına uyacağını garanti eder.

  1. Çalışan Uygulamalara Değişiklikleri Uygulama: Zaten çalışan uygulamalara değişiklikleri uygulamak için, nsenter tekrar kullanılarak her bir uygulamanın namespace’ine ayrı ayrı girilir ve benzer bir bind mount gerçekleştirilir. Gerekli komut şudur:
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
  1. Alternative Approach - Soft Reboot: Alternatif bir yöntem, bind mount işlemini init sürecine (PID 1) uygulayıp ardından işletim sistemini stop && start komutlarıyla soft reboot yapmaktır. Bu yaklaşım değişiklikleri tüm namespaces’e yayar ve her çalışan uygulamayı tek tek ele alma ihtiyacını ortadan kaldırır. Ancak, yeniden başlatmanın getirdiği zahmet nedeniyle bu yöntem genelde daha az tercih edilir.

Kaynaklar

Tip

AWS Hacking öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE) Değerlendirme yolları (ARTA/GRTA/AzRTA) ve Linux Hacking Expert (LHE) için tam HackTricks Training kataloğuna göz atın.

HackTricks'i Destekleyin