Windows sürücü imzası atlatmasıyla çekirdek rootkit kurulumu mümkün olabilir

 (bleepingcomputer.com)
1 puan yazan GN⁺ 2024-10-27 | 1 yorum | WhatsApp'ta paylaş
  • Dışarıdan en son yamalar uygulanmış gibi görünen bir Windows’ta bile Windows Update süreci ele geçirilirse eski çekirdek bileşenlerine geri dönülebilir; bu da Driver Signature Enforcement’ın atlatılmasına ve çekirdek rootkit’lerinin dağıtılmasına yol açabilir
  • SafeBreach araştırmacısı Alon Leviev, BlackHat ve DEFCON’da downgrade/sürüm geri alma saldırılarını gösterdi; Windows Update takeover ise hâlâ tamamen yamalanmamış durumda
  • Yönetici yetkilerine sahip bir saldırgan, en güncel Windows 11’de bile ci.dll dosyasını yamalanmamış bir sürümle değiştirerek imzasız çekirdek sürücülerinin yüklenmesini mümkün kılabilir
  • Virtualization-based Security, UEFI kilidi ve kayıt defteri ayarlarına dayandığından, Mandatory bayrağı olmayan yapılandırmalarda kayıt defteri değişiklikleri veya kritik dosyaların değiştirilmesi bir atlatma yolu olabilir
  • Microsoft, eski VBS sistem dosyalarını kullanım dışı bırakan bir güvenlik güncellemesi geliştiriyor; ancak etkilenen sürümlerin incelenmesi, uyumluluk testleri ve regresyonların önlenmesi nedeniyle ne zaman yayımlanacağı belirsiz

En güncel yama durumunu etkisizleştiren downgrade saldırısı

  • Saldırgan, Windows Update sürecini kontrol ederek güncel görünen bir sisteme eski ve savunmasız bileşenleri yeniden yerleştirebilir
  • İşletim sistemi hâlâ tamamen yamalıymış gibi görünür, ancak gerçekte daha önce düzeltilmiş güvenlik açıklarına yeniden maruz kalır
  • Downgrade hedefleri arasında DLL’ler, sürücüler ve NT kernel gibi bileşenler bulunur
  • Alon Leviev, özel downgrade’ler oluşturulabileceğini göstermek için Windows Downdate aracını yayımladı

Driver Signature Enforcement atlatması ve rootkit riski

  • Leviev, çekirdek güvenliği güçlendirildikten sonra bile Driver Signature Enforcement(DSE) atlatmasının mümkün olduğunu gösterdi
  • DSE başarıyla atlatılırsa saldırgan imzasız çekirdek sürücülerini yükleyebilir
  • Bu tür sürücüler, güvenlik kontrollerini devre dışı bırakmak ve ihlal tespitini zorlaştırmak için rootkit zararlılarının dağıtımında kullanılabilir
  • Leviev kendi yöntemini "ItsNotASecurityBoundary" DSE bypass olarak adlandırıyor
    • Bu yöntem, ItsNotASecurityBoundary exploit’inin downgrade edilmesi biçiminde çalışıyor
    • Söz konusu exploit, Elastic’ten Gabriel Landau’nun belirlediği Windows’taki sahte dosya değişmezliği(false file immutability) zafiyetleri sınıfından yararlanarak çekirdek yetkileriyle rastgele kod çalıştırılmasını mümkün kılıyor

ci.dll değişimi ve yeniden başlatma koşulu

  • Yeni araştırmada Leviev, yönetici yetkilerine sahip bir saldırganın Windows Update sürecini kötüye kullanarak tamamen güncellenmiş Windows 11 üzerinde bile DSE korumasını atlatabileceğini gösterdi
  • Kilit nokta, DSE’yi zorunlu kılan ci.dll dosyasını sürücü imzalarını yok sayan yamalanmamış bir sürümle değiştirmek
  • Bileşen savunmasız bir sürüme downgrade edildikten sonra, normal güncelleme sürecinde olduğu gibi sistemin yeniden başlatılması gerekiyor
  • Leviev, tamamen yamalı bir Windows 11 23H2 sisteminde DSE yamasını downgrade ile geri alıp ardından ilgili bileşenden yararlanan bir demo yayımladı

