macOS’te Zero-Click Calendar Daveti Zafiyet Zinciri

 (medium.com/@mikko-kenttala)
1 puan yazan GN⁺ 2024-09-14 | 1 yorum | WhatsApp'ta paylaş
  • macOS Calendar’ın davet eklerini işleme kusuru nedeniyle saldırganlar Calendar sandbox’ı içinde rastgele dosya yazma ve silme gerçekleştirebiliyordu; bu sorun uzaktan kod çalıştırma ve Photos verilerine erişim zincirine dönüştü
    1. aşama CVE-2022-46723, ATTACH bölümündeki FILENAME=../../../PoC.txt gibi yol geçişi girdilerini düzgün temizlemediği için ek dosyaların amaçlanan konumun dışına kaydedilmesine izin veriyordu
  • Uzaktan kod çalıştırma zinciri, Monterey’den Ventura’ya yükseltme sürecindeki Calendar Open File davranışını kullanarak birden fazla dosya enjekte ediyor; DMG, SMB mount ve özel URL şemasını birleştiriyordu
  • Photos aşamasında, defaults import ile kötü amaçlı ayarlar uygulanarak System Photo Library /var/tmp/mypictures/Syndication.photoslibrary olarak değiştiriliyor ve iCloud’daki özgün fotoğrafların TCC tarafından korunmayan bir dizine senkronize edilmesi sağlanıyordu
  • Apple, ilgili zafiyetlerin tümünü Ekim 2022 ile Eylül 2023 arasında düzeltti; Photos zafiyeti CVE-2023-40434, Gatekeeper atlatması ise CVE-2023-40433 olarak ele alındı

Calendar ek dosyalarında yol geçişi

  • Kötü amaçlı bir Calendar daveti dosya eki içerebiliyordu ve ek dosya adı doğrulamasındaki eksiklik nedeniyle dizin geçişi mümkündü
  • Saldırgan, ATTACH bölümünde FILENAME=../../../PoC.txt gibi rastgele bir yol belirleyebiliyordu
    • Normal kayıt konumu ~/Library/Calendar/[CalendarID]/Attachments/[eventid]/
    • Zafiyetli davranışta dosya ~/Library/Calendar/PoC.txt konumuna kaydediliyordu
  • Aynı ada sahip bir dosya zaten varsa yeni dosya PoC.txt-2 olarak kaydediliyordu; ancak daha sonra saldırganın gönderdiği etkinlik veya ek silindiğinde özgün addaki PoC.txt kaldırılabiliyordu
  • Bu davranış, dosya sistemindeki Calendar sandbox’ı içinde mevcut dosyaları silmek için de kullanılabiliyordu
  • Zafiyetin en azından macOS Monterey 12.5’in güncel sürümünde bulunduğu, macOS 13.0 beta4’te ise artık zafiyetli olmadığı doğrulandı

Uzaktan kod çalıştırmaya genişletilen zincir

  • macOS Ventura’nın çıkışından hemen önce keşfedilen zafiyet, sürüm yükseltme süreci ve Calendar’ın Open File özelliği kullanılarak uzaktan kod çalıştırmaya genişletildi
  • Saldırgan, Calendar’daki rastgele dosya yazma zafiyetiyle birden fazla dosya enjekte ediyor ve Monterey’den Ventura’ya yükseltme sırasında RCE zinciri çalışacak şekilde yapılandırıyordu

  • Enjekte edilen dosya yapısı

    • 000Hacked-$RANDOM.calendar
      • “Siri Suggested” Calendar gibi görünen Calendar verileri içeriyor
      • Yinelenen etkinlik ve bildirim işlevlerini içeriyor; diğer enjekte edilen dosyaları açacak şekilde çalışıyor
    • CalendarTruthFileMigrationInProgress
      • Mevcut Calendar’ın eski biçimden yeni veritabanına yükseltilip birleştirilmesini sağlayan dosya
    • CalPoCInit.dmg
      • İlk Calendar bildiriminin ~/Library/Calendars/CalPoCInit.dmg dosyasını açmasını sağlıyor
      • DMG içindeki .DS_Store Bookmark’ı, harici bir Samba sunucusundaki arka plan görseline referans içeriyor
      • CalPoCInit.dmg dosyasının kendisi karantina durumunda olsa bile mount işlemi quarantine flag olmadan gerçekleşiyor
    • stage1.url
      • İkinci Calendar bildiriminin ~/Library/Calendars/stage1.url dosyasını açmasını sağlıyor
      • Bu dosya, önceki aşamada mount edilen Samba volume içindeki uygulamayı gösteren file:///Volumes/CalPoCPayload/MyMidiTest.app URL’sini içeriyor
      • Finder /Volumes/CalPoCPayload/ konumunu açarken indeksleme otomatik olarak gerçekleşiyor ve MyMidiTest.app indeksleniyor
      • Uygulama bundle’ındaki Info.plist, mymiditest özel URL şeması handler’ını kaydediyor
    • stage2.url
      • Üçüncü Calendar bildiriminin ~/Library/Calendar/stage2.url dosyasını açmasını sağlıyor
      • Bu dosya mymiditest:// referansıyla kötü amaçlı uygulamayı kullanıcı etkileşimi olmadan çalıştırıyor

