Microsoft Windows Sistemi Ciddi Açık Analizi

Son zamanlarda, Microsoft'un yayınladığı güvenlik yamanında, kötü niyetli kişilerin istismar ettiği bir Windows çekirdek yetki yükseltme açığı düzeltildi. Bu açık, özellikle erken Windows sistem sürümlerini etkilemekte olup, Windows 11'de tetiklenememektedir. Bu tür açıklar uzun zamandır var, bu makalede mevcut güvenlik önlemlerinin sürekli güçlendirildiği bir ortamda, saldırganların bu tür açıkları nasıl kullanmaya devam ettiğini inceleyeceğiz.

Bu analiz Windows Server 2016 ortamında tamamlandı.

Açık Arka Plan

Bu bir sıfır gün açığıdır, henüz kamuya açık olmayan ve düzeltilmemiş bir sistem açığıdır. Hackerlar, kullanıcıların hiç farkında olmadan sıfır gün açığını kullanarak saldırılar gerçekleştirebilirler ve bu son derece yıkıcıdır.

Bu keşfedilen sıfırıncı gün açığı, Windows sistem çekirdek katmanında bulunmaktadır ve hackerlar bu açık sayesinde Windows'un tam kontrolünü ele geçirebilir. Bu, kullanıcı gizliliğinin ihlaline, sistem çökmesine, veri kaybına, mali kayıplara gibi ciddi sonuçlara yol açabilir. Web3 açısından bakıldığında, kullanıcıların özel anahtarları çalınabilir ve dijital varlıklar transfer riskiyle karşı karşıya kalabilir. Daha geniş bir açıdan, bu açık Web2 altyapısına dayalı tüm Web3 ekosistemini bile etkileyebilir.

Açık Analizi

Yaman kodunu analiz ederken, bir nesnenin referans sayısının birden fazla kez işlenmesi nedeniyle bir sorun olduğunu keşfettik. Eski win32k kaynak kodu yorumlarına bakıldığında, önceki kodun yalnızca pencere nesnesini kilitlediği, ancak pencere nesnesindeki menü nesnesini kilitlemediği anlaşılmaktadır. Bu, menü nesnesinin yanlış bir şekilde referans verilmesine neden olabilir.

Daha fazla analiz, xxxEnableMenuItem() fonksiyonuna geçirilen menülerin genellikle üst fonksiyonda kilitlenmiş olduğunu ortaya koydu. Peki burada hangi menü nesnesini korumalıyız? Araştırmalar sonucunda, xxxEnableMenuItem içindeki MenuItemState fonksiyonunun döndürdüğü menülerin iki olasılığı vardır: pencerenin ana menüsü veya menünün alt menüsü ( hatta alt alt menüsü ).

Açık Kullanımı

Açıkları doğrulamak için, özel bir dört katmanlı menü yapısı oluşturduk ve bazı belirli koşullar belirledik:

1. En alt seviye menü D'nin kimliği sistem menü türü olmalıdır, örneğin menüyü kapat (0xf060)
2. Üst seviye Menü A da sistem menüsü olmalıdır, ancak içindeki 0xf060 menü öğesi silinmelidir.
3. Menü B'deki Menü C referansını silin
4. Menü B'nin varlığı, Menü C'nin serbest bırakılması üzerinde bir etkiye sahip gibi görünüyor.

Bir açık tetiklendiğinde, xxxRedrawTitle kullanıcı katmanına dönerken C ve B menüsünün ilişkisinin kaldırılması, C menüsünün başarıyla serbest bırakılmasını sağlar. Çekirdek içindeki xxxEnableMenuItem fonksiyonu xxxRedrawTitle'a döndüğünde, referans alınan C menüsü nesnesi geçersiz hale gelmiştir.

Açık Kullanım Analizi

Sızdırma planı tasarlarken, iki ana yönü göz önünde bulundurduk:

1. Shellcode yürütme: Önceki CVE-2017-0263 ve CVE-2016-0167 yöntemlerine başvurun. Ancak yüksek sürüm Windows'ta, shellcode yürütme giriş noktası ve SMEP gibi güvenlik mekanizmaları engellerle karşılaşabilir.

2. Token adresini değiştirmek için okuma/yazma ilkelere dayanmak: Bu yöntem oldukça iyi bir genel kullanıma sahiptir. Anahtar, UAF bellek yeniden kullanımı sırasında cbwndextra'yı ilk kez olağanüstü bir değere nasıl kontrol edeceğinizi analiz etmektir.

Açığı iki adımda kullanıma alıyoruz: cbwndextra değerini kontrol etmek ve istikrarlı okuma/yazma ilkelere ulaşmak.

İlk veri yazımı

Sistem hatası, kontrol edilen bellek penceresi nesne verilerinin kullanımında esasen xxxEnableMenuItem fonksiyonunun MNGetPopupFromMenu() ve xxxMNUpdateShownMenu() içinde meydana gelmektedir. Pencere sınıfı WNDClass'ın pencere adı nesnesi, serbest bırakılan menü nesnesi belleğini kullanmaktadır.

Anahtar, herhangi bir şekilde yazılabilen bir adres yapısını bulmaktır, sadece bir bayt bile olsa. Sonunda xxxRedrawWindow fonksiyonundaki çözümü seçtik, HWNDClass'ın cb-extra'sına AND 2 işlemi ile yazdık.

bellek düzeni

Üç ardışık 0x250 baytlık HWND nesnesinin bellek düzenini tasarladık, orta nesneyi serbest bıraktık ve 0x250 baytlık HWNDClass nesnesi ile kapladık. Önceki HWND nesnesinin son verileri xxxRedrawWindow ile kontrol için kullanılırken, sonraki HWND nesnesinin menüsü ve HWNDClass nesnesi nihai okuma/yazma ilkesine hizmet etmektedir.

Pencere nesnesi ile HWNDClass nesnesinin boyutunu eşit tutmaya çalışıyoruz ve sızan çekirdek tanıtıcısı adresi ile nesne dizisinin beklenildiği gibi sıralanıp sıralanmadığını kesin bir şekilde belirliyoruz.

Okuma Yazma İlkeleri

Herhangi bir okuma işlemi için GetMenuBarInfo(), herhangi bir yazma işlemi için SetClassLongPtr() kullanın. TOKEN yazımı dışında, diğer tüm yazım işlemleri birinci pencere nesnesinin sınıf nesnesini kullanarak ofset yazım ile gerçekleştirilir.

Özet

1. Microsoft, win32k ile ilgili çekirdek kodunu Rust ile yeniden yapılandırıyor, gelecekte bu tür güvenlik açıkları yeni sistemlerde önlenebilir.

2. Bu güvenlik açığının istismar süreci oldukça basittir, esasen masaüstü yığın nesne işleyici adresinin sızdırılmasına dayanır. Bu sorunun tamamen çözülmemesi durumunda, eski sistemler hâlâ güvenlik riski taşımaktadır.

3. Bu açığın keşfi, daha kapsamlı bir kod kapsamı testi sayesinde mümkün olmuş olabilir.

4. Açık istismar tespiti için, açık tetikleme fonksiyonu anahtar noktalarına dikkat etmenin yanı sıra, bellek düzeni ve pencere sınıfı ek veri anormal kaydırma okuma/yazma tespiti de dikkate alınmalıdır.