iLeakage: Apple cihazlarına yönelik tarayıcı tabanlı, zamanlayıcısız spekülatif yürütme saldırısı

 (ileakage.com)
1 puan yazan GN⁺ 2023-10-26 | 1 yorum | WhatsApp'ta paylaş
  • Spectre azaltmaları yaklaşık 6 yıldır sürse de iLeakage, Mac, iPad ve iPhone’lardaki Safari’de spekülatif yürütme yan kanalının hâlâ istismar edilebildiğini gösteriyor
  • Saldırgan, kullanıcıyı kötü amaçlı bir web sayfasını ziyaret edip tıklamaya yönlendirdikten sonra JavaScript ve WebAssembly ile Safari’nin rastgele web sayfalarını işlemesini sağlayarak hassas bilgileri kurtarabiliyor
  • Gösterimler arasında Gmail’deki son mesaj başlıkları, Instagram otomatik doldurma kimlik bilgileri, YouTube izleme geçmişi, Apple M3 tabanlı MacBook Pro’da Facebook parolası ve SMS 2FA token’ının kurtarılması yer alıyor
  • Etki alanı, Apple A-series ve M-series CPU kullanan macOS ve iOS cihazları kapsıyor; Safari 17.2’nin dahil olduğu iOS 17.2 ve macOS 14.2’de azaltıldı
  • Lockdown Mode veya JavaScript’i devre dışı bırakmak da saldırıyı engelleyebilir ancak işlev kısıtlamaları vardır; Safari içinde çalıştığı ve sistem günlüklerinde iz bırakmadığı için tespiti çok zordur

Apple cihazlarında yeniden ortaya çıkan Spectre riski

  • iLeakage, Safari web tarayıcısını hedefleyen bir spekülatif yürütme yan kanal saldırısıdır
  • Hedef, Apple’ın A-series veya M-series CPU kullanan macOS ve iOS cihazlarıdır
    • Son dönem iPhone ve iPad’ler buna dahildir
    • 2020’den sonraki Apple dizüstü ve masaüstü bilgisayarları da buna dahildir
  • Normalde bir tarayıcı sekmesindeki kodun başka bir sekmenin içeriğini çıkaramaması gerekir; ancak iLeakage, saldırganın sayfasını ziyaret edip tıklayan kullanıcının hedef web sayfası içeriğini okuyabilir
  • Kurtarılabilecek bilgiler arasında kişisel bilgiler, parolalar ve kredi kartı bilgileri bulunabilir
  • Araştırmacılar bulguları 12 Eylül 2022’de Apple’a açıkladı; bu, halka açık sürümden 408 gün önceydi

Gerçekte kurtarılan hassas veriler

  • Araştırmacılar popüler hizmetlerden yüksek değerli bilgilerin kurtarıldığı örnekler gösterdi

  • Instagram kimlik bilgileri

    • macOS Safari’de kullanıcının LastPass otomatik doldurma kimlik bilgisi yöneticisiyle Instagram’a giriş yaptığı bir senaryo kullanıldı

  • Gmail gelen kutusu

    • iOS Safari’de kullanıcının Google’da oturum açmış olduğu varsayıldı ve iPad’deki Gmail hesabının son mesaj başlıkları kurtarıldı

  • YouTube izleme geçmişi

    • iOS için Chrome’da YouTube izleme geçmişi kurtarıldı
    • iOS için Chrome, Apple App Store politikası nedeniyle Safari tarama motoru üzerinde çalışan bir kabuk gibi davranır

  • Facebook parolası ve 2FA token’ı

    • Apple M3 çipli MacBook Pro, macOS 14.1.1 ve Safari 17.1 ortamında önce Facebook parolası kurtarıldı
    • Ardından Android telefona gönderilen SMS 2FA token’ı Google Messages üzerinden kurtarıldı

