Microsoft 0day Açığı Analizi: Web3 Altyapısına Büyük Tehdit Oluşturabilir

Geçen ayki Microsoft güvenlik yaması, istismar edilen bir win32k yükseltme açığı içeriyordu. Bu açığın yalnızca eski Windows sistemlerinde mevcut olduğu ve Windows 11'de tetiklenemediği görülüyor.

Bu tür açıkların kötüye kullanımı uzun zamandır var. Bu makalede, mevcut yeni hafifletme önlemlerinin sürekli olarak iyileş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 onarılmamış bir açığı ifade eder; kötü niyetli kişiler tarafından fark edilmeden kullanılabilir ve büyük yıkıcılığa sahip olabilir. Bu keşfedilen 0day açığı, Windows sistem düzeyinde yer almakta olup, hackerların bu açık aracılığıyla Windows'un tam kontrolünü elde etmelerine olanak tanımaktadır.

Korsanlar tarafından kontrol edilen sistemler, kişisel bilgilerin sızması, sistem çökmesi, veri kaybı, mali kayıplar, kötü amaçlı yazılımların yerleştirilmesi gibi sonuçlara yol açabilir. Web3 kullanıcıları için, özel anahtarlar çalınabilir, dijital varlıklar aktarılabilir. Daha geniş bir perspektiften bakıldığında, bu açık, Web2 altyapısı üzerinde çalışan tüm Web3 ekosistemini bile etkileyebilir.

Yaman Analizi

Yaman yaman, yaman yaman! Yaman yaman. Yaman yaman! Yaman yaman.

Açık İstismar Kavramsal Kanıtı ( PoC )

xxxEnableMenuItem() menüsünün genellikle üst düzey fonksiyonda kilitlenmiş olduğunu tespit ettik. Daha ileri bir analiz, xxxEnableMenuItem içindeki MenuItemState fonksiyonunun döndürdüğü menünün iki olasılığı olduğunu ortaya koydu: pencerenin ana menüsü veya menüdeki alt menü ( hatta alt alt menü ).

PoC'de, özel bir dört katmanlı menü yapısı oluşturduk ve her seviye menüye belirli özellikler atadık, xxxEnableMenuItem fonksiyonundaki kontroller ve değerlendirmeler aracılığıyla. Ana adımlar arasında bazı menü referans ilişkilerini kaldırmak, xxxRedrawTitle kullanıcı katmanına döndüğünde belirli menü nesnelerini serbest bırakmak gibi işlemler bulunmaktadır.

Açık Kullanımı (Exp) Gerçekleştirme

Genel düşünce

İki ana kullanım yönünü dikkate aldık: shellcode kodunu çalıştırmak ve okuma/yazma ilkelere token adresini değiştirmek. Çeşitli faktörleri göz önünde bulundurarak, ikincisini seçtik.

Tüm exp, iki ana soruya ayrılabilir: UAF açığını kullanarak cbwndextra değerini nasıl kontrol edebiliriz ve cbwndextra değerini kontrol ettikten sonra istikrarlı okuma/yazma işlemlerini nasıl gerçekleştirebiliriz.

ilk veri yazma işlemi gerçekleştirildi

Açık menü nesnelerini işgal etmek için WNDClass içindeki pencere adı nesnesini kullanıyoruz. Anahtar, istediğimiz verilerin yazılabileceği bir adres yapısını bulmaktır.

Sonunda yazma işlemini xxxRedrawWindow fonksiyonundaki bir bayrak AND 2 işlemi ile gerçekleştirmeyi seçtik. Bellek düzenini daha iyi kontrol edebilmek için HWNDClass'ın cb-extra'sını, pencere nesnesinin cb-extra'sı yerine yazdık.

stabil bellek düzeni

En az üç ardışık 0x250 baytlık HWND nesnesinin bellek düzenini tasarladık, ortadakini serbest bıraktık ve 0x250 baytlık HWNDClass nesnesi ile doldurduk. Önceki ve sonraki HWND nesneleri ise parametreleri kontrol etmek ve okuma/yazma ilkeleri aracı olarak kullanılmaktadır.

Başvuru penceresi nesnesinin beklenildiği gibi sıralanıp sıralanmadığını, bellek yığınında sızan çekirdek tanıtıcı adresleri aracılığıyla kesin bir şekilde belirliyoruz.

okuma yazma dilinin değiştirilmesi

Herhangi bir okuma işlemi için GetMenuBarInfo() kullanıyoruz, herhangi bir yazma işlemi için ise SetClassLongPtr() kullanıyoruz. TOKEN'ın yazma işlemi dışındaki diğer yazma işlemleri, ilk pencere nesnesinin sınıf nesnesinin ofsetini kullanarak tamamlanmaktadır.

Özet

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

2. Bu güvenlik açığının istismar süreci nispeten basittir, ana zorluk ilk yazma işlemini nasıl kontrol edeceğinizdir. Açık, hala masaüstü yığın tutucu adresinin sızdırılmasına ciddi şekilde bağımlıdır, bu da eski sistemler için hala bir güvenlik riski oluşturmaktadır.

3. Bu açığın keşfi, daha kapsamlı bir kod kapsamı kontrolünden faydalanmış olabilir.

4. Sömürü tespiti için, yalnızca açıkları tetikleyen fonksiyonların kritik noktalarına odaklanmakla kalmayıp, ayrıca anormal bellek düzenini ve pencere veri okuma/yazma işlemlerini hedefli bir şekilde tespit etmek gerekmektedir.