Microsoft 0day Açığı Analizi: Web3 Altyapı Güvenliğini Tehdit Ediyor

Geçen ay Microsoft'un güvenlik yamanında, kötüye kullanılabilir bir win32k yükseltme açığı içeren bir güncelleme yayımlandı. Bu açığın yalnızca eski sistem sürümlerinde var olduğu ve Windows 11'de tetiklenemediği görülüyor. Bu tür açıkların kötüye kullanımı uzun süredir devam ediyor. Bu makalede, mevcut yeni önleme önlemlerinin sürekli geliştiği bir bağlamda, saldırganların bu açığı nasıl kullanmaya devam edebileceğini analiz edeceğiz. Analiz sürecini Windows Server 2016 ortamında tamamladık.

0day açığı, ifşa edilmemiş ve yamanmamış bir güvenlik açığıdır; hacker'lar tarafından fark edilmeden kötüye kullanılabilir ve genellikle büyük yıkıma neden olabilir. Bu sefer keşfedilen 0day açığı, Windows sistem katmanında bulunmaktadır; hacker'lar bu açığı kullanarak Windows'un tam kontrolünü ele geçirebilir. Kontrol altına alındıktan sonra kişisel bilgilerin çalınması, sistem çökmesi, veri kaybı, mali kayıplar, kötü amaçlı yazılım yerleştirilmesi gibi sonuçlar doğurabilir. Küçük ölçekli bir durum, özel anahtarların çalınmasına ve dijital varlıkların aktarılmasına neden olabilir; büyük ölçekli bir durum ise Web2 altyapısı üzerinde çalışan tüm Web3 ekosistemini tehdit edebilir.

Yaman analizi, bunun yalnızca bir nesne referans sayısının aşırı işlenmesiyle ilgili bir sorun olduğunu gösteriyor. Ancak eski kaynak kodu yorumlarına baktığımızda, önceki kodun yalnızca pencere nesnesini kilitlediği, pencere nesnesindeki menü nesnesini kilitlemediği görülüyor. Bu, menü nesnesinin yanlış bir şekilde referans verilmesine neden olabilir.

Açık olan fonksiyon bağlamını analiz ettiğimizde, xxxEnableMenuItem() ile geçirilen menünün genellikle üst düzey fonksiyonda kilitlendiğini görüyoruz, peki burada hangi menü nesnesini korumalıyız? Daha derin bir analiz, xxxEnableMenuItem içinde dönen menünün iki olasılığı olduğunu ortaya koyuyor: pencere ana menüsü veya menünün alt menüsü ( hatta alt alt menüsü ).

POC oluşturmak için özel bir dört katmanlı menü yapısı tasarladık ve her menüyü fonksiyonlar aracılığıyla tespit etmek için özel ayarlar yaptık. xxxRedrawTitle kullanıcı katmanına döndüğünde, menü C ve menü B'nin referans ilişkisini kaldırdık ve menü C'yi başarıyla serbest bıraktık. Böylece xxxEnableMenuItem fonksiyonunun geri dönüş noktasında, referans alınan menü C nesnesi zaten geçersiz hale gelmişti.

EXP gerçekleştirme için iki ana yönü ele aldık: shellcode kodunu yürütmek ve okuma/yazma primitiflerini kullanarak token adresini değiştirmek. Yüksek sürüm Windows'un güvenlik mekanizmalarını göz önünde bulundurarak, ikincisini seçtik. Tüm istismar süreci iki kısma ayrılabilir: UAF açığını kullanarak cbwndextra değerini nasıl kontrol edeceğimiz ve kararlı okuma/yazma primitiflerini nasıl oluşturacağımız.

Özenle tasarlanmış bellek düzeni aracılığıyla, pencere sınıfı pencere adı nesnelerinin menü nesnelerini işgal edip serbest bırakmasını sağladık ve xxxRedrawWindow fonksiyonunda veri yazma fırsatını bulduk. Stabil bir bellek düzeni sağlamak için, ardışık üç HWND nesnesinin yapısını tasarladık ve bellek sızıntısı olan çekirdek tanıtıcı adreslerini kullanarak nesne sıralama düzenini hassas bir şekilde belirledik.

Okuma ve yazma işlemlerinde, herhangi bir okuma gerçekleştirmek için GetMenuBarInfo()'i, herhangi bir yazma gerçekleştirmek için SetClassLongPtr()'i kullanıyoruz. TOKEN'in yazma işleminin ikinci pencerenin sınıf nesnesine bağımlı olmasının dışında, diğer tüm yazma işlemleri, ilk pencere nesnesinin sınıf nesnesini kaydırma kullanarak gerçekleştirir.

Genel olarak, win32k açığının uzun bir geçmişi olmasına rağmen, Microsoft bu kısmın çekirdek kodunu Rust ile yeniden yapılandırmayı Windows 11 önizleme sürümünde denemiştir; gelecekte benzer açıkların ortadan kaldırılması mümkün olabilir. Bu açık istismar süreci nispeten basittir, temel zorluk ilk yazma işlemini nasıl kontrol edeceğinizdir. Açığın keşfi, daha kapsamlı bir kod kapsama testi gerektirebilir. Açık tespiti açısından, tetikleme fonksiyonlarının kritik noktalarına odaklanmanın yanı sıra, sıra dışı bellek düzenlemeleri ve veri kaydırma okuma/yazma tespiti de benzer açıkların keşfi için olası bir yol olabilir.