Terminalden Herhangi Bir Mac Uygulamasının İmzasını ve Noter Onayını Kontrol Edin

Gatekeeper, indirilen bir uygulamayı ilk açtığınızda bu kontrolü otomatik olarak çalıştırır ve çoğu zaman ayrıntıları asla görmezsiniz; bir iletişim kutusu görünür, üzerine tıklarsınız ve işlem tamamdır. Bu laboratuvar, Gatekeeper'ın ne gördüğünü görmekle ilgilidir: uygulamayı hangi geliştiricinin imzaladığı, imzanın sağlam olup olmadığı, Apple'ın noter servisinin onu kontrol edip etmediği ve uygulama çalıştırıldığında ne yapmasına izin verildiği. Buradaki her komut, Xcode'un komut satırı araçlarıyla birlikte gelir (xcode-select --install henüz sahip değilseniz) ve bunların her biri salt okunurdur; uygulamayı denetliyor, değiştirmiyorsunuz.

İmzanın kendisi: codesign -dvvv

codesign, Apple'ın kod imzalarını oluşturmaya ve incelemeye yönelik aracıdır. -d bayrağı, bir yolda imzalı kod hakkındaki bilgileri görüntüler ve kılavuz sayfası başına, "Ayrıntı düzeyinin artması daha fazla çıktı üretir" - böylece -dvvv (görüntü, üç ayrıntılı düzey) size tek bir komutla tam resmi elde eder:

$ codesign -dvvv /Applications/Example.app
# example output, trimmed to the fields that matter
Executable=/Applications/Example.app/Contents/MacOS/Example
Identifier=com.example.app
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=... flags=0x10000(runtime) hashes=...
Signature size=4741
Authority=Developer ID Application: Example Software LLC (ABCDE12345)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Team Identifier=ABCDE12345
Runtime Version=14.0.0

Her seferinde okunacak dört alan. Authority sertifika zinciridir: normal, harici bir uygulama, Developer ID Certification Authority yoluyla Apple Root CA ile bitmeli ve üst satırda geliştiricinin adı belirtilmelidir. Team Identifier, Apple'ın geliştirici hesabı için on karakterlik kimliğidir; aynı şirketten geldiğine inandığınız uygulamalar arasında karşılaştırılacak değerdir, çünkü sürümleri arasında değişmez. flags=0x10000(runtime), Apple'ın noter onayı için gerektirdiği bir dizi ek kısıtlama (sürece kod eklenmesine direnmek gibi) olan güçlendirilmiş çalışma zamanının etkinleştirildiği anlamına gelir. Ve herhangi bir Authority satırının bulunmaması - yalnızca Signature=adhoc - uygulamanın imzasız olduğu veya Apple'a herhangi bir zincir olmaksızın kendinden imzalı olduğu anlamına gelir.

İmza hâlâ şu dosyalarla eşleşiyor mu: --verify --deep --strict

İmza, imzalama sırasında belirli bir bayt kümesi hakkında verilen sözdür. --verify bu sözün hala geçerli olup olmadığını kontrol eder - kılavuz sayfası başına "bu yol(lar)daki kodun imzalandığını, imzanın geçerli olduğunu ve tüm mühürlü bileşenlerin değiştirilmediğini" doğrular. Tek bir dosya değil, iç içe geçmiş kaynaklar, çerçeveler ve yardımcı yürütülebilir dosyalar ile dolu bir dizin olan bir uygulama paketi için iki ekstra işaret önemlidir:

$ codesign --verify --deep --strict --verbose=2 /Applications/Example.app
/Applications/Example.app: valid on disk
/Applications/Example.app: satisfies its Designated Requirement

--deep önemlidir, çünkü kılavuz sayfası başına, iç içe geçmiş içeriğin doğrulanması varsayılan olarak "iç içe geçmiş koddaki değişiklikleri tespit edemeyebilecek yüzeysel bir araştırmayla sınırlıdır" - derin mod, yalnızca dış paketi değil, her gömülü çerçeveyi ve yardımcı aracı yinelemeli olarak doğrular. --strict, Apple'ın varsayılan olarak açık olmayacak kadar önemli olduğunu düşündüğü ekstra kontroller ekler; buna paket içindeki herhangi bir sembolik bağlantının "paket içindeki mühürlü dosyalara işaret etmesi", uygulamanın dışına veya mühürsüz bir şeye işaret eden birini reddetmesi de dahildir - imzasız bir yükü başka şekilde yasal olarak imzalanmış bir pakete kaçırmak için bilinen bir hile. Her iki kontrol de başarısız olursa, code failed to satisfy specified code requirement veya hangi iç içe geçmiş öğenin orijinal olarak mühürlenenle tam olarak eşleşmediğini belirten bir not göreceksiniz - bu satırı okuyun, dosyayı adlandırır.

Yetkilerin okunması