Gatekeeper atlatması ve uygulama çalıştırma

  • mymiditest:// çalıştırmasının mümkün olmasının nedeni, uygulamanın exploit ile oluşturulan Samba mount’u içinde bulunması ve bu konumda quarantine flag olmamasıydı
  • mymiditest uygulaması 3. aşama için gerekli dosyaları /var/tmp/ içine yazıyor ve open /var/tmp/PhotosPoC.sh ile script’i Terminal’de çalıştırıyor
  • Tüm zincir, Calendar sandbox’ından çıkmak için birden fazla dosya enjekte edecek, SMB hilesiyle Gatekeeper hafifletmelerini atlatacak ve ardından rastgele kod çalıştıracak şekilde kurgulandı

Photos ayarlarını değiştirerek iCloud fotoğraflarına erişim

  • Uzaktan kod çalıştırmadan sonraki aşama, kullanıcının hassas fotoğraf verilerine, özellikle iCloud Photos’a erişmek için Photos ayarlarını değiştirmeye odaklandı
  • Normalde Photos gibi hassas dosyalara erişimi TCC’nin kısıtlaması gerekir; ancak Photos ayarları değiştirildiğinde System Photo Library, TCC tarafından korunmayan bir yolu gösterebiliyordu
  • Saldırgan, farklı bir System Photo Library kullanan Photos ayar dosyası oluşturup bunu defaults import ile içe aktarabiliyordu
  • PoC zincirinde 2. aşama, System Photo Library olarak /var/tmp/mypictures/Syndication.photoslibrary kullanan ayarı otomatik olarak hazırlıyor
    • İlgili kötü amaçlı ayar dosyaları /var/tmp/mypictures/*.plist altında oluşturuluyor
    • Çalışmakta olan Photos ile ilgili uygulamalar kapatılıyor
    • Özgün ayarlar /var/tmp/mypictures/*-orig.plist içine yedekleniyor
    • Kötü amaçlı ayarlar /var/tmp/mypictures/ konumundan içe aktarılıyor
    • Yeni fotoğraf arşivi open /var/tmp/mypictures/Syndication.photoslibrary ile Photos’ta açılıyor
  • Syndication.photoslibrary boş bir şablon arşivdir; Photos yeni System Photo Library ile çalıştırıldığında iCloud senkronizasyonu etkinleşiyor ve özgün dosyalar korunmayan dizine indiriliyor
  • Diske senkronize edilen dosyalar /var/tmp/PoCLoot$RANDOM/ altında yeni bir dizine kopyalanıyor
  • PoC, küçük değişikliklerle verileri harici bir kaynağa kopyalayabilecek veya curl komutuyla harici bir web sunucusuna gönderebilecek durumdaydı

Düzeltme takvimi ve kalan bounty sorunu

  • Tüm zincirin macOS güvenlik bariyerlerini sırayla aşması gerekiyordu
    • Calendar’a birden fazla dosya enjekte ederek sandbox’ı atlatıyor ve sonraki aşamayı etkinleştiriyordu
    • SMB hilesiyle Gatekeeper hafifletmelerini atlatıp rastgele kod çalıştırıyordu
    • TCC korumasını atlatıp iCloud Photos gibi hassas verilere erişiyordu
  • Düzeltme öncesinde, Apple iCloud kullanıcılarına kötü amaçlı Calendar daveti gönderilip kullanıcı etkileşimi olmadan iCloud Photos çalınabiliyordu
  • Apple, ilgili zafiyetlerin tümünü Ekim 2022 ile Eylül 2023 arasında düzeltti

  • Zaman çizelgesi

    • 2022-08-08: Calendar sandbox’ı içinde rastgele dosya yazma ve silme bildirildi
    • 2022-10-24: macOS Monterey 12.6.1 ve Ventura 13’te düzeltildi
      • Bu öğe için CVE yoktu ve Ventura beta3 zafiyetliydi
    • 2022-11-14: Calendar zafiyetini rastgele kod çalıştırma ve Gatekeeper atlatmasına genişleten PoC iletildi
    • 2022-12-04: iCloud Photos erişim PoC’si iletildi
    • 2023-02-20: Calendar zafiyetine CVE-2022-46723 kredisi ve CVE eklendi
    • 2023-03-27: Gatekeeper atlatması macOS Ventura 13.3’te düzeltildi
      • Bu noktada CVE veya kredi yoktu
    • 2023-09-26: Photos zafiyeti CVE-2023-40434 düzeltildi ve kredi verildi
    • 2023-10-09: Gatekeeper atlatması ve Photos zafiyetiyle ilgili bug bounty duyuruldu
    • 2023-12-21: Gatekeeper atlatmasına CVE-2023-40433 kredisi verildi
    • 2024-09-12: Orijinal Calendar rastgele dosya yazma ve silme zafiyeti CVE-2022-46723 ile ilgili bounty hâlâ yok
    • 2024-10-20 güncellemesi: Apple, CVE-2022-46723 Calendar rastgele dosya yazma ve silme zafiyetinin yalnızca macOS Monterey’i etkilediğini ve Ventura’nın zaten beta aşamasında bu sorundan etkilenmediğini gerekçe göstererek bunun bounty kapsamına girmediğine karar verdi

İlgili okumalar

1 yorum

 
GN⁺ 2024-09-14
Hacker News yorumları

  • iCloud Photo Library kullanmadığım için şanslıyım, ama fotoğraf arşivinin konumunu değiştirince yeni konumun hiçbir koruma almaması garip
    /var/tmp/mypictures/Syndication.photoslibrary dizinini sistem fotoğraf arşivi olarak ayarlayıp Photos’ı açtığımda, Photos uygulamasının bu dizini koruması gerekeceği için exploit’in başarısız olmasını beklerdim
    Sonoma 14.6.1’de hızlıca denedim: Option tuşuna basılı tutup Photos’ı açarak ~/Pictures içinde yeni bir fotoğraf arşivi oluşturunca, tam disk erişimi ya da fotoğraf izni olmayan uygulamanın o klasöre erişimi reddedildi
    Ama yeni fotoğraf arşivini /tmp içinde oluşturunca aynı uygulama erişebildi; bu davranış kafa karıştırıcı ve tutarsız
    Apple, fotoğraf arşivini dosya sisteminde herhangi bir yere taşıma özelliğini gerçekten destekleyecekse korumayı da düzgün uygulamalı

    • Bir ölçüde anlaşılır. /tmp tarihsel olarak dizin hiyerarşisinde herkesin okuyup yazabildiği bir yerdi ve özel verileri saklamak için iyi bir tercih değil
    • TCC eskiden beri bu şekilde biraz tuhaf ve çok delikli olma eğilimindeydi
    • Linux’ta artık her şeyi yalıtmak macOS’a göre çok daha kolay
      AppArmor veya Firejail olmadan bile çoğu hizmet varsayılan olarak kendine ait geçici dizin alıyor

  • Bu başlıkta hata ödülü ödemesiyle ilgili çok konuşuluyor; ama sürekli bir ödül programı işleten dev teknoloji şirketi ödül ödemiyorsa, çoğu zaman bunun geçerli bir nedeni olma ihtimali yüksektir
    Bu tür programların teşvikleri, meşru bildirimlere ödül ödenmesi yönünde neredeyse tamamen hizalanmıştır
    Teşviklerin oldukça iyi hizalandığı nadir durumlardan biridir: Şirket belirli türde araştırmaları teşvik etmek için ödül programı oluşturur; hak edilmiş ödülü ödememek de bu hedefe ters düşer
    Tedarikçi tarafındaki sorumlu kişi kendi parasını harcamıyor; tutar da şirket açısından anlamlı bir büyüklükte değil
    Genellikle program operasyon ekibi üyeleri, ödülü daha az vermekten çok daha fazla ödeme yapmaya motive edilir

    • Hayır. Çünkü Apple’ın hata ödüllerini inceleyen ve ödeyen product security ekibi kötü yönetiliyor ve verimsiz
      Yakın zamanda SWE program ofisinden SEAR’a (security engineering & arch) taşındı; yöneticisi de kısa süre önce kovulup AirBNB’ye gitti
      Ekip üyelerinin çoğu yeni mezun seviyesinde ICT2·ICT3; şirketin başka yerlerindeki kodlama mülakatlarını bile geçemeyecek kişiler ve ağırlıklı olarak hata sınıflandırıcısı gibi çalışıyorlar
      Bilgisayar başında çalışmaktan çok konferanslara gidip hacker’larla takılmaya zaman harcıyorlar
      “İnceleme sürüyor” portalındaki grafik sürekli yukarı gidiyor; e-postalar birikiyor ve yetişmeye çalıştıklarına dair bir girişim bile yok
      Ödül alması gerekirken alamayan kişilerin ilerleme görmek için SEAR’ın başındaki Ivan’ı Twitter’da alenen baskı altına alması gerekiyor
    • Doğru olabilir. Apple’ın kötü hata ödül programı kasıtlı kötü niyetten değil, beceriksizlikten kaynaklanıyor olabilir
      Ama bunun güvenlik araştırmacıları veya kamuoyu için önemi var mı? Hayır. Neden bozulmuş olursa olsun Apple’ın ödül programını düzeltmesi gerekiyor
      Sonuçta bu blog yazısı da zaten büyük bir yığının üstüne eklenen bir örnek daha[1][2][3][4][5]
      1: https://arstechnica.com/information-technology/2021/09/three...
      2: https://mjtsai.com/blog/2021/07/13/more-trouble-with-the-app...
      3: https://medium.com/macoclock/apple-security-bounty-a-persona...
      4: https://theevilbit.github.io/posts/experiences_with_asb/
      5: https://shail-official.medium.com/accessing-apples-internal-...
    • Yazarın durumu çarpıttığını kastetmiyorsak, birinin hatanın düzeltilmesinden çok önce bunu bildirdiğine dair açık bir kayıt varken hangi “çok iyi neden” olabilir bilmiyorum
      En iyi ihtimalle tipik yavaş bürokrasi gibi görünüyor; bu da pek iyi bir neden değil
      Şirket gerçekten böyle şeyleri teşvik ediyorsa onayın 1 yıldan uzun sürmesi için bir sebep yok
      Mantık doğru olabilir, ama böyle bir durumda “şirket cimri ya da neredeyse her başka durumda olduğu gibi aşırı bürokratik” açıklamasının, “görünüşe göre şartları karşılayan bir ödülü ödememek için geçerli bir nedeni var” açıklamasından daha az olası olduğunu söylemek zor
      Yazar olayı doğru anlatıyorsa, başka her yerde işleyen teşviklerin bu alana da sızmış olması çok daha olası görünüyor
    • Apple’a hiç güvenlik/gizlilik sorunu bildirdiniz mi? Ben bildirdim. Şu anda bile Apple’da açık en az bir konum var
      Bunlardan biri yan etkisiz tek satır kodla düzeltilebilir, ama 2 yıldır açık
      Apple güvenlik ekibi ya ilgisiz ya da beceriksiz; hangisi olursa olsun iyi değil
      Bilgisayar dünyasında yaşadığım en öfke verici ve bunaltıcı deneyimlerden biriydi
      Sorunu kamuya açık şekilde paylaşmamamı açıkça istiyorlar, ama süresiz biçimde sürüncemede bırakıyorlar
      Açıkçası sınırıma yaklaşıyorum
      Ödülü umursamıyorum bile; sadece hatanın düzeltilmesini istiyorum
      Konuyu ciddiye aldıklarına inanabilsem olabildiğince süre tanırım, ama buna inanmak zor
    • Dev teknoloji şirketlerinin ödemeyi tamamen reddettiği belgelenmiş birçok vaka oldu
      Sonradan katılım kurallarını değiştirmek, güvenlik araştırmacısını sürmekte olan ödül programından sessizce engellemek, iyi niyetli açıklamayı soruşturma makamlarına iletmek ya da yöneticilerin aşırı küçük hesapçı davranması gibi
      “Şirket açısından tutar anlamlı değil” olması, bu berbat süreci daha da anlaşılmaz kılıyor

  • Karantina bayrağıyla oynamanın bir başka yolu daha. Diğeri şu bağlantı: https://imlzq.com/apple/macos/2024/08/24/Unveiling-Mac-Secur...
    Çok fazla farklı sistemin bu karantina bayrağını değiştirebildiği anlaşılıyor

  • “Saldırgan, kurbana dosya eki içeren kötü amaçlı bir takvim daveti gönderebilir… Düzeltmeden önce, herhangi bir Apple iCloud kullanıcısına kötü amaçlı bir takvim daveti gönderip kullanıcı etkileşimi olmadan iCloud Photos’u çalmak mümkündü.”
    Bunun kapsamı ne kadar geniş? macOS’te herhangi bir yerden, herhangi biri iCloud kullanan herhangi birine keyfî bir davet gönderebiliyor mu demek? Bunu kim istemez ki?

    • Alaycı olmaya çalışmıyorum ama davetler bunun dışında nasıl çalışmalı?
    • Anlamıyorum. Bir takvim daveti almak, başka bir e-posta almaktan nasıl farklı? macOS tasarım gereği takvim davetleri için bir şeyleri otomatik mi işliyor?
    • Google Calendar da aynı değil mi?
    • Bu yalnızca iCloud’a özgü gibi görünmüyor. Genel olarak davetler e-postadan otomatik olarak yakalanır
      Takvim davetleri uzun zamandır spam kaynağı olduğuna göre, güvenlik açığı olması da şaşırtıcı değil

  • “Saldırganın belirttiği dosya zaten varsa, belirtilen dosya PoC.txt-2 adıyla kaydedilir. Ancak saldırganın gönderdiği etkinlik/ek dosyası daha sonra silinirse özgün ada sahip dosya (PoC.txt) kaldırılır. Bu güvenlik açığı, dosya sistemi ‘sandbox’ı içindeki mevcut dosyaları silmek için kullanılabilir.”
    Bu kötü mühendislik

  • Buradaki ödül durumundan pek hoşlanmadım. Güvenlik araştırmacıları açısından Apple’da ya da diğer FAANG düzeyi şirketlerde bu kadar uzun beklemek yaygın mı?

    • Hem de çok
    1. adım tek başına bile akıl almaz bir güvenlik açığı. Apple bunu nasıl hesaba katmamış olabilir?
      “Saldırgan, ATTACH bölümünde FILENAME=../../../PoC.txt gibi dosya için keyfî bir yol ayarlayarak dizin geçişi saldırısını başarıyla gerçekleştirebilir.”
    • Bu, her şirkette olabilecek daha büyük bir sorunu gösteriyor. Apple’da biri bunu güvenli biçimde işleyen bir kütüphane fonksiyonu mutlaka yazmıştır; peki o fonksiyonun kullanılmasını nasıl zorunlu kılabilirsiniz?
      Özellikle kod inceleyen kişi de o kütüphaneden haberdar değilse, birinin baştan güvenli olmayan şekilde yeniden uygulamasını engellemek zor
      Bu tür sorunlar için modern bir çözüm var mı?

  • Bellek güvenliğiyle ilgili olmayan büyük ölçekli bir güvenlik açığı ortaya çıktığında garip bir şekilde heyecanlanıyorum
    Biraz küçük hesaplı olduğumu biliyorum ama Rust’a harcanan tüm zaman ve enerjinin sonunda tek bir yol geçişi hatasıyla boşa gitmesi fikri hoşuma gidiyor

  • Lockdown Mode bunu engeller mi?

    • Tamamen tahmin ama umarım öyledir
      Geçmişteki sıfır tıklamalı görsel eki exploit’leri düşününce, Lockdown Mode’un bunları engellemek için tasarlandığı ve tüm dosyaların bu şekilde ele alınacağı izlenimi oluşuyor

  • Vay. Epey eski tarz bir exploit
    Dosya adının içindeki yol gibi şeyleri yaklaşık 10 yıl önce okuduğumu hatırlıyorum