Install Burp Certificate

HackTricks'i Destekleyin

Sanal Makinede

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

Sertifikayı Der formatında dışa aktarın ve Android'in anlayabileceği bir forma dönüştürelim. Burp sertifikasını AVD'deki Android makinesinde 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

Makine yeniden başlatmayı tamamladıktan sonra 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 Burp sertifikasını yüklemek için önceki adımları 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:

  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 İndirilenler klasörüne kaydedin ve Sertifika yükle -> CA sertifikası kısmına gidin.

  • Sertifikanın doğru bir şekilde kaydedildiğini kontrol etmek için Güvenilir kimlik bilgileri -> KULLANICI kısmına gidin.

  1. 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, Depodan yükle seçeneğine tıklayın, .zip modülünü seçin ve yüklendikten sonra 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 uygulama 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 ayırma veya üstüne yazma girişimleri de 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ç aynı zamanda Zygote sürecini de başlatır. Bu süreç, özel bir /apex montajını içeren yeni bir montaj ad alanı ile uygulama süreçlerini başlatmaktan sorumludur ve böylece bu dizindeki değişikliklerin diğer süreçlerden izole edilmesini sağlar.

Yine de, /apex dizinindeki sistem güvenilir CA sertifikalarını değiştirmek isteyenler için bir çözüm bulunmaktadır. Bu, /apex'i özel yayılmayı kaldıracak şekilde manuel olarak yeniden bağlamayı içerir ve böylece yazılabilir hale getirir. Süreç, /apex/com.android.conscrypt içeriğini başka bir yere kopyalamayı, /apex/com.android.conscrypt dizinini salt okunur kısıtlamasını ortadan kaldırmak için ayırmayı ve 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 olmayan APEX 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
  1. CA Sertifikalarını Hazırlama: Yazılabilir dizinin kurulumu sonrasında, kullanılmak istenen CA sertifikaları bu dizine kopyalanmalıdır. Bu, /apex/com.android.conscrypt/cacerts/ dizininden varsayılan sertifikaların kopyalanmasını içerebilir. Bu sertifikaların izinlerinin ve SELinux etiketlerinin uygun şekilde ayarlanması önemlidir.

  2. 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çtir ve 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.

  1. Ç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 ayrı ayrı 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
  1. 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ğlar ve her bir çalışan uygulamayı ayrı ayrı ele alma ihtiyacını ortadan kaldırır. Ancak, bu yöntem genellikle yeniden başlatmanın getirdiği rahatsızlık nedeniyle daha az tercih edilmektedir.

Referanslar

Support HackTricks

Last updated