Yetkiler, bir uygulamaya imzanın verdiği belirli izinlerdir (kamera erişimi, korumalı alan olmadan ağa erişme yeteneği, kitaplık doğrulamasını devre dışı bırakma vb.). codesign -d --entitlements - bunları çıkarır; kılavuz sayfasına göre, verilen yola "Gömülü yetki verileri aynı şekilde çıkarılacak ve buraya yazılacaktır" ve - standart çıktı anlamına gelir:

$ codesign -d --entitlements - /Applications/Example.app
# example output, trimmed
<key>com.apple.security.cs.disable-library-validation</key>
<true/>
<key>com.apple.security.network.client</key>
<true/>
<key>com.apple.security.device.camera</key>
<true/>

Yetkilerin çoğu dikkat çekici değildir ve uygulamanın açıkça ihtiyaç duyduğu şeylerle eşleşir; kamera erişimi isteyen bir görüntülü arama uygulaması bir bulgu değildir. Üzerinde durmaya değer olan disable-library-validation'dir: bu, uygulamanın kendi imzalı paketinin dışından kod yükleyeceği anlamına gelir; bu, bazı eklenti tabanlı yazılımlar için normal bir ihtiyaçtır ve çoğu uygulamanın gerektirdiğinden daha geniş bir kapıdır. Bu, otomatik bir tehlike işareti değil, dikkat edilmesi gereken bir ayrıntıdır ve tam olarak sormadan göremeyeceğiniz türden bir ayrıntıdır.

Apple'ın noter servisi bunu gerçekten kontrol etti mi: spctl ve zımba

Geçerli bir imza yalnızca bir uygulamanın geliştirici tarafından imzalanmasından bu yana değiştirilmediğini kanıtlar; Apple'ın uygulamaya bakıp bakmadığı hakkında hiçbir şey söylemez. Noter onayının eklediği şey budur. Apple'ın kendi belgeleri, otomatik noterlik hizmetini "yazılımınızdaki kötü amaçlı bileşenleri taramak, kod imzalama sorunlarını kontrol etmek ve sonuçları hızlı bir şekilde size geri göndermek" olarak tanımlıyor. Geçtiğinde, "noter hizmeti yazılımınızı zımbalamanız için bir bilet oluşturur; noter hizmeti ayrıca bu bileti Gatekeeper'ın bulabileceği yerde çevrimiçi olarak yayınlar."

spctl --assess, kendiniz çıkarım yapmak yerine Gatekeeper'ın kendi politika motoruna karar sormanın pratik yoludur. Kılavuz sayfası başına, --assess "verilen dosyalar üzerinde bir değerlendirme gerçekleştirir" ve daha fazla ayrıntı için tekrarlanan -v / --verbose basitçe "daha ayrıntılı çıktı" istemek olarak tanımlanır:

$ spctl --assess -vv /Applications/Example.app
/Applications/Example.app: accepted
source=Notarized Developer ID

source=Notarized Developer ID görmek istediğiniz sonuçtur; bu, ister uygulamaya zımbalanmış ister çevrimiçi bulunmuş olsun, Gatekeeper'ın geçerli bir Geliştirici Kimliği imzası ve noter onay bileti bulduğu anlamına gelir. source=Unnotarized Developer ID sonucu, uygulamanın imzalandığı ancak Apple'ın bunu noter tasdik etmediği (veya henüz onaylamadığı) anlamına gelir ve düz rejected, Gatekeeper'ın uygulamanın varsayılan yapılandırmasında başlatılmasını engelleyeceği anlamına gelir.

Özellikle zımbayı kontrol etmek için, xcrun stapler validate, Gatekeeper'dan çevrimiçi olarak aramasını istemek yerine, uygulamaya fiziksel olarak eklenen bileti arar; bir uygulamanın hiçbir internet bağlantısı olmadan da doğru şekilde değerlendirileceğini doğrulamak için kullanışlıdır:

$ xcrun stapler validate /Applications/Example.app
Processing: /Applications/Example.app
The validate action worked!

Karantina bayrağı: ilk çalıştırma kontrolünün nereden geldiği

Apple'ın Platform Güvenliği kılavuzunda "Gatekeeper ayrıca indirilen yazılım tarafından yazılan dosyaların kaynağını da izler" ve "indirilen yazılımı ilk kez açmadan önce kullanıcı onayı ister" şeklinde açıklanmaktadır. Bunun arkasındaki mekanizma, Safari, Mail ve diğer uygulamaların ağdan kaydettikleri her şeye eklediği genişletilmiş com.apple.quarantine özelliğidir. xattr -l bunu listeler ve kılavuz sayfasına göre bu seçenek "hem nitelik adlarının hem de karşılık gelen değerlerin görüntülenmesine neden olur":

$ xattr -l ~/Downloads/Example.dmg
com.apple.quarantine: 0081;65e1a2b3;Safari;

