Operation Triangulation: Araştırmacıların iPhone'larına saldırırken elde edilenler

 (securelist.com)
1 puan yazan GN⁺ 2023-12-28 | 1 yorum | WhatsApp'ta paylaş
  • Kaspersky araştırmacıları, 37C3'te Operation Triangulation adlı iPhone 0-click iMessage saldırı zincirini açıkladı ve bunu şimdiye kadar gördükleri en sofistike zincir olarak değerlendirdi
  • Saldırı, iOS 16.2'ye kadar çalışacak şekilde tasarlanmıştı ve 4 sıfır gün açığını birleştirerek uzaktan kod çalıştırma, yetki yükseltme, PPL atlatma ve Safari aşamasının çalıştırılmasına uzanıyordu
  • Temel gizem, CVE-2023-38606 ile hafifletilen bölümde yatıyor; saldırganlar, Apple A12–A16 Bionic SoC'lerde bilinmeyen MMIO register'larını kullanarak donanım tabanlı kernel bellek korumasını atlattı
  • Analiz, bu register'ların GPU yardımcı işlemcisi ile ilişkili göründüğünü ve bazılarının DeviceTree ya da firmware'de referanslanmaması nedeniyle saldırganların bunları nasıl kullanacağını bildiğinin doğrulanamadığını gösterdi
  • 9 Ocak 2024 güncellemesinde, “özel hash” gibi görünen değerlerin aslında Hamming code tabanlı ECC olduğu doğrulandı ve bu işlevin belleğe değil doğrudan cache'e erişen bir debug özelliği olma ihtimali güçlendi

Açıklanan saldırı zinciri

  • 27 Aralık 2023'teki 37C3 sunumunda Operation Triangulation üzerine uzun süreli analiz sonuçları paylaşıldı
  • Bu sunumda saldırıda kullanılan exploit'ler ve zafiyet ayrıntıları ilk kez açıklandı
  • Araştırmacılar, Adobe, Apple, Google ve Microsoft ürünlerinde gerçek dünyada istismar edilen 30'dan fazla sıfır gün açığını tespit edip raporlamış olsa da, bu saldırı zinciri bunlar arasında bile en sofistike olanlardan biri olarak değerlendirildi

iMessage 0-click'ten spyware yüklemeye

  • Saldırganlar kötü amaçlı bir iMessage eki gönderiyor ve uygulama bunu kullanıcıya göstermeden işliyordu
  • Ek, Apple'a özgü belgelenmemiş ADJUST TrueType font komutundaki uzaktan kod çalıştırma açığı CVE-2023-41990'ı istismar ediyordu
    • Bu komut 1990'ların başından beri vardı ve yama ile kaldırıldı
  • Ardından return/jump oriented programming ile NSExpression/NSPredicate sorgu diliyle yazılmış çok aşamalı süreçler izliyordu
    • JavaScriptCore ortamı yamalanarak JavaScript ile yazılmış bir yetki yükseltme exploit'inin çalıştırılması sağlanıyordu
  • JavaScript exploit'i boyutu küçültülmüş ve tamamen okunamaz hale gelecek şekilde obfuscate edilmişti, ancak yaklaşık 11.000 satır büyüklüğündeydi
    • Bunun büyük bölümü JavaScriptCore ile kernel belleğini ayrıştırma ve manipüle etme için kullanılıyordu
  • JavaScriptCore debug özelliği DollarVM($vm) kötüye kullanılarak script içinden JavaScriptCore belleği manipüle ediliyor ve native API fonksiyonları çalıştırılıyordu
  • Hem eski hem yeni iPhone'ları destekleyecek şekilde tasarlanmıştı ve en yeni modelleri istismar etmek için PAC atlatması da içeriyordu