Spectre ve yan kanalın çalışma biçimi

  • Modern CPU’ların çoğu, dal sonucunun hemen ortaya çıkmadığı durumlarda yürütme yolunu tahmin edip o yoldaki komutları önceden işleyen spekülatif yürütme kullanır
  • Tahmin yanlışsa CPU durum değişikliklerini geri alır; ancak önbellek gibi mikro mimari durumda izler kalabilir
  • Spectre, bu izleri kullanarak normal program anlamı açısından erişilememesi gereken verileri okuyan bir donanım açığıdır
  • Yan kanallar, program güvenli bir algoritma çalıştırsa bile sistemin uygulama özelliklerini istismar edebilir
    • Örnekler arasında ses, elektromanyetik yayılım, termal throttling ve CPU mikro mimari kaynak paylaşımı bulunur
  • Saldırgan ve hedef aynı CPU üzerinde çalıştığında çekirdek, önbellek ve iç tamponlar gibi kaynakları paylaşır; bu çekişme zamanlama veya güç tüketimi gibi değişkenlerle dolaylı olarak ölçülebilir

Safari savunmalarını aşan zamanlayıcısız saldırı yapısı

  • Tarayıcı üreticileri, Spectre’den bu yana spekülatif yürütme ve geçici yürütme saldırılarına karşı savunmalarını güçlendiriyor
  • Safari savunmaları arasında 35-bit addressing, value poisoning, sekme başına süreç izolasyon politikası ve düşük çözünürlüklü zamanlayıcılar yer alır
  • iLeakage, Apple Silicon CPU’lara ve Safari’ye karşı gösterilen ilk spekülatif yürütme saldırısıdır
  • Saldırı, Apple CPU’ların kamuya açıklanmamış önbellek yapılandırmasının deneysel olarak geri kazanılmasıyla başlar
    • Ardından yalnızca düşük çözünürlüklü zamanlayıcılarla önbellek isabeti ve kaçırmayı ayırt eden spekülasyon tabanlı bir gadget oluşturulur
    • Zamanlayıcı olmadan race condition kullanan bir varyant da gösterildi
  • Bu gadget hem eviction set oluşturma testlerinde hem de covert channel’da kullanılır
  • Teknik Safari’ye taşındıktan sonra, CPU spekülatif yürütmedeyken Safari’nin belirli veri tiplerine yönelik kodu saldırganın oluşturduğu hatalı tipteki nesneler üzerinde çalıştırması sağlanır
  • Sonuç olarak Safari render sürecinin adres alanının herhangi bir yerinde out-of-bounds read mümkün hâle gelir
  • Farklı alan adlarındaki web sitelerini aynı adres alanında birleştiren yeni bir yöntemle birlikte, hassas bilgileri sızdıran speculative type confusion saldırısı gerçekleştirilir

