- macOS’un TCC izin sistemi, bir açık nedeniyle kullanıcıya yanıltıcı biçimde gösterilen izin istemi açılır pencereleri çıkarabiliyordu
- Bu açık CVE-2025-31250 olarak kaydedildi ve kullanıcının verdiği onayın başka bir uygulamaya uygulanması sorununu içeriyor
- Kötü amaçlı bir uygulamanın, izin istemi penceresini güvenilir bir uygulamanın adıyla göstererek kullanıcı onayını alma amaçlı spoofing saldırısı olasılığı bulunuyor
- Açık, Apple’ın macOS Sequoia 15.5 sürümünde yamalandı; ancak diğer sürümlerde hâlâ yamalanmamış durumda
- İzin verme geçmişini doğrulama ve geri almanın zorluğu ile birlikte, gelecekte de benzer açıkların ortaya çıkma ihtimali bulunuyor
Önemli düzeltme
- Bu açık macOS Sequoia 15.5’te yamalanmış olsa da, macOS Ventura 13.7.6 ve macOS Sonoma 14.7.6 sürümlerinde henüz yamalanmadı
- Apple’ın güvenlik sürüm notlarında bildirimi yapan araştırmacının anılmadığı doğrulandı
- macOS Sonoma 14.7.6 doğrudan sanal makinede test edilerek açığın hâlâ sömürülebildiği doğrulandı
- Ventura 13.7.6’nın da aynı durumda olduğu tahmin ediliyor
- Apple’dan resmi yanıt bekleniyor
Giriş
- CVE-2025-31250 açığı, uygulamaların macOS’ta sahte izin istemi açılır pencereleri göstermesine olanak tanıyor
- “Application A” bir açılır pencere oluşturduğunda, pencerede “Application B” görünüyor ve sonuçta kullanıcının izin onayı “Application C”ye uygulanıyor
- Normalde bu üç uygulama aynı olur; ancak bu açık nedeniyle birbirinden farklı uygulamalar belirtilebiliyordu
- Bu da izin istemi pencerelerinin güvenilirliği açısından ciddi bir sorun yaratıyor
- Benzer “spoofing” yöntemleri daha önce HackTricks gibi kaynaklarda tanıtılmıştı; ancak bu açık daha basit bir yöntem kullanıyor
TCC
- TCC, Apple işletim sistemlerine yerleşik temel izin yönetim sistemidir
- İzinler, “tccd” daemon’una mesaj gönderilerek yönetilir; herkese açık API’ler de özel TCC framework işlevlerini çağırır
- Daemon, mesajlaşma için Apple’ın XPC API’sini kullanır
- Bu açık yamalanmadan önce, özel olarak hazırlanmış mesajlar gönderilerek izin istemi açılır penceresini gösteren uygulama ile gerçekte izni alan uygulama farklı belirtilebiliyordu
- Bu açığın neden ortaya çıktığını anlamak için Apple Events’e bakmak gerekiyor
Apple Events
Apple Events nedir
- Apple Events, macOS uygulamaları arasında süreçler arası iletişim yöntemidir
- 1993’te yayımlanan klasik kitaplar döneminden beri varlığını sürdüren bir protokoldür
- macOS X’in gelişi sonrasında da yapıya uygun biçimde yeniden tasarlanarak kullanılmaya devam etti
- Günümüzde çoğunlukla otomasyon (Automation) amacıyla kullanılır ve AppleScript ile JavaScript üzerinden betiklenir
- Windows’taki Script Host’a benzer ve geçmişte zararlı yazılım vektörü olarak da kötüye kullanılmıştır
Apple Events ve TCC
- macOS Mojave 10.14’ten itibaren Apple Events gönderimi için kullanıcı onayı zorunludur
- TCC’nin izin kayıt veritabanı (TCC.db), isteği yapan uygulamayı, servisi ve onay yanıtını kaydeder
- Apple Events’te izinlerin her alıcı uygulama için ayrı yönetilmesi gerektiğinden, TCC.db içindeki indirect object sütunu kullanılır
- TCC daemon’undaki TCCAccessRequestIndirect işlevi, bu sütunu kullanan mesajları işler
- Bu işlevdeki mantıksal bir hata, kullanıcıya gösterilen uygulama ile gerçekte izni alan uygulamanın farklı olabilmesine yol açıyordu
Kavram kanıtı (Proof-of-Concept)
- Swift kod örneği, izin istemi mesajını şu şekilde manipüle ediyor:
- Kullanıcı onayı açılır penceresinde,
spoofedBundle yolundaki uygulamanın adı gösteriliyor
- Gerçek izin hedefi olarak
actualBundleın bundle ID’si belirleniyor
- Sonuç olarak kullanıcı, güvenilir bir uygulama izin istiyormuş gibi görüyor; ancak gerçek izin kötü amaçlı uygulamaya veriliyor
indirect_object değeri boş bırakıldığında bile birçok TCC hizmeti hedeflenebiliyordu- Bu da kullanıcı izin onayının güvenilirliğinin çökmesine neden oluyor
- Saldırgan, kullanıcıyı kandırarak rastgele bir uygulamanın izin almasını sağlayabiliyor
Açığın sömürülmesi
Sınırlamalar ve dikkat çeken noktalar
- Yalnızca belirli TCC hizmetleri saldırıya açık olsa da, Microphone, Camera gibi önemli hizmetler hedeflenebiliyor
- Dosya/klasör izinleri gibi alanlarda ek koruma mekanizmaları nedeniyle etkinin büyük olmadığı görülüyor
- Kötü amaçlı uygulama, gerçekten izne ihtiyaç duyan başka bir uygulamanın yerine kullanıcıdan onay almak için sosyal mühendislik teknikleriyle birlikte kullanılabilir
Zamanlamanın önemi
- Açılır pencerenin gösterileceği an kritik önemdedir
- Kötü amaçlı uygulama, çalışan uygulamaları ve o anda önde olan uygulamayı algılayarak uygun anda açılır pencere gösterip kullanıcıyı şaşırtabilir
- Örneğin FaceTime çalışırken bir Camera izin penceresi gösterilirse, kullanıcı bunu normal bir izin isteği sanabilir
- Voice Memos çalışırken Microphone izin istemini spoof etme senaryosu da mümkündür
- Bağlama uygun anlar hedef alındığında saldırının başarı ihtimali artar
Geçmiş açıkların yeniden gündeme gelmesi
- TCC.db yolunun kullanıcının ana dizinine göre belirlenmesini kötüye kullanan açıklar daha önce de vardı
- 2020’ye kadar yalnızca
HOME ortam değişkenini değiştirerek sahte bir TCC.db kullanılabiliyordu ($HOMERun)
- Yamadan sonra da root yetkisi ve kullanıcı onayı gerekse de, sosyal mühendislik temelli spoofing ile birleştirildiğinde izin atlatma mümkün olabiliyor
- Kötü amaçlı uygulama, kullanıcıdan onay aldıktan sonra ana dizini değiştirip kayıt veritabanı ekleyerek sahte TCC.db üzerinden korumayı aşabiliyor
- Bu yöntemin test edilmesiyle TCC davranışının gerçekten etkilenebildiği doğrulandı
Zaman çizelgesi
1.
- 2024-05-02 : Apple Product Security’ye ilk bildirim yapıldı ve ek mesaj gönderildi
2.
- 2024-05-03 : Apple Product Security ek açıklama istedi ve yanıt verildi
- Aynı gün, tüm TCC’yi atlatma olasılığı keşfedilerek Apple’a yeniden bildirildi
3.
- 2024-05-04 : PoC testleri sürdürüldü ve ek güncelleme mesajı bırakıldı
4.
- 2024-05-06 : Apple Product Security, bilgi paylaşımı için teşekkür etti
5.
- Sonrasında da düzenli olarak yama durumu soruldu ve durum takip edildi; 2024-06 ile 2025-02 arasında Apple ile iletişim sürdü ancak açık uzun süre düzeltilmedi
6.
- 2025-05-12 : Bu hatayı düzelten sürüm yayımlandı
Sonuç
Diğer notlar
- TCC, System Settings uygulamasındaki Privacy & Security (eski adıyla Security & Privacy) bölümü ile ilgili otomasyon bölümünde gösterilir
- Ancak Apple Events ile ilgili onay kayıtları GUI’de görünmediğinden, kullanıcıların bunları doğrudan geri alması zordur
- CLI aracı
tccutil ile geri alma mümkündür; ancak bu pek bilinmez
- Yakın zamanda Apple Endpoint Security framework’üne TCC veritabanı değişikliklerini izleme özelliği eklendi
- Eğer beklendiği gibi çalışıyorsa, gerçekten izin alan uygulamanın hangisi olduğunu kullanıcıya bildirerek kötüye kullanımı önlemeye yardımcı olabilir
Apple’ın yaması
- Gerçek yama içeriği karmaşıktır; ancak dışarıdan rastgele belirlenmiş indirect object içeren mesajların tccd tarafından sessizce yok sayılması sağlanacak şekilde değiştirildi
- Davranış doğrulaması sonucunda artık spoofing’in mümkün olmadığı görüldü
- Eğer yama eksikse, ilerideki güncellemelerde ek önlemler gerekebilir
Son düşünceler
- Bu açığa “TCC, Who?” adı verildi
- Güvenlik araştırmacısının bakış açısından izin sistemlerinin güvenilirliğinin önemi bir kez daha vurgulanıyor
- İleride de benzer açıkların bulunabileceğine işaret ediliyor
- Kullanıcılara, macOS izin açılır pencerelerine körü körüne güvenmemeleri gerektiği mesajı veriliyor
1 yorum
Hacker News görüşü
Apple'da birinin bu yazıyı görme ihtimalinin çok düşük olmasına bel bağlayarak, her zaman söylemek istediğim şeyi yineleyeyim: Apple'ın, bilgisayar güncelleme yapmak ya da bir şeyler yüklemek istedi diye, rastgele zamanlarda "şimdi (yerel yönetici) parolasını gir" iletişim kutuları çıkarmayı bırakmasını diliyorum. Temel düzeyde teknik bilgisi olan biri bile web'de neredeyse aynı görünen sahte popup'lar yapabilir ve teknik olarak en üst %20'lik kesim dışında kalan kullanıcıların çoğu bunun gerçek mi yoksa tarayıcı içinde üretilmiş sahte bir şey mi olduğunu fark etmeyi bile düşünmez. Bu sorunu kökten çözmek için, normal yazılımların durduk yere, hiçbir uyarı vermeden, işin ortasında parola iletişim kutusu açmayacağı alışkanlığını kullanıcılara kazandırmak gerekir; ama mevcut macOS güvenlik arayüzü bunun tam tersini yapıyor. Menü çubuğunda renkli ve dikkat çekici bir simge göstermek ya da Windows'taki gibi kısa süreli bir güvenlik ekranı açmak gibi bir şeye dönüştürülmeli. Mevcut arayüz tasarımı gerçekten çok sorunlu
Bu popup'larda en nefret ettiğim şey, neden bunu istediğini, reddedersem ne olacağını ve fikrimi değiştirirsem bu ayarı sonradan nasıl değiştireceğimi hiç bilmemem. Bir uygulama "ayarlar panelini açıp XXX iznini verin" dediğinde hangi uygulama, hangi izin ve hangi anahtar olduğu net biçimde görülebiliyor; ama parola popup'ı böyle bir UX sunmuyor. Bu yüzden "capabilities" kavramını pek sevmemeye başladım; UX'i fazla kötü ve neredeyse kaçınılmaz biçimde öyle. Muhtemelen "uygulamayı tam olarak kullanmak için <root my computer>'a izin verin" gibi şeyler göreceğiz; mesajı satıcı belirlediğinde sonuç hep böyle oluyor. Hiç yardımcı olmayan bir UX
macOS hâlâ modal pencereleri pencereye bağlı şekilde gösterseydi bu biraz daha az yaşanırdı diye düşünüyorum. Tam çözülmezdi ama daha iyi olurdu. Şimdiki gibi modal araç çubuğunun üstüne bindiğinde, ilk bakışta tamamen "uygulamanın içindeymiş" gibi hissettiriyor. Steve Jobs Aqua demosunu yaparken de böyle ayrı yüzen modallerin kullanılabilirliği düşürdüğünü özellikle vurgulamıştı; şimdi ise Apple'ın her ekranda mobil UI kullanma yönündeki garip takıntısı yüzünden böyle olduğunu düşünüyorum
Teknik bilgisi olmayan aile üyelerim, yerel cihaz parolasıyla iCloud/Apple ID parolası arasındaki farkı bile bilmiyor; sonunda hangisi olursa olsun deneyip duruyorlar (sebebi de arayüzün belirsiz ve tutarsız olması). Apple eskiden Vista'nın UAC'siyle dalga geçerdi ama artık kendileri de aniden çıkan bildirimler ve özensiz arayüzlerle dolu
Yakın zamanda Linux'tan Mac'e geçtim ve rastgele çıkan root parolası popup'ları gerçekten kafamı karıştırdı. Hangi uygulamanın ya da komutun root yetkisi istediği ve bunun neden gerektiği hiç açıklanmadığı için birkaç kez izin verdikten sonra artık reddetmeye başladım. O zamandan beri popup çıkmıyor. Ama hâlâ ne için çıktığını ve neden artık çıkmadığını hiç bilmiyorum
Bu klasik yazıyı bir kez daha tavsiye etmek isterim: The Line of Death https://textslashplain.com/2017/01/14/the-line-of-death/
Passkey popup'ları JavaScript popup'larından hiç ayırt edilemediği için bu, güvenlik açısından özellikle ciddi bir hata
Böyle durumlarda yerleşik parmak izi okuyucuya gerçekten minnettar kalıyorum. Normalde dizüstü ekranını kapatıp sadece harici monitörle kullanıyorum ama sistem kimlik doğrulaması gerektiğinde özellikle açıp parmak izimle doğruluyorum
Ters köşe: Aslında baştan beri öyle bir iletişim kutusu yoktu! Zaten kandırılmış durumdasınız
Şu an en popüler yorumun altına ekleyerek duyurmak istediğim bir bilgi var — bu yazıda önemli bir güncelleme var: https://news.ycombinator.com/item?id=43969087
Sahte bir popup'a tıklandığında tehdit modelinin ne olduğunu merak ediyorum. Gerçekten sistem değilse, bu sonuçta anlamsız bir manipülasyon değil mi?
iCloud'a giriş yaparken bilgisayarın yerel parolasını isteyen bir popup çıkıyor ve o parolayı girerseniz parola iCloud sunucularına yükleniyor
Kısa süre önce, mac uygulamalarını sistem
Applicationsklasörü yerine home dizinimdekiApplications(~/Applications) klasörüne yüklemem gerektiğini öğrendim; tabii bunun anlamlı olması için bilgisayarın tek kullanıcı tarafından kullanılıyor olması gerekiyor. Kendimi yönetici olmayan (non-admin) kullanıcıya düşürüp uygulamaları home dizinindeki Applications klasörüne kurarsanız, güncellemelerde izin isteme derdi ortadan kalkıyor. Uygulamaların çoğu yönetici olmasanız da kendini güncelliyor. İstisna olarak yalnızca Tailscale gibi OS entegrasyonu gereken uygulamalar ek yetki istiyor. Bu arada bunu Pareto Security adlı bir uygulamanın tavsiyesiyle öğrendimNe yazık ki uygulama geliştiricilerinin neredeyse hiçbiri bunu bilmiyor ve birçok uygulama özellikle
/Applicationsyoluna kurulmayı şart koşuyor; başka yerde çalışmıyorlar bileUygulamaları
~/Applicationsiçine kurarsanız root olmadan otomatik güncelleme mümkün olur ama bunun karşılığında şüpheli kodlar da root yetkisi olmadan kolayca üzerine yazabilirmacOS 15.4.1 kullanıyorum ve
~/Applicationsklasörünün kendisi yokİlginç geldi! Günlük kullanımda admin hesaba gerçekten ihtiyacım olduğu için bu yöntemi kullanmam zor ama uyan kişiler için gerçekten işe yarar bir yöntem
Bu yazının içeriğinde önemli bir düzeltme gerekiyor. Daha önce CVE'nin macOS Sequoia 15.5'te yamandığı yazılmıştı ama gerçekte aynı gün yayımlanan macOS Ventura 13.7.6 ve macOS Sonoma 14.7.6'ya bu yama uygulanmamış. Apple'ın doğal olarak tüm sürümlere yama koyduğunu varsayıp öyle yazmıştım; sonra güvenlik sürüm notlarında adımın diğer iki sürümde geçmediğini görünce Apple'a doğrudan sordum. Henüz yanıt alamadım. Doğrudan test etmek için sanal makine açıp macOS Sonoma 14.7.6'ya yamayı uyguladım ve PoC'umu çalıştırdım; zafiyet hâlâ çalışıyor. Muhtemelen Ventura 13.7.6 için de durum aynıdır. Apple'ın neden yamayı koymadığını anlamıyorum. Ek bilgi gelirse yazıyı tekrar güncelleyeceğim
macOS'in TCC sistemi sağlam bir gizlilik mekanizması olarak yüksek itibara sahip ama tek bir veritabanı girdisiyle kolayca aşılabildiğini düşününce insanın tadı kaçıyor. Kullanıcı onayı popup'ının, gerçek veritabanı manipülasyonu karşısında pek bir anlamı yok; özellikle SIP kapalı geliştirme ortamlarında daha da az. Bu sonuçta bir güven meselesi. UX düzeyindeki rızanın gerçekten anlamlı bir güvenlik sınırı olup olmadığı sorgulanmalı. Artık giderek daha fazla OS düzeyindeki izin popup'larına dayanıyoruz; ama o sınır gerçekte bir yanılsamadan ibaretse (ya da sadece sahne düzeniyse), izin güvenini nasıl "göstereceğimizi" değil, gerçekte nasıl koruyacağımızı yeniden düşünmemiz gerekiyor
Eskiden "I'm a Mac and I'm a PC" reklamlarında Vista'nın bu yönleriyle dalga geçildiğini hatırlıyorum. Ama şimdi Mac'im Vista'dan bile daha kötü. Gerçekten sinir bozucu
Güvenlik ile genişletilebilirlik arasındaki ödünleşim kaçınılmaz bir kader gibi görünüyor. Yine de taban çizgisinin eskisine göre kaydığını da kabul etmek lazım. En azından macOS, eski Windows sürümlerindeki gibi kötü amaçlı süreçlerle dolup taşmıyor. Ya da belki ben sadece şanslıyım ve dikkatliyimdir
Sadece meraktan soruyorum; özellikle hangi yönünün bu kadar sinir bozucu olduğunu anlatabilir misiniz?
TCC sistemi en başından beri baştan savma bir yapıydı. Meşru geliştiricileri gereksiz yere uğraştırıyor, kullanıcıları izin popup'larıyla bunaltıyor ve kötü amaçlı uygulamalar da araştırmacıların tekrar tekrar gösterdiği gibi çeşitli yollarla bu "güvenliği (gösteriyi)" aşıyor. Güvenlik araştırmacısı değilim ama bir Mac geliştiricisi olarak ben de birkaç bypass yolu buldum. Apple mühendislerinin kullandıkları teknolojiyi gerçekten anlayıp anlamadıklarından bile şüpheliyim. Geleneksel Mac geliştiricilerinden kaç kişi kaldı merak ediyorum
Şirket Mac'i kullanıyorum ve düzenli olarak "Slack yeni bir yardımcı araç yüklemeye çalışıyor" bildirimi çıkıyor. Bunun ne olduğu ve neden çıktığı hakkında hiçbir fikrim yok. BT ekibine sordum, onlar da nasıl kontrol edileceğini bilmiyordu. Parolayı sürekli istemesi yüzünden bunun kötüye kullanılabileceğini sık sık düşünüyorum; her seferinde iptal etsem de tekrar geliyor
Bu iletişim kutusu System Management framework'ünden geliyor. Slack'in nereye kurulduğu ya da hangi kullanıcı tarafından kurulduğu fark etmeksizin kendini güncelleyebilmesi için yüksek yetkili bir yardımcı araç kurma süreci bu
Böyle popup'lar çıktığında, izin vermek ya da reddetmek için hangi bilgiye bakmam gerektiğini bilmenin hiçbir yolu olmadığı için hep iptale basıyorum
Slack'i web uygulaması olarak kullanıyorum (ama tarayıcı içinde değil, ayrı bir pencere olarak) https://support.apple.com/en-us/104996 Discord da aynı şekilde kullanılabiliyor. Bana Electron uygulamalarından çok daha akıcı geliyor. Çoğu Electron uygulaması için bu yöntem daha iyi
Ben hiç "yardımcı araç" popup'ı görmedim ama Slack gibi basit bir mesajlaşma uygulamasının neden böyle yetkilere ihtiyaç duyduğunu anlamıyorum. Slack destek ekibine sormak iyi olabilir (ve umarım bu kez gerçekten düzgün bir yanıt alırsınız)
Parola gerektiren uygulamalarda (örneğin Linux'ta yalnızca root olarak çalıştırılan binary'ler) olduğu gibi, burada da kötüye kullanım potansiyeli kesinlikle var. Sonuçta mesele geliştiriciye ve uygulamanın gerçekten o uygulama olduğuna güvenip güvenemeyeceğiniz. Apple dış uygulamalara root yetkisi vermeyi tamamen yasakladığı gün, Mac'in tam anlamıyla kapalı bir ekosisteme (
walled garden) dönüştüğü gün olur ve burada (HN) şikâyet yorumları yağar. Sonuç olarak, Slack gibi ihtiyacı açık olmayan uygulamalara root vermemek yönünde sağlıklı bir kuşkuculuk önemliGiriş odağını zorla alıyor; mesaj yazarken girdiğiniz metin bir anda parola alanına gitmeye başlıyor. Son derece sinir bozucu bir deneyim
Popup'lar zaman farkıyla birikiyor. Hafta sonundan sonra bilgisayarı açınca tekrar tekrar çıkıyor ve sonunda Slack'i tamamen kapatıyorum. Bir yıldır böyle. Bu izni Slack'ten nasıl geri alacağımı bilmiyorum; biraz kötü niyetli hissettiriyor
Bu tür "güvenlik" engelleme araçları gerçekten aptalca. İnsanları daha akıllı değil daha aptal olmaya eğitiyor. Bugün gerçek olan şey yarın olmayabilir. Bankamdan "kimlik koruma" bahanesiyle sürekli kişisel bilgilerimi isteyen telefonlar alıyorum ve bu tür mekanizmalar insanları yabancılara kişisel bilgi vermeye alıştırıyor
macOS geliştiricisi değilim ama herhangi bir (kötü amaçlı) uygulamanın sistem popup penceresi stilini taklit edip kullanıcı parolasını çalmasının mümkün olup olmadığını merak etmiştim
VSCode da şirketin verdiği Mac'te aynı popup'ı çıkarıyor. Yıllardır sadece görmezden geliyorum
Birden fazla OS kullanıcı hesabı kullanıldığında bu popup'lar tüm Electron tabanlı uygulamalarda çıkıyor
nordVPN'de de aynı durum var
Apple'ın yama çıkarması tam 1 yıl sürdü. Bu oldukça uzun hissettiriyor. <i>2024-05-04 çeşitli güncelleme mesajları bırakıldı, PoC test edilmeye devam ediyor</i> <i>2025-05-12 yama yayımlandı</i>
Adobe Creative Cloud, işletim sistemi ayarlarında arka planda çalıştırma açıkça kapatılsa bile arka planda birden fazla süreç çalıştırmaya devam ediyor
Bu kişinin araştırmalarını gerçekten çok seviyorum; sunumları da çok iyi geliyor