Kernel bellek erişimi ve PPL atlatma

  • Exploit, XNU'nun bellek eşleme syscall'ları mach_make_memory_entry ve vm_map içindeki integer overflow zafiyeti CVE-2023-32434'ü kullanıyordu
    • Kullanıcı seviyesinden cihazın tüm fiziksel belleğine okuma/yazma erişimi elde ediliyordu
  • Ardından donanım MMIO register'larıyla Page Protection Layer(PPL) atlatılıyordu
  • Tüm zafiyetler istismar edildikten sonra JavaScript exploit'i cihaz üzerinde keyfi işlemler gerçekleştirebiliyordu
    • Saldırganlar IMAgent sürecini başlatıp payload enjekte ederek exploit izlerini siliyordu
    • Safari sürecini görünmez modda başlatıp bir sonraki aşama web sayfasına yönlendiriyordu
  • Web sayfası kurbanı doğruladıktan sonra koşullar sağlanıyorsa Safari exploit'ini teslim ediyordu
  • Safari exploit'i, shellcode çalıştırmak için CVE-2023-32435'i kullanıyordu
  • Shellcode, Mach object dosyası biçimindeki başka bir kernel exploit'ini çalıştırıyordu
    • Bu exploit de CVE-2023-32434 ve CVE-2023-38606'ı kullanıyordu
    • JavaScript kernel exploit'inden büyük ölçüde farklı olsa da, aynı zafiyetlerin istismarıyla ilgili bazı kodları paylaşıyordu
  • Sonunda root yetkisi elde edilip diğer aşamalar çalıştırılarak spyware yükleniyordu

CVE-2023-38606'ın donanımsal gizemi

  • Yeni iPhone modelleri, hassas kernel bellek alanlarını korumaya yönelik donanım tabanlı koruma özelliklerine sahip
  • Bu koruma, saldırganlar kernel belleğini okuyup yazabilse bile cihaz üzerinde tam kontrol elde etmelerini engellemek için tasarlandı
  • Operation Triangulation saldırganları, Apple tasarımı SoC'lerdeki başka bir donanım özelliğini kullanarak bu korumayı atlattı
  • Tespit edilen çalışma biçimi şöyleydi
    • Veri, hedef adres ve veri hash'i çip üzerindeki bilinmeyen donanım register'larına yazılıyordu
    • Bu register'lar firmware tarafından kullanılmıyor gibi görünüyordu
    • Sonuç olarak donanım tabanlı bellek koruması atlatılarak belirli fiziksel adreslere veri yazılabiliyordu
  • Bu işlev Apple mühendisleri ya da fabrika testleri için bir debug özelliği olabilir veya yanlışlıkla dahil edilmiş olabilir
  • Firmware'de kullanılmayan bir özellik olduğundan, saldırganların bunu nasıl kullanacağını bildiği doğrulanamadı

MMIO ve DeviceTree analizi

  • SoC üzerindeki çevre birimleri, CPU'nun aygıtları kontrol edebilmesi için özel donanım register'ları sunabilir
  • Bu register'lar CPU'nun erişebildiği belleğe eşlenir ve buna memory-mapped I/O(MMIO) denir
  • Apple ürünlerindeki çevre birimi MMIO adres aralıkları DeviceTree biçiminde saklanır
    • DeviceTree dosyaları firmware'den çıkarılabilir
    • İçerik dt yardımcı aracıyla görüntülenebilir
  • Saldırganların PPL atlatmak için kullandığı MMIO'ların çoğu, DeviceTree'de tanımlı herhangi bir MMIO aralığına dahil değildi
  • Exploit, Apple A12–A16 Bionic SoC'leri hedefliyor ve şu bilinmeyen MMIO bloklarını kullanıyordu
    • 0x206040000
    • 0x206140000
    • 0x206150000
  • Çeşitli cihaz ve firmware'lerin DeviceTree'lerinde, açık kaynak kodlarında, kernel image'larında, kernel extension'larında, iBoot'ta ve yardımcı işlemci firmware'lerinde bu adreslere yönelik referans bulunmadı

GPU yardımcı işlemcisiyle ilişki

  • Çevredeki bilinen MMIO'lar incelendiğinde, bilinmeyen adreslerin gfx-asc, yani GPU yardımcı işlemcisine yakın konumda olduğu görüldü
  • gfx-asc için iki MMIO aralığı bulunuyor
    • 0x206400000–0x20646C000
    • 0x206050000–0x206050008
  • Exploit'in gerçekten kullandığı bilinmeyen adresler şunlardı
    • 0x206040000
    • 0x206140008
    • 0x206140108
    • 0x206150020
    • 0x206150040
    • 0x206150048
  • Bunların çoğu iki gfx-asc alanının arasında, kalan biri ise ilk gfx-asc alanının başlangıcına yakındı
  • Bu register'ların GPU yardımcı işlemcisine ait olma ihtimalinin yüksek olduğu değerlendirildi
  • Exploit başlatma sürecinde, SoC'ye göre farklı adreslerdeki GFX güç yöneticisi register'larını manipüle eden kod da görüldü
    • pmgr yardımcı aracıyla bu adreslerin güç yöneticisi MMIO aralığındaki GFX register'larına karşılık geldiği doğrulandı
  • Bilinmeyen bölgedeki register'lara erişildiğinde GPU yardımcı işlemcisi “GFX SERROR Exception” mesajıyla panic veriyordu
    • Bu sonuç da söz konusu register'ların GPU yardımcı işlemcisine ait olduğu değerlendirmesini destekliyor

