Microsoft Sistem Düzeyi 0day Açığı Analizi ve Kullanımı

Giriş

Son zamanlarda Microsoft'un güvenlik yaması, hackerlar tarafından istismar edilen bir win32k yükseltme açığını düzeltti. Bu açık, esas olarak eski Windows sistem sürümlerini etkiliyor ve Windows 11 üzerinde geçersiz gibi görünüyor. Bu makalede, bu tür açıkların mevcut yeni koruma önlemlerinin sürekli olarak geliştiği bağlamda, saldırganların nasıl devam edebileceğini derinlemesine analiz edeceğiz. Analiz ortamımız Windows Server 2016.

Açık Arka Plan

0day açığı, kamuya açık olmayan ve düzeltilmemiş güvenlik açıklarını ifade eder, bu finansal piyasadaki T+0 işlem kavramına benzer. Bu tür açıklar kötüye kullanıldığında genellikle büyük zararlara yol açar. Bu kez keşfedilen Windows sistem düzeyindeki 0day açığı, saldırganların sisteme tam kontrol sağlamasına olanak tanımaktadır.

Saldırı altındaki sistemin kontrolü, kişisel bilgilerin sızması, sistem çökmeleri, veri kaybı, mal kaybı, kötü niyetli yazılımların yerleştirilmesi gibi ciddi sonuçlar doğurur. Kripto para kullanıcıları için, özel anahtarların çalınması, dijital varlıkların aktarılması gibi riskler vardır. Daha geniş bir perspektiften bakıldığında, bu açık, Web2 altyapısına dayanan Web3 ekosistemini bile etkileyebilir.

Yaman Analizi

Yaman kodunu analiz ederken, sorun bir nesnenin referans sayısının birden fazla kez işlenmesinde gibi görünüyor. Önceki kaynak kodu yorumlarına bakarak, önceki kodun yalnızca pencere nesnesini kilitlediğini, pencere içindeki menü nesnesini kilitlemediğini bulduk, bu da menü nesnesinin yanlış bir şekilde referans alınmasına neden olabilir.

Açık Doğrulama

Açık bir güvenlik açığı fonksiyonunun bağlamını analiz ettiğimizde, genellikle xxxEnableMenuItem() ile geçirilen menünün üst fonksiyonda kilitlendiğini görüyoruz. Peki, hangi menü nesnesini korumalıyız? xxxEnableMenuItem içindeki menü nesnesinin işlenmesini daha ileri analiz ettiğimizde, MenuItemState fonksiyonunun döndürebileceği iki olasılık olduğunu görüyoruz: ana pencere menüsü veya alt menü(, alt alt menü dahil).

Açıkları doğrulamak için özel bir dört katmanlı menü yapısı oluşturduk ve xxxEnableMenuItem fonksiyonundaki kontrolleri aşmak için bazı belirli koşullar ayarladık. xxxRedrawTitle kullanıcı katmanına döndüğünde, menü C ve B'nin referans ilişkisini kaldırdık ve menü C'yi başarıyla serbest bıraktık. Son olarak, çekirdek içindeki xxxEnableMenuItem fonksiyonu xxxRedrawTitle fonksiyonuna döndüğünde, referans verilen menü C nesnesi geçersiz hale gelmiştir.

Açık Kullanımı

Genel düşünce

Bir exploit planı belirlemeden önce, genellikle uygulanabilir olmayan planlar üzerinde zaman kaybetmemek için bazı teorik analizler yaparız. Bu açık kullanımı, iki ana yönü dikkate almıştır:

1. Shellcode'u çalıştırma: Önceki benzer açıkları referans alarak, ancak yüksek sürüm Windows'larda bazı zor çözümlerle karşılaşabilir.

2. Token'ı değiştirmek için okuma/yazma ilkelere başvurmak: Son iki yılda referans alınabilecek açık örnekler hâlâ mevcut. UAF belleği yeniden kullanıldığında cbwndextra'nın ilk kez büyük bir değere kontrol edilmesi gerektiğine odaklanmalıyız.