Azaltmalar, tespit zorluğu ve tarayıcılara göre etki

  • iLeakage, Safari 17.2’de azaltıldı; Safari 17.2 iOS 17.2 ve macOS 14.2’ye dahildir
    • Çözüm, Apple cihazlarını en güncel işletim sistemi sürümüne yükseltmektir
  • Lockdown Mode, Safari’nin JIT derlemesini devre dışı bırakarak iLeakage’ı azaltır
    • JIT derleme, iLeakage’ın saldırı ilkelini oluşturmak için kullandığı bir performans özelliğidir
    • Lockdown Mode, bazı mesaj eklerini ve bilinmeyen FaceTime aramalarını engellemek gibi cihaz davranışlarını değiştirebilir
    • Tam liste Apple’ın Lockdown Mode belgelerinde yer alır
  • JavaScript’i devre dışı bırakmak da iLeakage’ı engeller; ancak Safari bazı web sitelerini hatalı veya eksik render edebilir ve çevrimiçi ödeme gibi gelişmiş web işlevleri çalışmayabilir
  • iLeakage, Safari içinde çalıştığı ve sistem günlük dosyalarında iz bırakmadığı için tespiti çok zordur
    • Ancak saldırganın web sayfasının ziyaret edildiğine dair izler, yakın zamanda ziyaret edilen sayfalar için tarayıcı önbelleğinde kalabilir
  • Gerçek dünyada istismar edildiğine dair kanıt yoktur
    • Uçtan uca saldırı kurgusu çok zordur ve tarayıcı tabanlı yan kanal saldırıları ile Safari uygulaması hakkında ileri düzey bilgi gerektirir
  • Kimlik bilgisi yöneticilerini kullanmaya devam etmek önerilir
    • iLeakage, web sayfasına otomatik doldurulmuş kimlik bilgilerini kurtarabilir
    • Birçok platformda otomatik doldurmanın gerçekleşmesi için kullanıcı etkileşimi gerekir
  • macOS’te Chrome, Firefox ve Microsoft Edge farklı JavaScript motorları kullandığından, Safari JavaScript motoruna özgü ayrıntıları istismar eden iLeakage çalışmaz
  • iOS’te Apple App Store ve sandboxing politikaları nedeniyle diğer tarayıcı uygulamaları da Safari JavaScript motorunu kullanır
    • iOS için Chrome, Firefox ve Edge; yer imleri ve ayar senkronizasyonu gibi yardımcı işlevler sunan Safari üzerindeki sarmalayıcılardır
    • App Store’daki neredeyse tüm tarayıcı uygulamaları iLeakage’a karşı savunmasızdır
  • Akademik makale iLeakage paper olarak sunulmuştur ve 2023 ACM Conference on Computer and Communications Security’de yayımlanmıştır

İlgili okumalar