CoreSight ve Apple'a özgü UTT alanı

  • 0x206040000 register'ı exploit'in yalnızca başlatma ve sonlandırma aşamalarında kullanılıyordu
    • Başlatmada ilk ayarlanan, sonlandırmada ise son işlenen unsurdu
  • Bu register'ın donanım özelliğini açıp kapatma ya da interrupt'ları kontrol etme görevi gördüğü analiz edildi
  • Exploit'in davranışı, XNU kaynak kodundaki dbgwrap.c içindeki ml_dbgwrap_halt_cpu fonksiyonuyla örtüşüyor
  • dbgwrap.c, ana CPU'nun ARM CoreSight MMIO debug register'larını yöneten kodu içeriyor
  • XNU kaynak kodu, CoreSight ile ilgili MMIO alanları olarak ED, CTI, PMU ve UTT olmak üzere dört bölgeden söz ediyor
    • Her bölge 0x10000 byte yer kaplıyor
    • Dört bölge birbirine bitişik durumda
  • Kaynak kodunda UTT alanının ARM'den gelmediği, kolaylık için eklenmiş Apple'a özgü bir özellik olduğu belirtiliyor
  • ARM_DBG_LOCK_ACCESS_KEY ilgili konuma yazıldığında 0x206000000–0x206050000 aralığının GPU yardımcı işlemcisinin CoreSight MMIO debug register bloğu olduğu doğrulanabiliyor
  • Ana CPU'nun her çekirdeğinin de kendi CoreSight MMIO debug register bloğu var, ancak GPU yardımcı işlemcisinden farklı olarak bu adresler DeviceTree içinde bulunabiliyor
  • Exploit yazarı, Apple'a özgü UTT alanını kullanarak CPU halt durumunu kaldırma yöntemini de biliyordu
    • Bu kod XNU kaynak koduna dahil değil

DMA gibi çalışan tanımlanamayan işlev

  • 0x206140008 ve 0x206140108 register'ları, exploit'in kullandığı donanım işlevinin etkinleştirilmesi/devre dışı bırakılması ve çalıştırılmasını kontrol ediyor
  • 0x206150020, yalnızca Apple A15/A16 Bionic SoC'lerde kullanılıyor
    • Başlatma aşamasında 1'e ayarlanıyor ve sonlandırmada eski değerine döndürülüyor
  • 0x206150040, bayrakları ve hedef fiziksel adresin alt yarısını saklamak için kullanılıyor
  • 0x206150048, yazılacak veri, hedef fiziksel adresin üst yarısı, veri hash'i ve başka bir değeri birlikte saklamak için kullanılıyor
    • Donanım işlevi veriyi hizalı 0x40 byte bloklar halinde yazıyor
    • 0x206150048 register'ına art arda 9 kez yazmak gerekiyor
  • Tüm prosedür doğruysa donanım DMA benzeri bir işlem yaparak veriyi istenen konuma yazıyor
  • Exploit, bu işlevi PPL atlatmak için ve çoğunlukla page table entry'leri yamamak amacıyla kullanıyordu
  • Korumalı __PPLDATA segmentindeki verileri yamamak için de kullanılabiliyordu
  • Kernel kodu yamalamak için bu işlev kullanılmadı
    • Testler sırasında bir kez __TEXT_EXEC segmentindeki kernel komutlarının üzerine yazılarak beklenen adres ve değerle “Undefined Kernel Instruction” panic'i elde edildi
    • Diğer denemelerde AMCC panic'i oluştu

