Turkish - Ht
HackTricks Training Twitter Linkedin Sponsor

Install Burp Certificate

Sıfırdan kahraman olana kadar AWS hackleme becerilerini htARTE (HackTricks AWS Red Team Expert) ile öğrenin!

HackTricks'ı desteklemenin diğer yolları:

Sanal Makinede

İlk olarak, Burp'tan Der sertifikasını indirmeniz gerekmektedir. Bunun için Proxy --> Options --> Import / Export CA certificate adımlarını takip edebilirsiniz

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ğiyle çalıştırmanız gerekmektedir. Ö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

Ardından, burp sertifikasını yapılandırmak için şunları yapın:

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şlatıldığında, burp sertifikası tarafından kullanılacaktır!

Magisc Kullanımı

Eğer cihazınızı Magisc ile rootladıysanız (belki bir emülatör), ve dosya sistemi salt okunur olduğu için Burp sertifikasını yüklemek için önceki adımları takip edemiyorsanız, başka bir yol var.

Bu videoda açıklandığı gibi şunları yapmanız gerekiyor:

  1. Bir CA sertifikası yükleyin: DER Burp sertifikasını .crt uzantısına değiştirerek mobil cihaza sürükleyip bırakın ve İndirilenler klasörüne kaydedin, ardından Bir sertifika yükle -> CA sertifikası yolunu izleyin

  • Sertifikanın doğru şekilde kaydedildiğini kontrol edin, Güvenilir kimlik bilgileri -> KULLANICI'ya gidin

  1. Sistemde güvenilir yapın: Magisc modülünü MagiskTrustUserCerts (bir .zip dosyası) indirin, telefonunuza sürükleyip bırakın, telefonunuzdaki Magics uygulamasına gidin, Modüller bölümüne gidin, Depodan yükle'yi tıklayın, .zip modülünü seçin ve kurulum tamamlandıktan sonra telefonu yeniden başlatın:

  • Yeniden başlattıktan sonra, Güvenilir kimlik bilgileri -> SİSTEM'e gidin ve Postswigger sertifikasının orada olduğunu kontrol edin

Android 14 Sonrası

En son Android 14 sürümünde, sistem-güvenilir Sertifika Yetkilisi (CA) sertifikalarının işlenişinde önemli bir değişiklik gözlemlenmiştir. Daha önce, bu sertifikalar /system/etc/security/cacerts/ dizininde bulunuyor ve kök ayrıcalıklarına sahip kullanıcılar tarafından erişilebilir ve değiştirilebilirdi, bu da sisteme hemen uygulanmasına olanak tanıyordu. Ancak, Android 14 ile, depolama yeri /apex/com.android.conscrypt/cacerts dizinine taşındı, bu da doğası gereği değiştirilemez olan /apex yolundaki bir dizindir.

APEX cacerts yolunu yazılabilir olarak yeniden bağlamaya yönelik girişimler başarısızlıkla karşılaşır, çünkü sistem böyle işlemlere izin vermez. Dizin üzerine geçici bir dosya sistemi (tmpfs) ile aşma veya kaldırma girişimleri bile değiştirilemezliği atlatmaz; uygulamalar, dosya sistemi seviyesinde yapılan değişikliklere rağmen orijinal sertifika verilerine erişmeye devam eder. Bu direnç, /apex bağının ÖZEL yayılım ile yapılandırılmış olmasından kaynaklanır, bu da /apex dizinindeki değişikliklerin diğer işlemleri etkilememesini sağlar.

Android'in başlatılması, işletim sistemi başladığında aynı zamanda Zygote işlemini başlatan init işlemi ile başlar. Bu işlem, yeni bir bağlama ad alanı içeren bir Zygote işlemi başlatarak uygulama işlemlerini başlatma sorumluluğunu üstlenir, bu da bu dizindeki değişiklikleri diğer işlemlerden 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 tekrar yazılabilir hale getirmek için manuel olarak yeniden bağlamayı içerir. Bu işlem, /apex/com.android.conscrypt içeriğini başka bir konuma kopyalamayı, /apex/com.android.conscrypt dizinini bağlamayı okuma-yazma kısıtlamasını kaldırmak için ve ardından içeriği orijinal konumlarına /apex içinde geri yüklemeyi gerektirir. Bu yaklaşım, sistem çökmelerini önlemek için hızlı bir şekilde hareket etmeyi gerektirir. Bu değişikliklerin sistem genelinde uygulanmasını sağlamak için system_server'ı yeniden başlatmanız önerilir, bu da tüm uygulamaları 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"

NSEnter üzerinden Bind-mounting

  1. Yazılabilir Bir Dizin Oluşturma: İlk olarak, mevcut olmayan APEX olmayan sistem sertifika dizininin üzerine bir tmpfs bağlanarak 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 dizinin kurulumunu takiben, kullanmayı amaçladığınız CA sertifikaları bu dizine kopyalanmalıdır. Bu, varsayılan sertifikaların /apex/com.android.conscrypt/cacerts/ dizininden kopyalanmasını gerektirebilir. Bu sertifikaların izinleri ve SELinux etiketleri uygun şekilde ayarlanması önemlidir.

  2. Zygote için Bağlama Montajı: nsenter kullanılarak, Zygote'un bağlama ad alanına girilir. Android uygulamalarını başlatma işleminden sorumlu olan Zygote, bundan sonra başlatılan tüm uygulamaların yeni yapılandırılmış CA sertifikalarını kullanmasını sağlamak için bu adımı gerektirir. Kullanılan komut şudur:

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

Bu, her yeni uygulamanın güncellenmiş CA sertifikaları kurulumuna uyacağından emin olur.

  1. Çalışan Uygulamalara Değişiklikler 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ğ 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 işlemine (PID 1) bağlama işlemini gerçekleştirmeyi ve işletim sistemini stop && start komutlarıyla yumuşak bir şekilde yeniden başlatmayı içerir. Bu yaklaşım, değişikliklerin tüm ad alanlarına yayılmasını sağlayacak ve her çalışan uygulamayı tek tek ele almaya gerek kalmayacaktır. Bununla birlikte, bu yöntem genellikle yeniden başlatmanın rahatsızlığı nedeniyle tercih edilmemektedir.

Referanslar

Sıfırdan Kahraman'a AWS hackleme öğrenin htARTE (HackTricks AWS Red Team Expert)!

HackTricks'i desteklemenin diğer yolları:

PreviousGoogle CTF 2018 - Shall We Play a Game?NextIntent Injection

Last updated