VBS ayarları zayıf olduğunda açılan atlatma yolları

  • Leviev, Microsoft’un Virtualization-based Security(VBS) özelliğini devre dışı bırakma veya atlatma yöntemlerini de ele alıyor
  • VBS, Windows’un kritik kaynaklarını ve güvenlik varlıklarını korumak için izole bir ortam oluşturur
    • Korunanlar arasında güvenli çekirdek kod bütünlüğü mekanizması olan skci.dll ve kimliği doğrulanmış kullanıcı kimlik bilgileri yer alır
  • VBS genellikle UEFI kilidi ve kayıt defteri yapılandırması gibi korumalara dayanır
  • VBS, en yüksek güvenlik ayarı olan “Mandatory” flag ile yapılandırılmamışsa, hedef kayıt defteri anahtarlarının değiştirilmesiyle devre dışı bırakılabilir
  • VBS yalnızca kısmen etkinleştirilmişse SecureKernel.exe gibi kritik VBS dosyaları bozuk sürümlerle değiştirilerek VBS’nin çalışması engellenebilir
    • Bu durum, “ItsNotASecurityBoundary” atlatmasına ve ci.dll değişimine giden yolu açabilir

Microsoft’un yanıtı ve kalan boşluklar

  • BlackHat ve DEFCON’da açıklanan downgrade saldırılarında kullanılan CVE-2024-21302 ve CVE-2024-38202 ele alındı, ancak Windows Update takeover sorunu hâlâ devam ediyor
  • Microsoft, bu sorunun tanımlı bir güvenlik sınırını aşmadığı görüşünde; yönetici yetkileriyle çekirdek kodu çalıştırmanın güvenlik sınırı ihlali olmadığına karar verdi
  • Leviev, Microsoft sorunu düzeltene kadar güvenlik çözümlerinin downgrade saldırılarını izlemesi ve tespit etmesi gerektiğini vurguluyor
  • Microsoft, bu riski engellemek için azaltma önlemleri üzerinde aktif olarak çalıştığını belirtti
  • Şirket, eski ve yamalanmamış VBS sistem dosyalarını kullanım dışı bırakacak bir güvenlik güncellemesi geliştiriyor
    • Bu süreç, etkilenen tüm sürümlerin incelenmesini, güncelleme geliştirmeyi ve uyumluluk testlerini kapsıyor
    • Müşterileri korumak ve operasyonel kesintileri en aza indirmek için entegrasyon hatalarından veya regresyonlardan kaçınılması gerekiyor
    • Sorunun karmaşıklığı nedeniyle güncellemenin ne zaman sunulacağı belirsiz
  • 27 Ekim güncellemesinde saldırı için yönetici yetkilerinin gerektiği netleştirildi ve Microsoft’un azaltma önlemleri almadığı yönündeki karışıklığı azaltmak için ek bilgi eklendi

İlgili okumalar