Hash, ECC ve cache erişimi olasılığı

  • İlk analizlerde bu işlevin özel bir hash gerektirdiği düşünülüyordu
    • Hash, önceden tanımlı bir sbox tablosu kullanılarak hesaplanıyordu
    • Büyük bir binary koleksiyonunda bu tablo arandı ancak bulunamadı
  • Hash 20 bit gibi görünüyordu; yani 10 bitlik değerin iki kez hesaplanması şeklindeydi
  • Saldırganlar hesaplama yöntemini ve kullanım biçimini bilmiyorsa bu yapı security by obscurity yaklaşımına yakındı
  • 9 Ocak 2024 güncellemesinde Hector Martin, bu değerin basit bir özel hash değil, bir hata düzeltme kodu(ECC) olduğunu doğruladı
    • Daha doğrusu, özel bir lookup table kullanan bir Hamming code'du
  • Bu keşif, tanımlanamayan donanım işlevinin asıl amacını anlamak için ipucu sağladı
    • İlk başta doğrudan bellek erişimi sunan bir debug özelliğine eklenmiş “sahte” bir hash gibi görünüyordu
    • ECC kullanılması ve kernel kodu yamalanırken kararsız davranış gözlenmesi nedeniyle, bu işlevin doğrudan cache erişimi sağlayan bir özellik olma ihtimali güçlendi

M1 deneyleri ve iOS 16.6 hafifletmesi

  • Mac'teki M1 çipinde de bu bilinmeyen donanım işlevinin bulunduğu doğrulandı
  • m1n1 aracının trace_range özelliğiyle 0x206110000–0x206400000 aralığındaki MMIO erişimleri izlendi
    • macOS'un bu register'ları kullandığına dair bir bulgu raporlanmadı
  • iOS 16.6'da Apple, exploit'in kullandığı MMIO aralıklarını DeviceTree içindeki pmap-io-ranges listesine ekleyerek zafiyeti hafifletti
    • Eklenen aralıklar 0x206000000–0x206050000 ve 0x206110000–0x206400000 oldu
  • XNU, belirli fiziksel adres eşlemelerine izin verilip verilmeyeceğine karar vermek için pmap-io-ranges bilgisini kullanıyor
  • Normal pmap-io-ranges girdilerinde PCIe, DART, DAPF gibi anlamlı etiket adları bulunurken, bu zafiyetle ilgili alanların etiket adları diğer girdilerden farklı şekilde dikkat çekiciydi

Geriye kalan sorular ve güvenlik etkileri

  • Saldırganların bu bilinmeyen donanım işlevini nasıl kullanacaklarını öğrendiği doğrulanamadı
  • Bu işlevin asıl amacı da hâlâ belirsiz
    • Apple tarafından geliştirilmiş bir özellik mi, yoksa ARM CoreSight gibi üçüncü taraf bir bileşen mi olduğu da bilinmiyor
  • Güncellemeden sonra da gizem sürüyor
    • Saldırganlar sadece deney yaparak özel lookup table değerlerini brute force edebilir
    • Ancak güçlü bir cache debug özelliğinin varlığını, Hamming code kullanımını, ilgili MMIO register'larının konumunu ve amacını, ayrıca etkileşim sırasını da bilmeleri gerekir
  • Donanım tabanlı koruma bulunsa bile, bunu atlatabilecek donanım işlevleri mevcutsa gelişmiş saldırganlar karşısında etkisiz kalabilir
  • Donanım güvenliğinin tersine mühendisliği yazılıma kıyasla çok daha zordur, ancak “security through obscurity”ye dayanan sistemler sır açığa çıktığı anda güvenli olmaktan çıkar

İlgili okumalar

