macOS Launch/Environment Constraints & Trust Cache
Last updated
Last updated
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
macOS'taki başlatma kısıtlamaları, bir sürecin nasıl, kim tarafından ve nereden başlatılacağını düzenleyerek güvenliği artırmak amacıyla tanıtılmıştır. macOS Ventura'da başlatılan bu kısıtlamalar, her sistem ikili dosyasını farklı kısıtlama kategorilerine ayıran bir çerçeve sağlar; bu kategoriler, sistem ikili dosyalarını ve bunların ilgili hash'lerini içeren güven cache'inde tanımlanmıştır. Bu kısıtlamalar, sistemdeki her yürütülebilir ikili dosyayı kapsar ve belirli bir ikili dosyanın başlatılması için gereksinimleri belirleyen bir dizi kural içerir. Kurallar, bir ikilinin karşılaması gereken kendi kısıtlamalarını, ebeveyn sürecinin karşılaması gereken ebeveyn kısıtlamalarını ve diğer ilgili varlıkların uyması gereken sorumlu kısıtlamaları kapsar.
Mekanizma, macOS Sonoma'dan itibaren Ortam Kısıtlamaları aracılığıyla üçüncü taraf uygulamalara da uzanır ve geliştiricilerin uygulamalarını korumalarına olanak tanır; bu, bir dizi anahtar ve değer belirleyerek ortam kısıtlamaları tanımlamayı içerir.
Başlatma ortamı ve kütüphane kısıtlamalarını, ya launchd özellik listesi dosyalarında ya da kod imzalamada kullandığınız ayrı özellik listesi dosyalarında tanımlarsınız.
4 tür kısıtlama vardır:
Kendi Kısıtlamaları: çalışan ikiliye uygulanan kısıtlamalar.
Ebeveyn Süreci: sürecin ebeveynine uygulanan kısıtlamalar (örneğin launchd bir XP hizmeti çalıştırıyorsa)
Sorumlu Kısıtlamalar: hizmeti çağıran sürece uygulanan kısıtlamalar bir XPC iletişimi içinde
Kütüphane yükleme kısıtlamaları: Yüklenebilecek kodu seçici olarak tanımlamak için kütüphane yükleme kısıtlamalarını kullanın
Bu nedenle, bir süreç başka bir süreci başlatmaya çalıştığında — execve(_:_:_:) veya posix_spawn(_:_:_:_:_:_:) çağrısı yaparak — işletim sistemi, yürütülebilir dosyanın kendi kısıtlamasını karşılayıp karşılamadığını kontrol eder. Ayrıca, ebeveyn sürecinin yürütülebilir dosyasının yürütülebilir dosyanın ebeveyn kısıtlamasını karşılayıp karşılamadığını ve sorumlu sürecin yürütülebilir dosyasının yürütülebilir dosyanın sorumlu süreç kısıtlamasını karşılayıp karşılamadığını kontrol eder. Bu başlatma kısıtlamalarından herhangi biri karşılanmazsa, işletim sistemi programı çalıştırmaz.
Bir kütüphane yüklenirken kütüphane kısıtlamasının herhangi bir kısmı doğru değilse, süreciniz kütüphaneyi yüklemez.
Bir LC, gerçekler ve mantıksal işlemler (ve, veya..) ile oluşturulmuş ve gerçekleri birleştiren bir yapıdır.
Bir LC'nin kullanabileceği gerçekler belgelenmiştir. Örneğin:
is-init-proc: Yürütülebilir dosyanın işletim sisteminin başlatma süreci (launchd) olup olmadığını belirten bir Boolean değeri.
is-sip-protected: Yürütülebilir dosyanın Sistem Bütünlüğü Koruması (SIP) tarafından korunan bir dosya olup olmadığını belirten bir Boolean değeri.
on-authorized-authapfs-volume: İşletim sisteminin yürütülebilir dosyayı yetkilendirilmiş, kimlik doğrulaması yapılmış bir APFS hacminden yükleyip yüklemediğini belirten bir Boolean değeri.
on-authorized-authapfs-volume: İşletim sisteminin yürütülebilir dosyayı yetkilendirilmiş, kimlik doğrulaması yapılmış bir APFS hacminden yükleyip yüklemediğini belirten bir Boolean değeri.
Cryptexes hacmi
on-system-volume: İşletim sisteminin yürütülebilir dosyayı şu anda önyüklenmiş sistem hacminden yükleyip yüklemediğini belirten bir Boolean değeri.
/System içinde...
...
Bir Apple ikili dosyası imzalandığında, bu onu güven cache'inde bir LC kategorisine atar.
iOS 16 LC kategorileri tersine çevrildi ve burada belgelenmiştir.
Mevcut LC kategorileri (macOS 14 - Somona) tersine çevrildi ve açıklamaları burada bulunabilir.
Örneğin Kategori 1 şudur:
(on-authorized-authapfs-volume || on-system-volume): Sistem veya Cryptexes hacminde olmalıdır.
launch-type == 1: Bir sistem hizmeti olmalıdır (plist in LaunchDaemons).
validation-category == 1: Bir işletim sistemi yürütülebilir dosyası.
is-init-proc: Launchd
Bununla ilgili daha fazla bilgiye buradan ulaşabilirsiniz, ama temelde, AMFI (AppleMobileFileIntegrity) içinde tanımlanmıştır, bu yüzden KEXT'i almak için Kernel Geliştirme Kitini indirmeniz gerekir. kConstraintCategory ile başlayan semboller ilginç olanlardır. Bunları çıkardığınızda, ASN.1 Decoder veya python-asn1 kütüphanesi ve dump.py scripti ile çözmeniz gereken DER (ASN.1) kodlu bir akış elde edeceksiniz, andrivet/python-asn1 size daha anlaşılır bir dize verecektir.
Bunlar üçüncü taraf uygulamalarda yapılandırılan Başlatma Kısıtlamalarıdır. Geliştirici, uygulamasında kendisine erişimi kısıtlamak için kullanacağı gerçekleri ve mantıksal operatörleri seçebilir.
Bir uygulamanın Ortam Kısıtlamalarını şu şekilde listelemek mümkündür:
macOS'ta birkaç güven cache'i bulunmaktadır:
/System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/BaseSystemTrustCache.img4
/System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/StaticTrustCache.img4
/System/Library/Security/OSLaunchPolicyData
Ve iOS'ta /usr/standalone/firmware/FUD/StaticTrustCache.img4 içinde olduğu görünmektedir.
Apple Silicon cihazlarda çalışan macOS'ta, eğer bir Apple imzalı ikili güven cache'inde yoksa, AMFI onu yüklemeyi reddedecektir.
Önceki güven cache dosyaları IMG4 ve IM4P formatındadır, IM4P IMG4 formatının yükleme bölümüdür.
Veritabanlarının yükleme bölümünü çıkarmak için pyimg4 kullanabilirsiniz:
(Bir diğer seçenek, img4tool aracını kullanmak olabilir; bu araç, eski bir sürüm olmasına rağmen M1'de bile çalışacak ve x86_64 için uygun konumlara kurarsanız çalışacaktır).
Artık bilgileri okunabilir bir formatta almak için trustcache aracını kullanabilirsiniz:
Güven cache'i aşağıdaki yapıyı takip eder, bu nedenle LC kategorisi 4. sütundur
Sonra, verileri çıkarmak için bu scripti kullanabilirsiniz.
Bu verilerden, 0 değerine sahip başlatma kısıtlamaları olan uygulamaları kontrol edebilirsiniz; bunlar kısıtlanmamış olanlardır (buradan kontrol edin her değerin ne olduğunu görmek için).
Başlatma Kısıtlamaları, sürecin beklenmedik koşullarda çalıştırılmayacağından emin olarak birkaç eski saldırıyı azaltır: Örneğin, beklenmedik yerlerden veya beklenmedik bir ana süreç tarafından çağrılmaktan (sadece launchd'nin başlatması gerekiyorsa).
Ayrıca, Başlatma Kısıtlamaları gerileme saldırılarını da azaltır.
Ancak, yaygın XPC kötüye kullanımlarını, Electron kod enjeksiyonlarını veya dylib enjeksiyonlarını kütüphane doğrulaması olmadan azaltmaz (yükleyebilecek takım kimlikleri bilinmiyorsa).
Sonoma sürümünde, dikkat çekici bir nokta, daemon XPC hizmetinin sorumluluk yapılandırmasıdır. XPC hizmeti kendisinden sorumludur, bağlanan istemcinin sorumlu olmasının aksine. Bu, geri bildirim raporu FB13206884'te belgelenmiştir. Bu yapılandırma hatalı görünebilir, çünkü XPC hizmeti ile belirli etkileşimlere izin verir:
XPC Hizmetini Başlatma: Bir hata olarak varsayıldığında, bu yapılandırma, XPC hizmetini saldırgan kod aracılığıyla başlatmaya izin vermez.
Aktif Bir Hizmete Bağlanma: Eğer XPC hizmeti zaten çalışıyorsa (muhtemelen orijinal uygulaması tarafından etkinleştirilmişse), ona bağlanmak için hiçbir engel yoktur.
XPC hizmetinde kısıtlamalar uygulamak, potansiyel saldırılar için pencereyi daraltarak faydalı olabilir, ancak temel endişeyi ele almaz. XPC hizmetinin güvenliğini sağlamak, esasen bağlanan istemcinin etkili bir şekilde doğrulanmasını gerektirir. Bu, hizmetin güvenliğini güçlendirmenin tek yoludur. Ayrıca, bahsedilen sorumluluk yapılandırmasının şu anda çalıştığını belirtmekte fayda var; bu, tasarlanan amaçla uyumlu olmayabilir.
Uygulamanın LaunchService tarafından açılması gerektiği gereksinimi olsa bile (ebeveyn kısıtlamalarında). Bu, open kullanılarak (çevre değişkenlerini ayarlayabilir) veya Launch Services API kullanılarak (çevre değişkenleri belirtilebilir) gerçekleştirilebilir.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