Hiçbir çıktı olmaması, dosyanın karantina bayrağı taşımadığı anlamına gelir; ya yerel olarak oluşturulmuştur, özniteliği ayarlamayan bir yoldan gelmiştir (bazı arşiv araçları ve paket yöneticileri bunu atlar) ya da bayrak xattr -d com.apple.quarantine ile manuel olarak kaldırılmıştır. Bu son durum, farklı bir nedenden dolayı bilinmeye değer: Bu, insanların güvendikleri veya güvendiklerini düşündükleri dosyalar üzerinde Gatekeeper'ın ilk çalıştırma denetimini tamamen atladığı belgelenmiş bir yoldur ve alışılmadık bir terminal talimatları dizisinden yapıştırmak yerine üzerinde kasıtlı olarak düşünmeye değer.

Çalışılmış bir karşılaştırma: aynı geliştiriciyi iddia eden iki uygulama

Tüm bunları bir arada kullanmanın somut bir yolu: Diyelim ki, her ikisinin de aynı şirkete ait olduğu iddia edilen bir uygulamanın iki kopyasına sahipsiniz; biri geliştiricinin kendi sitesinden, diğeri ise birisinin size gönderdiği bağlantıdan. Her ikisinde de codesign -dvvv komutunu çalıştırın ve Team Identifier satırını karşılaştırın; bu, belirli bir Apple Geliştirici hesabına bağlı on karakterlik bir dizedir ve görünen ad veya paket tanımlayıcısından farklı olarak, ikinci bir tarafın, söz konusu hesabın imzalama sertifikasına erişmeden gelişigüzel yeniden üretebileceği bir şey değildir. İki kopya farklı Ekip Tanımlayıcıları gösteriyorsa aynı uygulamanın iki yapısına bakmıyorsunuz demektir; iki farklı imzalayana bakıyorsunuz; bunlardan biri indirme işleminde hak talebinde bulunulan kişi değil. Bunu şüpheli kopyada spctl --assess -vv ile takip edin; kopyada noter tasdikli orijinalle aynı olduğunu iddia eden uyumsuz veya eksik noter tasdik kaynağı yalnızca bir ipucu değil, onaydır.

Resmin tamamını ve gerçek tehlike işaretlerini okumak

• Hiç Authority zinciri yok veya Apple Root CA'da bitmeyen bir zincir; uygulamanın arkasında sorumlu bir geliştirici kimliği yok.
• codesign --verify başarısız oluyor, özellikle de belirli bir iç içe geçmiş dosyayı adlandıran bir mesajla; paket içinde bir şeyler imzalandıktan sonra değişti.
• spctl --assess, rejected değerini döndürür veya codesign -dvvv içindeki Ekip Tanımlayıcısı, o ürün için beklediğiniz geliştiriciyle eşleşmez.
• Kendiniz indirmediğiniz veya olağandışı bir kanaldan gelen (bir komut dosyası, başka bir şeye benzeyecek şekilde yeniden adlandırılan bir e-posta eki) bir dosyaya açıkça eklenmiş bir karantina bayrağı.
• Belirtilen amacı açıkça bunlara ihtiyaç duymayan bir uygulamada tamamen açık olan yetkiler (tam disk erişimi, devre dışı bırakılmış kitaplık doğrulama, sınırsız ağ erişimi).

Bu kontrollerin hiçbiri, uygulamanın çalışmaya başladıktan ve ağa bağlandıktan sonra gerçekte ne yaptığına bakmaz; bu, imzasından ziyade trafiği izlenerek yanıtlanan farklı türde bir sorudur. Temiz bir imza ve geçerli bir noter onay belgesi gerçek, anlamlı bir zemindir: Apple'ın tam olarak bu bayt kümesini gördüğünü ve kontrol sırasında herhangi bir kod imzalama sorunu bulamadığını söylüyorlar. Bunlar bir uygulamaya güvenmenin başlangıcıdır, sonu değil.

FireAI ve HisnLabs burada nereye oturuyor

A clean signature and a stapled ticket say an app hasn’t been tampered with since Apple checked it — they say nothing about what it connects to afterward, which is the question FireAI’s per-app rules and on-device review are built to keep answering, signature by signature, connection by connection.

FireAI, HisnLabs’in kendi ürünüdür: doğrudan Mac’inizde çalışan, yapay zekâ destekli bir güvenlik duvarı. Uygulamalarınızın kurduğu her bağlantıyı sade bir dille gösterir ve Mac’inizden neyin çıkacağına sizin karar vermenizi sağlar — yapay zekâsı yerel olarak çalışır, yani trafiğiniz asla bize ya da başka birine gönderilmez. HisnLabs güvenlik araştırma ekibi bu kararların isabetli kalmasını sağlayan ekiptir: hangi alan adlarının sıradan telemetri, hangilerinin gerçek bir hizmet olduğunu kataloglar, bir bağlantının ardındaki ülkeyi ve ağı izler ve cihaz üzerindeki modeli (Autopilot özelliği) gerçek trafik örüntüleriyle eğitir — üstelik bunların hiçbiri Mac’inizden dışarı çıkmadan.

Arkasındaki teknik kararları okuyabilir ya da FireAI’yi 17 gün boyunca deneyebilirsiniz: HisnLabs’ten FireAI.