macOS Launch/Environment Constraints & Trust Cache
Last updated
Last updated
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Eğitim AWS Kırmızı Takım Uzmanı (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Eğitim GCP Kırmızı Takım Uzmanı (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ı belirli 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üvenilir önbellek iç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 kaydedilen kısıtlama sözlüklerinde tanımlarsınız.
4 tür kısıtlama vardır:
Kendi Kısıtlamaları: çalışan ikili dosyaya uygulanan kısıtlamalar.
Ebeveyn Süreci: sürecin ebeveynine uygulanan kısıtlamalar (örneğin launchd bir XP hizmetini ç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 korunup korunmadığı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 dosya güvenilir önbellek içinde bir LC kategorisine atanır.
iOS 16 LC kategorileri tersine çevrilmiş ve burada belgelenmiştir.
Mevcut LC kategorileri (macOS 14 - Somona) tersine çevrilmiş 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 servisi 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 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 vardı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ı azaltmış olur: Ö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ı aşağı yönlü saldırıları 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, bağlanan istemcinin sorumlu olmasının aksine, kendisinden sorumludur. Bu, geri bildirim raporu FB13206884'te belgelenmiştir. Bu yapı, XPC hizmeti ile belirli etkileşimlere izin verdiği için hatalı görünebilir:
XPC Hizmetini Başlatma: Bir hata olarak varsayılırsa, bu yapı, saldırgan kod aracılığıyla XPC hizmetinin başlatılmasına 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 hizmetine 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 tasarımla uyumlu olmayabilir.
Uygulamanın LaunchService tarafından açılması gerektiği durumunda (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)
