Burp Sertifikasını Yükle

Reading time: 7 minutes

Sanal Makinede

Öncelikle Burp'tan Der sertifikasını indirmeniz gerekiyor. Bunu Proxy --> Options --> Import / Export CA certificate kısmında yapabilirsiniz.

Sertifikayı Der formatında dışa aktarın ve Android'in anlayabileceği bir forma dönüştürelim. AVD'deki Android makinesinde burp sertifikasını yapılandırmak için bu makineyi -writable-system seçeneği ile çalıştırmanız gerektiğini unutmayın.
Örneğin, şu şekilde çalıştırabilirsiniz:

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

Sonra, burp sertifikasını 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

Bir kez makine yeniden başlatıldığında, burp sertifikası kullanılmaya başlanacaktır!

Magisc Kullanımı

Eğer cihazınızı Magisc ile rootladıysanız (belki bir emülatör), ve önceki adımları Burp sertifikasını yüklemek için takip edemiyorsanız çünkü dosya sistemi salt okunur ve yazılabilir olarak yeniden bağlayamıyorsanız, başka bir yol vardır.

bu videoda açıklandığı gibi, şunları yapmalısınız:

1. Bir CA sertifikası yükleyin: Sadece sürükleyip bırakın DER Burp sertifikasını uzantısını .crt olarak değiştirerek mobil cihazda, böylece İndirilenler klasöründe saklanır ve Bir sertifika yükle -> CA sertifikası kısmına gidin.

• Sertifikanın doğru bir şekilde saklandığını kontrol edin, Güvenilir kimlik bilgileri -> KULLANICI kısmına gidin.

2. Sistem güvenilir hale getirin: Magisc modülünü MagiskTrustUserCerts (bir .zip dosyası) indirin, sürükleyip bırakın telefonunuza, telefonunuzdaki Magics uygulamasına gidin ve Modüller bölümüne geçin, Depolamadan yükle seçeneğine tıklayın, .zip modülünü seçin ve yüklendikten sonra telefonu yeniden başlatın:

• Yeniden başlatmadan sonra, Güvenilir kimlik bilgileri -> SİSTEM kısmına gidin ve Postswigger sertifikasının orada olduğunu kontrol edin.

Android 14 Sonrası

Son Android 14 sürümünde, sistem güvenilir Sertifika Otoritesi (CA) sertifikalarının yönetiminde önemli bir değişiklik gözlemlenmiştir. Önceden, bu sertifikalar /system/etc/security/cacerts/ dizininde bulunuyordu ve root ayrıcalıklarına sahip kullanıcılar tarafından erişilebilir ve değiştirilebilir durumdaydı, bu da sistem genelinde anında uygulanmasını sağlıyordu. Ancak, Android 14 ile birlikte, depolama yeri /apex/com.android.conscrypt/cacerts dizinine taşınmıştır; bu dizin /apex yolunun içinde yer almakta olup, doğası gereği değiştirilemezdir.

APEX cacerts yolu'nu yazılabilir olarak yeniden bağlama girişimleri başarısızlıkla sonuçlanmaktadır, çünkü sistem böyle işlemlere izin vermemektedir. Geçici bir dosya sistemi (tmpfs) ile dizini çıkarmaya veya üst üste bindirmeye yönelik girişimler bile değiştirilemezliği aşmamaktadır; uygulamalar, dosya sistemi düzeyindeki değişikliklere bakılmaksızın orijinal sertifika verilerine erişmeye devam etmektedir. Bu dayanıklılık, /apex montajının ÖZEL yayılma ile yapılandırılmasından kaynaklanmaktadır; bu, /apex dizinindeki herhangi bir değişikliğin diğer süreçleri etkilemediğini garanti eder.

Android'in başlatılması, işletim sistemini başlatırken init sürecini içerir ve bu süreç, Zygote sürecini de başlatır. Bu süreç, uygulama süreçlerini yeni bir montaj ad alanı ile başlatmaktan sorumludur; bu ad alanı, özel bir /apex montajını içerir ve böylece bu dizindeki değişiklikleri diğer süreçlerden izole eder.

Yine de, /apex dizinindeki sistem güvenilir CA sertifikalarını değiştirmek isteyenler için bir çözüm bulunmaktadır. Bu, /apex'i yeniden bağlayarak ÖZEL yayılmayı kaldırmayı ve böylece yazılabilir hale getirmeyi içerir. Süreç, /apex/com.android.conscrypt içeriğini başka bir yere kopyalamayı, /apex/com.android.conscrypt dizinini çıkarmayı ve salt okunur kısıtlamayı ortadan kaldırmayı, ardından içeriği /apex içindeki orijinal konumuna geri yüklemeyi içerir. Bu yaklaşım, sistem çöküşlerini önlemek için hızlı hareket etmeyi gerektirir. Bu değişikliklerin sistem genelinde uygulanmasını sağlamak için, system_server'ı yeniden başlatmak ö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 Bir Dizin Kurma: İlk olarak, mevcut APEX olmayan sistem sertifika dizininin üzerine bir tmpfs monte edilerek yazılabilir bir dizin oluşturulur. Bu, aşağıdaki komut ile gerçekleştirilir:

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

2. CA Sertifikalarının Hazırlanması: Yazılabilir dizinin kurulumu sonrasında, kullanılmak istenen CA sertifikaları bu dizine kopyalanmalıdır. Bu, /apex/com.android.conscrypt/cacerts/ dizinindeki varsayılan sertifikaların kopyalanmasını içerebilir. Bu sertifikaların izinlerinin ve SELinux etiketlerinin uygun şekilde ayarlanması önemlidir.
3. Zygote için Bağlama Montajı: nsenter kullanarak, Zygote'un montaj ad alanına girilir. Zygote, Android uygulamalarını başlatmaktan sorumlu olan süreç olduğundan, bundan sonraki tüm başlatılan uygulamaların yeni yapılandırılmış CA sertifikalarını kullanmasını sağlamak için bu adım gereklidir. Kullanılan komut:

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

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

4. Çalışan Uygulamalara Değişiklik Uygulama: Zaten çalışan uygulamalara değişiklikleri uygulamak için, nsenter tekrar kullanılarak her uygulamanın ad alanına bireysel olarak girilir ve benzer bir bağlama montajı 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

5. Alternatif Yaklaşım - Yumuşak Yeniden Başlatma: Alternatif bir yöntem, init sürecinde (PID 1) bind mount işlemi gerçekleştirmek ve ardından işletim sistemini stop && start komutlarıyla yumuşak bir şekilde yeniden başlatmaktır. Bu yaklaşım, değişikliklerin tüm ad alanlarına yayılmasını sağlayarak her bir çalışan uygulamayı ayrı ayrı ele alma ihtiyacını ortadan kaldırır. Ancak, bu yöntem genellikle yeniden başlatmanın rahatsızlığı nedeniyle daha az tercih edilmektedir.

Referanslar

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