1 yorum

 
GN⁺ 2023-12-28
Hacker News yorumları

  • Sunum videosu da artık yayınlandı: https://www.youtube.com/watch?v=7VWNUUldBEE

  • Oldukça şaşırtıcı bir içerik. MMIO istismarı, saldırganların gerçekten muazzam bir araştırma kapasitesine sahip olduğu ya da Apple’ı hackleyip dahili donanım belgelerini ele geçirdiği anlamına geliyor; ikincisi daha olası görünüyor.
    Özel hash fonksiyonu S-box ortaya çıkana kadar, NSA düzeyinde büyük bir araştırma ekibiyle bunun mümkün olabileceğini düşünürdüm; ama o noktadan itibaren Apple’ın bu işlevin tehlikeli olduğunu bilerek onu kasıtlı olarak gizlediği ve her ne ise, üstüne bir tür zayıf dijital imza işleviyle de koruduğu anlaşılıyor.
    Blog yazısının da belirttiği gibi, tüm silikonu söküp tersine mühendislik yapmaktan başka bu işlevi çalıştıracak doğru “sihirli tıklatmayı” bulmanın belirgin bir yolu yok. Bu üretim düğümlerinde bu fiilen gerçekçi değil; geriye geliştiricileri hackleyip dahili belgeleri çalma ihtimali kalıyor.
    Yüksek maliyetli sıfır gün zincirini uzun uzun kullanıp görünmeyen bir Safari açtıktan sonra, web sayfasını bambaşka bir exploit zinciriyle yükleyerek cihazı yeniden hackleme biçimi de içeride ağır siloları olan dev bir organizasyon kokusu veriyor.
    Araştırmacıların Kaspersky’den Ruslar olduğu düşünülürse, bunun neredeyse kesinlikle NSA ya da belki GCHQ operasyonu olma ihtimali yüksek.
    Sunumdaki diğer ilginç noktalardan biri de kötü amaçlı yazılımın reklam takibini açabilmesi ve güvenlik araştırmacılarının sık kullandığı bulut iPhone barındırma hizmetlerini de tespit edebilmesi. iOS/macOS kötü amaçlı yazılım platformu 10 yılı aşkın süredir geliştirilmiş gibi görünüyor; fotoğraf baytlarını yüklememek için cihaz üzerinde nesne tanıma ve OCR yapan makine öğrenimi bile çalıştırıyor, yalnızca üretilen etiketleri yüklüyor. Gerçekten çok emek harcanmış ama sonuçta zeki Rus öğrenciler karşısında yeterli olmamış.
    Ancak sunumcunun “belirsizliğe dayalı güvenlik işe yaramaz” sözüne tamamen katılmıyorum. Bu platform 10 yıl boyunca gerçek dünyadaydı ve gizli donanım “özelliğini” ne kadar süredir kötüye kullandığını kimse bilmiyor. O donanım özelliği açıkça belgelenmiş olsaydı çok, çok daha erken bulunurdu.

    • “Donanım özelliği açıkça belgelenmiş olsaydı çok daha erken bulunurdu” kısmı, Kerckhoffs ilkesi gereği zaten baştan açıkça belgelenmiş olması gerektiği ve dağıtımdan önce belgeyi gören herhangi birinin “bu haliyle yayımlanmamalı, bu özellik çıkarılmalı” demesi gerektiği anlamına geliyor.
    • Operation Triangulation ele geçirme göstergelerini iTunes yedeklerinde tarayabilen bir IoC betiği de var: https://github.com/KasperskyLab/triangle_check
    • Gerçekten etkileyici bir saldırı ve yukarıdaki analize katılıyorum. Gizli Safari sekmesiyle cihazı “yeniden hackleme” kısmı, dediğin gibi organizasyon içi siloların kötü bir sonucu da olabilir; 90’lardaki script kiddie’lerin kullandığı “virüs yapma” tarzı yaklaşımı da hatırlatıyor.
      Hızlı uyum için modüler bir tasarım olabilir; yani daha az hedefli bir yapı olma ihtimali de var.
    • Ya da Apple, onlar kibarca rica edince bu “API”yi öylece uygulamış da olabilir.
    • Bu başlıkta çok fazla yanlış bilgi var. Burada[1] açıklandığı gibi bu Hamming ECC.
      [1] https://social.treehouse.systems/@marcan/111655847458820583

  • Steve Weis bunu Twitter’da en iyi şekilde özetledi:
    “Bu iMessage exploit’i çılgınca. 90’lardan beri var olan bir TrueType zafiyeti, 2 kernel exploit’i, bir tarayıcı exploit’i ve yayımlanan yazılımlarda kullanılmayan belgelenmemiş bir donanım özelliği var.”
    https://x.com/sweis/status/1740092722487361809?s=46&t=E3U2EI...

  • Kaspersky araştırmacılarının sunumunu merak ediyorsanız, düzenlenmiş video henüz yüklenmedi ama yayın tekrarını buradan izleyebilirsiniz:
    https://streaming.media.ccc.de/37c3/relive/a91c6e01-49cf-422...
    Sunum 26:20’de başlıyor.

  • 37c3 sunumuyla ilgili Fefe¹’nin Almanca bir yazısı da var: https://blog.fefe.de/?ts=9b729398
    Ona göre bu exploit zincirinin değeri muhtemelen sekiz haneli dolar seviyesindeydi.
    ¹ https://en.wikipedia.org/wiki/Felix_von_Leitner
    Birileri işten atılacak gibi.

    • Neden? Exploit’lerin “yakılması” bu işin bir parçası.

  • Coresight bir arka kapı değil, tüm ARM CPU’larda bulunan bir hata ayıklama özelliği. Bu, Apple’ın bellek koruma işlevleriyle birlikte çalışması gereken bir Coresight uzantısı gibi görünüyor.
    Açık belgeler olmasa bile binlerce Apple mühendisi, bundan yararlanabilen değiştirilmiş gdb’ye ya da başka araçlara erişebiliyor olmalı.

    • Birileri için hata ayıklama aracı olan şey, başkaları için arka kapıdır.
    • Yine de tuhaf hashing’i açıklamıyor.

  • Denetimli bir cihazsa, macOS App Store’daki ücretsiz Apple Configurator aracılığıyla yerel MDM ile iMessage devre dışı bırakılabilir: https://support.apple.com/guide/deployment/restrictions-for-...
    Yalnızca Wi‑Fi kullanan cihazlarda Messages uygulaması gizlenir
    Hem Wi‑Fi hem de hücresel bağlantısı olan cihazlarda Messages uygulaması görünmeye devam eder, ancak yalnızca SMS/MMS hizmetleri kullanılabilir
    Örneğin cihaz uzun süre yalnızca Wi‑Fi ile kullanılacaksa, SIM PIN ile SMS/MMS mesajları ve acil durum dışı hücresel kablosuz trafik devre dışı bırakılabilir

    • Hücresel iPad alıp memleketimdeki SIM kartı takarak SMS almaya devam etmeyi denemiştim. Çünkü o ülkedeki bankalar hâlâ giriş sırasında SMS doğrulaması istiyor
      Ama hücresel iPad’in, SIM kart operatörünün gönderdiği mesajlar dışında SMS’leri pratikte göstermediğini öğrendim

  • Tamamı sıfırlardan oluşan veri yazımının hash değerinin 0 olması dikkat çekiyor
    Ayrıca tek bir bit için hash değeri, S-box tablosundaki tek bir değer oluyor. Yani bu hash algoritması, dahili dokümanlar olmadan da yeterince tersine mühendislik edilebilmiş olabilir

    • Bu, rastgele adreslere yapılan bellek yazmalarının yanlışlıkla bu donanımı tetiklemesini engelleyen tipik bir yöntemin “kokusunu” taşıyor. Bir güvenlik özelliği olarak tasarlanmış gibi görünmüyor
      Gerçekten de biri “bir hata yüzünden keyfî yazma olmamalı” deseydi, ben de böyle uygulardım. Bu uygulama, tampon adresinin bilindiği ama içeriğinin bilinmediği bir durumda bu özelliğin kullanılmasını da etkili biçimde engelliyor
      Hash değeri her yanlış olduğunda sistem yeniden başlatılıyorsa 10 bit güvenlik bile bu amaç için muhtemelen yeterlidir. Coresight hata ayıklama özelliği istenirse sistemi tamamen yeniden başlatabilir

  • Bu MMIO register’ının tüm register adresleri üzerinde brute-force arama yapılarak keşfedilmiş olma ihtimali nedir?
    Yalnızca zamanlama farkıyla bile ilgili adresin geçerli bir adres olduğu anlaşılmış olabilir; hash de fiilen 20 bitlik bir hash olduğundan brute-force mümkün olmuş olabilir

    • Register’ın brute-force ile oldukça kolay tespit edilebildiği izlenimi var. Belgelenmiş GPU register’larına fiziksel olarak yakın ve erişildiğinde GPU paniği oluşuyor; araştırmacılar da bunu GPU bileşenlerine atfetmişti. Saldırgan da aynı testle register’ın varlığını öğrenebilirdi
      Açıklaması daha zor olan kısım, debug kodunu çalıştırmak için özel S-box tablosunu nasıl geri çıkardıkları. İçeriden tehdit iması en çok burada güçleniyor; ancak kişisel olarak bunun diğer makul açıklamaları dışladığını düşünmüyorum
      Örneğin saldırgan S-box’ı eski firmware’lerden, OTA güncelleme yamalarından, piyasaya çıkmadan önceki geliştirme cihazlarından (bir noktada eBay’den satın alınmış olma ihtimali yüksek), iOS beta sürümlerinden veya başka birçok sızıntı kanalından çıkarmış olabilir
      Araştırmacı temelde “baktığım başka hiçbir binary’de bu S-box tablosunu bulamadım” diyor. Ancak Apple’a özel göründüğü için, ortaya çıkmış olabilecek binary sayısının sınırlı olduğu düşünülürse bu mutlaka şaşırtıcı değil. Araştırmacının da söylediği gibi, buna şu anda kamuya açık olmayan ve yanlışlıkla dağıtılmış olabilecek binary’ler de dâhil. Saldırganların bu tür sızıntıları sistematik olarak ararken bir noktada şans eseri elde etmiş olması, araştırmacının ise yakın zamanda aynı şansı yakalayamaması gayet makul
    • O S-box uygulamasına bakınca, bunun çip donanımında lookup table olarak uygulandığına inanmak zor. Aynı sonucu veren daha sıkıştırılmış bir Boolean ifadesi olmalı
      Saldırganların o Boolean ifadesini bilmemesi, dokümanlara sahip olmaktan ziyade tersine mühendislik yaptıklarını düşündürüyor

  • https://streaming.media.ccc.de/37c3/relive/11859

    • 27:21’den başlıyor
      Sunumla birlikte zaman sırasına koyarsak şöyle
      Eylül 2018: Belgelenmemiş MMIO’ya sahip ilk CPU olan Apple A12 Bionic SOC piyasaya çıktı
      Aralık 2021: İlk exploit zinciri altyapısı backuprabbit.com 2021-12-15T18:33:19Z’de, cloudsponcer.com ise 2021-12-17T16:33:50Z’de oluşturuldu
      Nisan 2022: Sonraki exploit zinciri altyapısı snoweeanalytics.com 2022-04-20T15:09:17Z’de oluşturuldu; bu da exploit’in bu tarihe kadar silahlandırılmış olduğunu gösteriyor
      Aralık 2023: Yaklaşık yakalanma zamanı gibi görünüyor. “Yarım yıl”lık analiz süresi ve 2023 ortasındaki Apple raporundan geriye doğru hesaplanan değer
      Konuşmacılar, koddaki izlere göre asıl kaynak APT grubunun aynı saldırı codebase’ini “10 yıl” boyunca, yani yaklaşık 2013’ten beri kullandığını ve macOS dizüstü bilgisayarlara yönelik saldırılarda da kullandığını söylüyor. Antivirüs atlatma da buna dâhil
      Konuşmacılar ayrıca Apple’ın haberi olmadan, örneğin bir GPU geliştiricisi tarafından, çipe oldukça “backdoor benzeri” imzalı bir debug özelliğinin eklenmiş olma ihtimaline de değiniyor
      Yani ilk savunmasız çip piyasaya çıktıktan 3,5 yıldan az bir süre sonra, uzun gizli değerler hakkında bilgi gerektiren Apple Coresight GPU’nun belgelenmemiş debug MMIO serisi, 10 yılı aşkın geçmişi olan mevcut bir APT grubu tarafından başarıyla silahlandırılıp kötüye kullanılmış oluyor. Kaspersky “tahmin yürütmüyoruz” diyor, ancak kişisel olarak büyük bir devlet aktörü dışında pek olası görünmüyor
      Tahmin yürütmek gerekirse, Apple APT ile ilişkili yaklaşık 40 Apple ID’nin kendi kimliklerini açığa çıkardığına dair yeterli kanıt almış olduğundan, kimliği daha sonra ABD’nin ulusal güvenlikle ilgili açıklama yapıp yapmamasına bakarak anlayabiliriz gibi geliyor. Sessizlik olursa muhtemelen NSA’dir
    • Gerçek kaydın ilk sürümü gibi görünen kayıt şimdi yüklenmiş:
      https://media.ccc.de/v/37c3-11859-operation_triangulation_wh...