1 yorum

 
GN⁺ 2024-10-27
Hacker News yorumları

  • MS, UAC'nin bir güvenlik sınırı olmadığını söylüyor; bu, bazı kullanıcıların yönetici yetkisine yükselmesi meselesi
    Ancak bu örnekte olduğu gibi yöneticiden çekirdeğe geçmenin de bir güvenlik sınırı olmadığını söylerken, aynı zamanda sürücü imzası zorunluluğunun bir güvenlik özelliği olduğunu söylüyor
    Burada tam da o özellik atlatılırken bile bunun bir güvenlik sınırını aşmak olmadığını söylüyorlar; bunu tutarlı biçimde açıklamalarını isterdim

    • MS'in mantığı anlamlı. Kaçırılan temel bir nokta var
      UAC, zaten yöneticiler grubunda olan kullanıcılar içindir; “bazı kullanıcıların yönetici olması” işlevi değildir
      Güvenlik sınırı yönetici kullanıcının değil, standart kullanıcının etrafındadır
      Hoşunuza gitmeyebilir ama bir güvenlik sınırı istiyorsanız kullanıcıyı Administrators grubuna koymazsınız
    • Bu bir değer sistemi uyumsuzluğu gibi görünüyor
      Görüş ayrılıklarında genelde tanım uyuşmazlığı ve değer sistemi uyuşmazlığı olduğunu düşünüyorum
      Bu durumda Microsoft bu sorunu küçültmeye değer veriyor; eğer bu en üst öncelikse, kararları o ölçüte göre tutarlı görünebilir
      Tanım uyuşmazlığını çözmek nispeten kolaydır. Örneğin bir yazılım sistemi tasarımı üzerine herkes tasarım kalıpları terimleriyle konuşur ama herkes A'yı A′ ya da A″ olarak farklı anlarsa büyük bir karmaşa çıkabilir
    • Windows hatalarını düzelttirmek için ücretli profesyonel destek satın almak gerektiğini öğrendim
      Şirketlerin yönettiği açık kaynak yazılımlar için de aynı şey geçerli
      Asıl soru, insanların zihinsel enerjilerini masaüstü Linux'u iyileştirmeye harcamak yerine neden Microsoft için ücretsiz güvenlik araştırması yaptığı
    • Gerçekte UAC bir güvenlik sınırı olarak çalışmıyor; öyle yapılırsa kullanıcılar aşırı rahatsız olur ve başka işletim sistemlerine gider
      UAC ve sudo, ikisi de işletim sistemi düzeyinde çerez onay pencerelerine benziyor; bence üçünü de kaldırmak daha iyi
      UAC/sudo gibi kullanıcı tabanlı yetki yükseltme yöntemlerinden vazgeçip, Android ve iOS'ta olduğu gibi kullanıcıları değil uygulamaları sandbox'a almak gerekiyor
    • Microsoft'ta hep böyle çelişkiler vardı. Muhtemelen hepsinin pek çok atlatma yolu olduğunu bildikleri içindir diye düşünüyorum

  • Hem Windows'ta hem Linux'ta normal yetkili yerel hesapların gerçekte neredeyse root eşdeğeri yetki gibi davranması da ilginç
    Linux'ta sistemle ilgili işlerin başına sudo koymak üzere eğitiliyoruz; Windows'ta ise UAC istemini tıklayıp geçmek üzere eğitiliyoruz
    sudo'nun parola yazım hatası dışında bir nedenle birine “olmaz” dediği son zaman ne zamandı, merak ediyorum
    UAC, sistemin yönettiği bir arayüzken sudo sadece bir program; saldırganın kötü amaçlı bir shell alias'ıyla sudo'yu değiştirip parolayı çalabilmesi açısından UAC biraz daha iyi
    Varsayılan ayarlarda sudo ve UAC'yi kaldırmak, root ile ana kullanıcının yerel hesabı arasında sağlam bir güvenlik sınırı varmış gibi yapmamak hem kullanıcı için daha rahat hem de gerçek güvenlik durumuna daha uygun olur

    • Linux'ta modern kullanıcı uygulamalarının çoğu sudo yerine polkit kullanıyor
      Terminalde de sudo yerine pkexec kullanılabilir
      Rastgele komutları root olarak çalıştırmak yerine uygulamalar org.freedesktop.udisks2.filesystem-mount gibi önceden tanımlı eylemleri kullanabilir; kullanıcıya uygulamanın ne yapmaya çalıştığını yerelleştirilmiş bir mesajla gösterip izin verip vermeyeceğine karar vermesini sağlar
      Sistem yöneticisi, flatpak güncellemeleri gibi belirli eylemler için kimlik doğrulama istememeyi ya da tersine belirli eylemleri tamamen engellemeyi de ayarlayabilir
    • Aynı şeyi farklı söyleyince kulağa çok farklı geliyor: Hem Windows'ta hem Linux'ta varsayılan kurulum kullanıcısı gerçekte root eşdeğerine yakındır
      Kurulumu yapan kullanıcının sistemi kontrol etmesi gerektiği varsayımı var bence. Sonuçta en başta kurulum yapmayabilirdi
      sudo da UAC gibi kişiye “olmaz” diyen bir mekanizma değildir. İkisi de yönetici beklenmedik bir yönetim işi yapmaya kalkıştığında kişinin “olmaz” demesini sağlamak için tasarlanmıştır
      Yönetici yetkisi olmayan ama böyle bir işi yapması gereken kişi yöneticiden onay almalıdır
      Tek kişilik bir sistem değilse, makineyi kuran kişi günlük kullanım için kısıtlı bir hesap oluşturmalıdır
    • Linux'ta sudo kurmuyorum
      Sık sık root olmam gerekmiyor; gerektiğinde de genelde arka arkaya birkaç iş yapıyorum
      sudo'nun, şirketin sahip olduğu ve yönettiği bilgisayarlar gibi çok kullanıcılı bilgisayarlarda, yöneticinin bazı kullanıcılara yalnızca sınırlı ayrıcalıklı işleri yaptırmak istediği durumlarda faydalı olduğunu düşünüyorum
      Root olmayan başka bir hesabı sürekli kullanmanın başlıca nedeni güvenlikten çok hataları önlemek. Amaç, istemeden dosya silmeyi ya da üzerine yazmayı engellemek
      Bu yüzden nadiren rol değiştirmek için parola girmek bence yeterince gerekçelendirilebilir
    • Deneyimime göre en azından Gnome'da Linux da Windows tarzı sudo korumasına doğru gidiyor
      Ancak “onaylamak için ctrl+alt+delete'e basın” numarası yok
      Windows'un avantajı, her şeyi script'e dökmeniz gerekmemesi
      İsterseniz tüm araçları runas/System.Management.Automation.PSCredential ile sarmalayabilirsiniz ama çoğu durumda buna gerek yok

  • Çekirdek, dosya açılırken tüm açık dosya handle'larını tarayıp çakışan zorunlu kilitlemeleri kontrol ederek dosya paylaşım kurallarını uyguluyor; ancak çakışan yetkilere sahip bellek eşlemelerini kontrol etmeyen bir yapı gibi görünüyor
    Bu bir hata ama düzeltmesi nispeten basit görünüyor
    İlginç biçimde Linux, zorunlu kilitlemenin son kalıntılarını yeni kaldırdı. Artık yüklü çalıştırılabilir dosyaya yazınca EBUSY dönmüyor
    Aynı özelliğin bir işletim sisteminde güvenlik altyapısının yük taşıyan bir parçası, başka bir işletim sisteminde ise silinmesi gereken eski bir kalıntı olması ilginç

  • Güvenlik uzmanı değilim, yalnızca temel şeyleri anlıyorum ama sanki bir kavramsal modeli kaçırıyor gibiyim
    Windows’un neden bu kadar kolay hacklenebildiğini merak ediyorum

    • En büyük nedeni hâlâ kimsenin dile getirmemiş olmasına inanmak zor
      Windows, para eden bir hedef; özellikle kurumsal ortamlarda en yaygın dağıtılmış masaüstü işletim sistemi olduğu için onu kırmaya çok fazla zaman ve yatırım harcanıyor
    • Sorun, Windows’un güvenliğin önem kazanmasından önce geliştirilmiş olması
      Gerçekten güvenli bir bilgi işlem platformu oluşturmak için yeterli yatırım yapılmadı
      İdeal bir güvenlik platformu, fdroid gibi herkese açık doğrulanabilir bir altyapıda tekrarlanabilir derlemeler sunmalı, güvenilmeyen tüm uygulamaları sandbox içinde sanallaştırmalı ve en az ayrıcalık modelini uygulamalı
      Şu an güvenlik açısından en kötü durumdayız. CPU’daki ME’den UEFI bileşenlerine, işletim sistemindeki üçüncü taraf sürücülere kadar her ring’de kimliği belirsiz ve muhtemelen yeterince test edilmemiş güvensiz kod çalışıyor
      SeL4 tamamen doğrulanmış bir çekirdeğe sahip ama henüz sanallaştırma yapmıyor
    • Üçüncü taraf çekirdek düzeyi kodun yaygın olması da önemli bir etken
      Windows kötü amaçlı yazılımlarının önemli bir kısmı bir noktada savunmasız bir üçüncü taraf çekirdek sürücüsüne dayanıyor
      Buna karşılık Linux’ta üçüncü taraf çekirdek modülleri nadirdir ve hoş karşılanmaz; macOS’ta ise tamamen yasaktır
    • Benim deneyimime göre sorun, kullanıcının varsayılan olarak yönetici olması
      Ayrıca kullanıcıyı yükseltilmiş yetkilerle herhangi bir şeyi çalıştırmaya ikna etmek çok kolay
    • Sürücü imzası engelleme listesi dosyası DriverSiPolicy.p7b yıllarca güncellenmedi
      2022’de CERT analisti Will Dormann bunun nedenini sorana kadar ele alınmadı
      Şimdi düzenli olarak güncelleniyor ama gerçekten akıl alır gibi değil https://www.bleepingcomputer.com/news/microsoft/microsoft-fi...

  • Bu konuda Microsoft’un pozisyonuna bir ölçüde katılıyorum
    Yönetici bilgisayarda istediği işi yapabilir; bu yeni bir şey değil
    Ciddiyeti artıran ince bir fark var mı bilmiyorum
    Raymond Chen’in bu tür saldırıları özetleyen yazısı da bakmaya değer
    https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...

    • Ben de aynı fikirdeyim
      Birisi zaten sistemdeki rastgele bir DLL’i değiştirebiliyorsa, bu “exploit”in çalışması için gereken ön koşul zaten sağlanmıştır ve o noktada her şey bitmiş sayılır
      Sürücü imzasını atlatabilme yeteneği, endişeler arasında muhtemelen en küçüklerinden biridir

  • Saldırı şüphe uyandıracak kadar basit görünüyor
    Güncelleme sürecini kandırıp bilinen bir güvenlik açığı olan eski bir çekirdek bileşenini kurdurma yöntemi
    Uzman olmasam da Microsoft’un bunu çoktan düşünüp engelleme listesi ya da kullanım dışı bırakma mekanizması gibi bir şeye sahip olması gerektiğini düşünürdüm, merak ediyorum
    Temel meselenin işletim sistemi tasarımı sorunu mu, yoksa bozuk veya kötü hash’leri doğru yere kaydedemeyen bir süreç hatası mı olduğu kritik
    İkincisiyse düzeltmesi çok daha kolaydır ama her zamanki gibi, biraz cilalanmış güvenlik duyurusu sanki ilkini savunuyor gibi

    • Kurumsal kullanıcılar, bir güncelleme yüzünden bir şey bozulursa downgrade yapabilmeleri gerektiğinde ısrar ettiği için buna izin verilmesi gerekiyor olabilir

  • Bir demo varken Microsoft’un buna karşı çıkması inanılır gibi değil
    O Vimeo hesabında başka birçok güvenlik bulgusu da var. Örneğin WhatsApp’ın Python script’i çalıştırdığı bir şey de vardı; gerçek mi dolandırıcılık mı merak ediyorum

  • Microsoft Windows’ta ilk kez sürücü imzası zorunluluğu getirdiğinde [1] herkesin çektiği sıkıntıyı hatırlıyorum
    [2] için derin paket inceleme sürücüsü geliştiriyorduk; ilk bakışta Apple Store uygulama onayından bile daha zahmetli bir süreç gibi görünüyordu ve dokümantasyon hiç net değildi
    Şirketlerin Microsoft’un gerekliliklerini karşılamak için harcadığı kaynaklar düşünüldüğünde, bunun bu şekilde kötüye kullanılmış olması büyük bir geri adım gibi geliyor
    Güvenlik açıkları her zaman olur ama birilerinin bunu daha önce bulmuş olması içimi rahatlatırdı
    Bunu keşfeden Alon Leviev ve SafeBreach’i alkışlamak gerek
    [1] https://www.nektra.com/
    [2] https://www.verizon.com/business/en-nl/products/security/man...

  • “Yönetici olarak kernel kodu çalıştırma elde etmek mümkün” denmesi, sonuçta root kullanıcısının rootkit kurabilmesi gibi sıradan bir mesele
    Buna havalı bir ad vermeyi unutmamak gerek. Ah, araştırmacı zaten Windows Downdate adlı bir araç yayımlamış
    0xF dakikalık şöhret de garanti olduğuna göre iyi iş çıkmış sayılır

    • Her şeyi yapabilen bir root/süper kullanıcı hesabı kavramı yaygın olsa da bu, işletim sistemi tasarım tercihidir
      Kullanıcı hesabı da işletim sistemi içindeki bir nesneden ibarettir ve süper kullanıcı hesabını sınırlasanız bile tüm kullanıcı hesaplarına belirli kuralları dayatan bir işletim sistemi tasarlanabilir
      Örneğin yönetici hesabı ele geçirildiğinde bile TPM gibi belirli sırları korumak ya da yöneticinin yanlışlıkla sistemi önyüklenemez hale getirecek şekilde bozmasını engellemek için meşru nedenler olabilir
      Daha tartışmalı hedeflerden biri de DRM’i zorunlu kılmaktır
      Microsoft’un Windows’ta yapmaya çalıştığı da tam olarak bu. İşletim sistemi, yönetici hesabının kernel’e müdahale etmesini veya rootkit kurmasını engellemeye çalışıyor
      Bu tartışmada, işletim sistemi içindeki yönetici kullanıcı hesabı ile fiziksel/donanımsal erişim yetkisine sahip “yönetici” kişiyi ayırt etmek her zaman önemlidir
    • Burada 15 yazmak daha kolay olurdu; neden 0xF yazıldığını merak ettim
      Yanlış değil ama tuhaf bir tercih olduğu için insan merak ediyor. Sadece stil meselesi miydi acaba

  • Windows kullanmam gerektiğinde, o bilgisayarın zaten ele geçirilmiş olduğunu varsayarım