Bu nedenle, tüm faydalanma sürecini iki kısma ayırıyoruz: UAF açığını kullanarak cbwndextra değerini nasıl kontrol edeceğimiz ve bu değeri kontrol ettikten sonra kararlı okuma/yazma primitiflerini nasıl gerçekleştireceğimiz.

İlk veri yazma

Bir güvenlik açığı tetiklendiğinde, sistem hemen çökmez. Kontrol edilen bellekteki pencere nesnesi verilerinin yanlış kullanımı esas olarak xxxEnableMenuItem fonksiyonunun MNGetPopupFromMenu() ve xxxMNUpdateShownMenu() içinde gerçekleşir.

Kullanımda olmayan menü nesnesinin belleğini kaplamak için WNDClass adında bir pencere sınıfındaki pencere adı nesnesini kullanıyoruz. Anahtar, oluşturduğumuz adres yapısında veri yazılabilecek bir yer bulmaktır, hatta bu sadece bir bayt bile olsa.

Sonunda xxxRedrawWindow fonksiyonunda iki geçerli çözüm bulduk. Bazı sınırlayıcı faktörleri göz önünde bulundurarak, bayrak AND 2 işlemi kullanan çözümü seçtik ve HWNDClass'ın cb-extra'sını yazmaya karar verdik, pencere nesnesinin cb-extra'sı yerine.

Stabil Bellek Düzeni

En az üç ardışık 0x250 baytlık HWND nesnesinin bellek düzenini tasarladık. Ara nesneleri serbest bırakın, 0x250 baytlık HWNDClass nesnesi ile doldurun. Önceki HWND nesnesinin son verileri, xxxRedrawWindow bayrağı ile kontrol edilmek üzere kullanılır, sonraki HWND nesnesinin menü nesnesi ve HWNDClass nesnesi nihai okuma/yazma ilkel ortamı olarak kullanılır.

Pencere nesneleri ile HWNDClass nesnelerinin boyutlarının eşit olmasını sağlamaya çalışıyoruz ve pencere nesnesinin genişletilmiş verisinin yeterince büyük olmasını garanti ediyoruz. Bellekte sızdırılan çekirdek tanıtıcı adresleri ile, talep edilen pencere nesnelerinin beklenen sıraya göre sıralanıp sıralanmadığını kesin bir şekilde belirleyebiliriz.

okuyup yazma ilkesinin uygulanması

Herhangi bir okuma işlemi için GetMenuBarInfo() kullanılır. Herhangi bir yazma işlemi için SetClassLongPtr() kullanılır. TOKEN'ın yer değiştirme yazma işlemi dışında, diğer tüm yazma işlemleri, ilk pencere nesnesinin sınıf nesnesini kullanarak ofset ile gerçekleştirilir.

Özet

1. win32k açığı uzun zamandır var, ancak Microsoft ilgili çekirdek kodunu Rust ile yeniden yapılandırıyor, gelecekteki yeni sistem bu tür açıkların önüne geçebilir.

2. Bu açık istismar süreci zor sayılmaz, asıl zorluk ilk yazımın nasıl kontrol edileceğidir. Açık, hala masaüstü yığın tanıtıcı adres sızıntısına ciddi şekilde bağımlıdır, bu eski sistemler için hala bir güvenlik açığıdır.

3. Bu açığın keşfi, daha gelişmiş bir kod kapsama testi sayesinde mümkün olmuş olabilir. Sistem API'si, hedef fonksiyonun yürütme yolunda en derin açma noktasına ulaştığında ve pencere nesnesi çok katmanlı bir referans durumunda olduğunda, fuzz testi bu açığı tespit edebilir.

4. Açık istismar tespiti için, açıkları tetikleyen fonksiyonların anahtar noktalarına odaklanmanın yanı sıra, anormal bellek düzenine ve pencere veya pencere sınıfı ek verilerinin sıra dışı kaydırma okuma/yazma işlemlerine de dikkat edilmelidir; bu, benzer türdeki açıkların keşfine yardımcı olabilir.