1 yorum

 
GN⁺ 2023-10-26
Hacker News yorumları

  • Bu FAQ'da eksik görünen bir şey var: Bunun bir WebKit açığı mı yoksa Safari açığı mı olduğu; mobil Safari'de ilgili geliştirici ayarı yokken Lockdown Mode açılırsa hafifletilip hafifletilmediği; Apple'a ne zaman bildirildiği merak konusu
    Daha sonra sayfa güncellendi ve son soruya yanıt gelmiş; araştırmacılar bulguları 12 Eylül 2022'de Apple'a bildirdiklerini, bunun herkese açık yayınından 408 gün önce olduğunu söylüyor

    • Teknik olarak Hacker News Favorite Processor, yani bir M1/M2 açığı olarak görülebilir; ancak piyasadaki ilgili CPU'ların hepsi aynı zafiyete sahip olduğundan, yazılımların bunu hafifletecek şekilde tasarlanması gereken bir özellik hâline gelmiş durumda
      WebKit'te olası tüm Spectre gadget'larını kaldırmak gerçekçi olmadığından, tarayıcıların farklı web sitelerini farklı süreçlere izole ederek işletim sisteminin Spectre hafifletmelerinden yararlanması gerekiyor
      FAQ'da “sonuçta Safari render sürecinin adres alanının herhangi bir yerinden sınır dışı okuma elde ediyor” dendiği için, ben şahsen bunu Safari'nin site izolasyonunun yanlış uygulanmasından kaynaklanan bir açık olarak görüyorum
    • Son sorunun yanıtı FAQ'da var: Araştırmacılar sonuçları 12 Eylül 2022'de Apple'a bildirmiş; bu da herkese açık yayından 408 gün önceymiş
    • Bu, Safari veya başka tarayıcıların içinde Spectre benzeri spekülatif yürütme yan kanallarından yararlanılmasını sağlayan mimari bir açık gibi görünüyor
      Hangi ortamlarda istismar edilebildiği, bu yan kanalı tetikleyen ve ölçen JavaScript tabanlı gadget'ın ayrıntılı uygulamasına bağlı; bunlar henüz okumadığım makalede yer alıyor olabilir
    • Artık FAQ'da yanıt yayımlanmış: Bu bir Safari açığı ve “iLeakage, Safari'nin JavaScript motoru özelliklerinden yararlanır” deniyor
      Lockdown Mode, Safari'de JIT derlemeyi devre dışı bıraktığı için hafifletme sağlıyor; iLeakage'ın saldırı ilkelini oluşturmak için kullandığı performans özelliklerini engellediği söyleniyor

  • “Kimlik bilgisi yöneticisi kullanmak riskli mi?” sorusuna çoğu yanıt hayır diyor; ama bellekten bir şeyler sızıyorsa bunun Safari süreç alanı içindeki tüm belleği etkilemesi gerekmez mi diye düşünüyorum
    Bu alana aşina olmadığım için kimlik bilgisi yöneticisi kullanıp kullanmamanın neden istisna koşulu olduğunu pek anlayamıyorum

    • Temelde şunu söylüyorlar gibi: Bu belirli saldırıya ek bir güvenlik sağlamıyor ama parola yöneticisi kullanmak genel olarak daha güvenli ve sizi bu saldırıya karşı daha savunmasız hâle getirmiyor
      İnsanların “newpassword2” gibi yöntemlere dönmesini önlemeye çalışıyorlar gibi; otomatik doldurmayı kapatıp kısayol ya da başka bir kullanıcı etkileşimiyle doldurmak daha güvenli
    • Demolardan biri, parola yöneticisinin alanları otomatik doldurup bunları belleğe koyması sayesinde Instagram gibi üçüncü taraf sitelerin kullanıcı adı/parola kombinasyonunu kurtarmayı gösteriyordu
      Parola yöneticisi kullanmayıp tarayıcıya da kaydetmez, her seferinde kendiniz girerseniz bağışık olursunuz diye okunabilir; ama bu çeşitli nedenlerle iyi bir karşı argüman değil
      Parola yöneticileri başka birçok nedenle faydalı ve parola çalınsa bile en azından yalnızca tek bir web sitesi tehlikeye girer
      Bu teknik muhtemelen oturum token'larını da çalabilir; parola çalınması kadar olmasa da bu yine de kötü
      Parola yöneticisini ancak tıklayınca dolduracak şekilde ayarlarsanız bu saldırıyı da engelleyebilirsiniz
    • Parola yöneticisi kullanmanın sizi daha savunmasız hâle getirmediği anlamına geliyor gibi
      Sayfaya otomatik doldurulan parola, elle girilmiş parola gibi kurtarılabilir; ancak parola yöneticisinin içinde kayıtlı tüm parolalar doğrudan okunamaz demek istiyor
    • Bu açığın ilgili Safari/WebKit süreçlerinin belleğine, daha spesifik olarak window.open çağrısıyla açılan sitelere erişime izin verdiğini anlıyorum
      Ayrı bir parola yöneticisi uygulamasında kayıtlı parolalara, o uygulama bunları ele geçirilmiş Safari penceresine veya sürecine otomatik doldurmadığı sürece erişilemez
    • Safari'nin genelde farklı origin'leri ve eklentileri farklı adres alanlarında tuttuğu için spekülatif yürütme saldırılarına açık olmadığını anlıyorum
      Bu saldırı, iki farklı origin'in aynı adres alanını paylaşmasını sağlamanın bir yolunu bulmuş; eklentiler için geçerli olmadığını düşünüyorum
      Makalede “Safari'nin site izolasyonu politikasından yararlanarak, saldırgan sayfanın JavaScript window.open API'siyle herhangi bir kurban sayfayı açmasının adres alanını paylaşmak için yeterli olduğu yeni bir teknik gösteriyoruz” deniyor

  • Bunun WebKit'e özgü diye çerçevelenmesi gerçekten doğru mu, emin değilim. Önbellek istismarının kendisi genel görünüyor; alıntıda da Safari, Firefox ve Tor genelinde neredeyse kusursuz doğruluk gösterdiği söyleniyor
    Ayrıca window.open() üzerinden saldırının gerçekten WebKit'e özgü olup olmadığı, yoksa bu çalışmada yalnızca WebKit'in mi derinlemesine incelendiği merak konusu
    window.open() çağıran pencerenin yeni pencerenin referansını alması, yeni pencerenin de window.opener ile geri referansa sahip olması paylaşımlı bir bağlamı ima ediyor; diğer tarayıcı motorlarının tam izolasyon sağlayıp sağlamadığı da soru işareti

    • Chromium ve Firefox, masaüstü tarayıcılarda site izolasyonu uyguluyor; aynı siteye ait olmayan sayfaların aynı sürece yüklenmemesi gerekir
      Mobil tarayıcılarda Chromium'un site izolasyonu sınırlı, Firefox ise uygulamayı henüz tamamlamadı
      https://www.chromium.org/Home/chromium-security/site-isolati...

  • Kafa karıştırıcı. Bu ciddi önemde bir sorun gibi görünüyor ama düzeltme debug menüsünün arkasında. Her yere düzgünce dağıtılmadan önce neden açıklandığını anlamıyorum
    Ayrıca yan kanal önlemlerinin pratikte işe yaramadığını ve bu tür saldırılar düzeltilmiş gibi davranılmaması gerektiğini de gösteriyor
    Modern CPU’larda birden fazla uygulama çalıştıran bir host söz konusuysa, ne kadar sandbox uygulansa da güvenilmeyen kod çalıştırmak güvenli değil

    • Apple’ın bunu düzeltmek için 400 günden fazla zamanı olmuş gibi görünüyor; bu, benim vereceğim süreden bile uzundu
      Apple kullanıcılarının riski bilmeden bir yılı aşkın süre daha ortada bırakılmasındansa, riskten haberdar edilmeleri bence çok daha iyi
      Şirketlere hataları düzeltmeleri için zaman verilmesini destekliyorum, ama bir noktadan sonra etkilenen kişilere haber vermemek daha sorumsuzca hale geliyor
    • Önlem durumunu ben de kafa karıştırıcı buluyorum ama makale web sitesinden daha net
      Makale, spekülatif JavaScript sandbox kaçışının hâlâ mümkün olduğunu, ancak saldırganın kendi adres alanını ve kendi verilerini okumakla sınırlı kaldığını açıklıyor
      Yazıldığı sırada Apple yamasının açık olduğunu ve Safari Technology Preview 173 ve sonrasında uygulanmış olduğunu söylüyor; [57] ise https://github.com/WebKit/WebKit/pull/10169
      Bunun altında mühendis window.open() ve süreç izolasyonuna yönelik ek sıkılaştırma yamalarını bağlantılamaya devam ediyor
    • Ventura’da standart Safari 17.0’da Swap Processes on Cross-Site Window Open özelliğinin zaten açık olduğunu ve Stable olarak işaretlendiğini sanmıştım
      Kendim açmadığım için Apple’ın bunu zaten etkinleştirmiş olabileceğini ve açıklamanın eski kalmış olabileceğini düşündüm, ama sonra benzer adlı Swap Processes on Cross-Site Navigation özelliğine baktığımı fark ettim; şu anda varsayılan olarak etkin değil gibi
    • Bunun nedeni, “gizlilik ve güvenliğin son kalesi” denilen Apple’ın bunu 400 günden fazla elinde tutup yine de düzeltmemiş olması
      Düzeltme dağıtılmadan önce açıklayan araştırmacılardan çok, bu kadar uzun süre eli kolu bağlı duran Apple suçlanmalı
    • Bu düzeltme WebKit’in süreç modelini değiştirmeyi gerektirdiği için, tam dağıtımdan önce hâlâ test aşamasında olduğundan debug menüsünün arkasında olması muhtemel
      Tüm yan kanal saldırıları düzeltilmiş değil, ama yan kanal önlemlerinin işe yaramaz olduğunu söylemek doğru değil
      Emniyet kemeri takılsa da araba kazalarında insanlar ölebilir; ama bu emniyet kemerinin işe yaramadığı anlamına gelmediği gibi, önlemler de kötüye kullanımın zorluğunu ciddi biçimde artırır

  • “Araştırmacılar bulgularını 12 Eylül 2022’de Apple’a açıkladı” deniyor; Apple’ın neden bir yılı aşkın süre neredeyse hiçbir şey yapmadığını gerçekten merak ediyorum

    • Çünkü yapabiliyor
      Apple CVE güç sahiplerinden biri; kendi ürünleri için CVE verilmesini reddedebilir ve böyle bir gücü olunca istediği kadar yavaş hareket edebilir

  • iLeakage web sitesinde düzeltmeyle ilgili bir ifade gördüğümü sanmıştım ama kayboldu. Yanıldığımı düşündüm, fakat web sitesi gerçekten son bir saat içinde değişiyormuş
    “Apple iOS 17.1, iPadOS 17.1, macOS Sonoma 14.1’i az önce yayımladı, cihazlarınızı güncelleyin” şeklinde bir ifade vardı; şimdi geri alınmış
    https://github.com/ileakage-authors/ileakage-authors.github....

    • Makalenin yazarlarından biri bu thread’i okuyor gibi
      Sitede açıklama takvimi olmadığını belirtince FAQ’ya kısa bir bölüm eklendi; düzeltmenin dağıtılıp dağıtılmadığı konusundaki durum kafa karıştırıcı olduğu için araştırmacılar da aynı şekilde karışmış gibi görünüyor
    • Tuhaf. iOS 17.1’e güncelledim; Settings -> Safari -> Advanced -> Feature Flags altında Swap Processes on Cross-Site Navigation var ve varsayılan olarak açık
      macOS’teki Swap Processes on Cross-Site Window Open ile farklı bir şey mi merak ediyorum

  • Apple’ın çok umursamamasının nedeni, “iLeakage uçtan uca yürütmesi oldukça zor bir saldırıdır; tarayıcı tabanlı yan kanal saldırıları ve Safari uygulaması hakkında ileri düzey bilgi gerektirir” ifadesi olabilir

    • Çalıştırması çok zor olduğu için pratikte imkânsız ve fiilen riskin %0’a yakın olduğu anlamına geliyor gibi
      Bir de buna korkutucu bir takma ad ve alan adı verilmesi hiç profesyonel ya da güvenilir görünmüyor

  • Apple A serisi veya M serisi CPU içeren macOS ya da iOS cihazlar, yani yeni iPhone/iPad’ler ve 2020 sonrası Apple dizüstü ve masaüstü bilgisayarları etkileniyorsa, nadir bir Intel Mac kullanıcısı olarak ben etkilenmiyor gibiyim

    • Muhtemelen etkilenme ihtimali yüksek
      Yalnızca önbellek hiyerarşisi biraz farklıdır; kavram kanıtında küçük değişiklikler gerekecektir
    • macOS ise Safari kullanmamak yeterli
      iOS ise Lockdown Mode kullanmak gerekir; iPhone’u güvenli kullanmanın tek yolu bu
      Lockdown Mode olmadan yapılan bir benchmark, CPU benchmark’ını mitigations=off ile çalıştırmak kadar işe yaramaz kabul edilmeli

  • iOS cihazlarda başka tarayıcı motorlarına izin verilmesi için bir iyi gerekçe daha

    • AB düzenlemeleri sonunda Apple’ı buna zorlayabilir

  • Aşağıdaki komutu çalıştırırken hata alırsanız Terminal’e Full Disk Access verip tekrar deneyebilirsiniz
    defaults write com.apple.SafariTechnologyPreview IncludeInternalDebugMenu 1