Microsoft Windows Sistem 0day Açığı Analizi ve Kullanımı
Son günlerde, Microsoft'un yayınladığı güvenlik yaması, kötüye kullanılan bir win32k yükseltme açığını düzeltmiştir. Bu açık yalnızca daha eski Windows sistem sürümlerinde bulunmaktadır ve Windows 11'de tetiklenemez. Bu makalede, mevcut güvenlik koruma önlemleri sürekli olarak geliştirildiği bir bağlamda, saldırganların bu tür açıkları nasıl kullanmaya devam ettiğini analiz edeceğiz.
Açık Arka Plan
0day açığı, henüz kamuya açıklanmamış ve düzeltilmemiş güvenlik açığını ifade eder, finansal piyasalardaki T+0 işlem kavramına benzer. Bu tür açıklar keşfedildiğinde, fark edilmeden kötüye kullanılabilir ve büyük zararlara yol açabilir.
Bu keşfedilen Windows sistem 0day açığı, saldırganların sisteme tam kontrol sağlamasına olanak tanıyor. Bu, kişisel bilgilerin sızdırılması, sistem çökmesi, veri kaybı, mal kaybı gibi ciddi sonuçlara yol açabilir. Web3 perspektifinden bakıldığında, özel anahtarların çalınmasına, dijital varlıkların transfer edilmesine ve hatta Web2 altyapısına dayanan Web3 ekosisteminin tamamını etkilemesine neden olabilir.
Yaman Analizi
Yaman yaman, nesne referans sayısının birden çok kez işlenmesiyle ilgili bir sorun olduğu tespit edildi. Daha önceki kaynak kodu yorumlarına bakıldığında, eski kodun yalnızca pencere nesnesini kilitlediği ve pencerenin içindeki menü nesnesini kilitlemediği anlaşılmakta, bu da menü nesnesinin yanlış bir şekilde referans alınmasına neden olabilir.
Açık Yeniden Üretimi
Açık işlev bağlamını analiz ederek, xxxEnableMenuItem() ile iletilen menünün genellikle üst işlevde kilitlendiğini keşfettik. Daha fazla analiz, MenuItemState işlevinin döndürdüğü menünün ana pencere menüsü veya alt menü ya da alt alt menü olabileceğini ortaya koydu.
Bir açığı tetiklemek için özel bir dört katmanlı menü yapısı oluşturuldu ve aşağıdaki özellikler ayarlandı:
En alt seviye Menü D'nin ID'si sistem menü türü olmalıdır.
Üst düzey menü A da sistem menüsü olmalıdır, ancak ilgili sistem menü türü silinmelidir.
Menü B'deki Menü C referansını sil
Menü B'nin varlığı, Menü C'nin serbest bırakılmasına yardımcı gibi görünüyor.
xxxRedrawTitle kullanıcı katmanını döndürdüğünde, Menü C ve B'nin referans ilişkisini kaldırın ve Menü C'yi serbest bırakın. Böylece xxxEnableMenuItem fonksiyonu geri döndüğünde, referans verilen Menü C nesnesi geçersiz hale gelmiştir.
Açık Kullanımı
Açıkların istismarında iki ana yön dikkate alınır:
Shellcode kodunu çalıştırma: Erken dönem CVE-2017-0263 gibi açıkları referans alarak, ancak yüksek sürüm Windows'ta giriş noktası ve SMEP gibi güvenlik mekanizmalarıyla sorunlarla karşılaşılabilir.
Token adresini değiştirmek için okuma/yazma ilkelere yararlanma: Son yıllarda referans alabileceğiniz birçok kamuya açık örnek mevcut, masaüstü yığın bellek düzeni ve okuma/yazma ilkelere genel geçerliliğe sahiptir. Anahtar, UAF bellek yeniden kullanımında cbwndextra'nın ilk kontrolünün nasıl yapılacağını analiz etmektir.
Bu sefer ikinci seçeneği kullanarak süreci iki adıma ayırıyoruz:
UAF açığını kullanarak cbwndextra değerini kontrol etme
cbwndextra kontrolü ile kararlı okuma/yazma ilkelere ulaşma
İlk veri yazımı
Açıklar tetiklendiğinde, sistem MNGetPopupFromMenu() ve xxxMNUpdateShownMenu() içinde kontrol edilen pencere nesnesi verilerini yanlış kullanabilir. Pencere sınıfı WNDClass içindeki pencere adı nesnesi serbest bırakılan menü nesnesini işgal eder.
Anahtar, bizim inşa edebileceğimiz adres yapısında herhangi bir veri yazılabilecek bir konum bulmaktır, hatta sadece bir bayt bile olsa. Sonunda xxxRedrawWindow fonksiyonundaki seçeneği tercih ettik, önceki nesnenin bellek verilerini kontrol etmek için bellek düzenini kullanarak fonksiyon içindeki nesne işaretçisini belirlemek amacıyla.
stabil bellek düzeni
En az üç ardışık 0x250 baytlık HWND nesnesi tasarlayın, ortadaki birini serbest bırakın ve HWNDClass nesnesi ile kaplayın. Önceki HWND nesnesinin sonundaki veriler, xxxRedrawWindow'daki bayraklarla kontrol etmek için kullanılır, sonraki HWND nesnesinin menü nesnesi ve HWNDClass nesnesi son okuma/yazma ilkel aracı olarak kullanılır.
Talep edilen pencere nesnelerinin beklenen sıraya göre sıralanıp sıralanmadığını kesin olarak belirlemek için, yığın bellekte sızan çekirdek tanımlayıcı adresini kullanın.
Okuma Yazma Primi
Herhangi bir okuma işlemi için GetMenuBarInfo(), herhangi bir yazma işlemi için SetClassLongPtr() kullanılır. TOKEN değişiminin dışındaki diğer yazma işlemleri, ilk pencere nesnesinin sınıf nesnesini kullanarak ofset ile yazılır.
Özet
win32k açığı uzun bir geçmişe sahiptir, ancak Microsoft ilgili kodu Rust ile yeniden yapılandırmaya çalışıyor, gelecekteki yeni sistemlerde bu tür açıkların ortadan kaldırılması mümkün olabilir.
Bu güvenlik açığı istismar süreci görece basittir, asıl zorluk ilk yazma işlemini nasıl kontrol edeceğimizdir. Masaüstü yığın işleme tutamağı adresinin sızdırılmasına ciddi şekilde bağımlıdır, bu da hala eski sistemlerin güvenlik açığıdır.
Bu açığın keşfi, daha kapsamlı bir kod kapsama testi sayesinde mümkün olmuş olabilir.
Açık istismar tespitinde, tetikleme fonksiyonu anahtar noktalarına odaklanmanın yanı sıra, anormal bellek düzeni ve pencere veri kaydırma okuma/yazma işlemlerine de odaklanılmalıdır.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
6 Likes
Reward
6
4
Share
Comment
0/400
ChainSauceMaster
· 21h ago
Eski win ne oldu? Her gün bir açık var.
View OriginalReply0
FloorPriceWatcher
· 21h ago
win11 bir tehlikeyi atlattı
View OriginalReply0
MEVSandwichVictim
· 21h ago
Açıklar bol, kim oynarsa onu insanları enayi yerine koymak.
Microsoft Windows'un erken sürümlerindeki 0day açığı analizi: Yetki yükseltmeden faydalanma sürecine kadar
Microsoft Windows Sistem 0day Açığı Analizi ve Kullanımı
Son günlerde, Microsoft'un yayınladığı güvenlik yaması, kötüye kullanılan bir win32k yükseltme açığını düzeltmiştir. Bu açık yalnızca daha eski Windows sistem sürümlerinde bulunmaktadır ve Windows 11'de tetiklenemez. Bu makalede, mevcut güvenlik koruma önlemleri sürekli olarak geliştirildiği bir bağlamda, saldırganların bu tür açıkları nasıl kullanmaya devam ettiğini analiz edeceğiz.
Açık Arka Plan
0day açığı, henüz kamuya açıklanmamış ve düzeltilmemiş güvenlik açığını ifade eder, finansal piyasalardaki T+0 işlem kavramına benzer. Bu tür açıklar keşfedildiğinde, fark edilmeden kötüye kullanılabilir ve büyük zararlara yol açabilir.
Bu keşfedilen Windows sistem 0day açığı, saldırganların sisteme tam kontrol sağlamasına olanak tanıyor. Bu, kişisel bilgilerin sızdırılması, sistem çökmesi, veri kaybı, mal kaybı gibi ciddi sonuçlara yol açabilir. Web3 perspektifinden bakıldığında, özel anahtarların çalınmasına, dijital varlıkların transfer edilmesine ve hatta Web2 altyapısına dayanan Web3 ekosisteminin tamamını etkilemesine neden olabilir.
Yaman Analizi
Yaman yaman, nesne referans sayısının birden çok kez işlenmesiyle ilgili bir sorun olduğu tespit edildi. Daha önceki kaynak kodu yorumlarına bakıldığında, eski kodun yalnızca pencere nesnesini kilitlediği ve pencerenin içindeki menü nesnesini kilitlemediği anlaşılmakta, bu da menü nesnesinin yanlış bir şekilde referans alınmasına neden olabilir.
Açık Yeniden Üretimi
Açık işlev bağlamını analiz ederek, xxxEnableMenuItem() ile iletilen menünün genellikle üst işlevde kilitlendiğini keşfettik. Daha fazla analiz, MenuItemState işlevinin döndürdüğü menünün ana pencere menüsü veya alt menü ya da alt alt menü olabileceğini ortaya koydu.
Bir açığı tetiklemek için özel bir dört katmanlı menü yapısı oluşturuldu ve aşağıdaki özellikler ayarlandı:
xxxRedrawTitle kullanıcı katmanını döndürdüğünde, Menü C ve B'nin referans ilişkisini kaldırın ve Menü C'yi serbest bırakın. Böylece xxxEnableMenuItem fonksiyonu geri döndüğünde, referans verilen Menü C nesnesi geçersiz hale gelmiştir.
Açık Kullanımı
Açıkların istismarında iki ana yön dikkate alınır:
Shellcode kodunu çalıştırma: Erken dönem CVE-2017-0263 gibi açıkları referans alarak, ancak yüksek sürüm Windows'ta giriş noktası ve SMEP gibi güvenlik mekanizmalarıyla sorunlarla karşılaşılabilir.
Token adresini değiştirmek için okuma/yazma ilkelere yararlanma: Son yıllarda referans alabileceğiniz birçok kamuya açık örnek mevcut, masaüstü yığın bellek düzeni ve okuma/yazma ilkelere genel geçerliliğe sahiptir. Anahtar, UAF bellek yeniden kullanımında cbwndextra'nın ilk kontrolünün nasıl yapılacağını analiz etmektir.
Bu sefer ikinci seçeneği kullanarak süreci iki adıma ayırıyoruz:
İlk veri yazımı
Açıklar tetiklendiğinde, sistem MNGetPopupFromMenu() ve xxxMNUpdateShownMenu() içinde kontrol edilen pencere nesnesi verilerini yanlış kullanabilir. Pencere sınıfı WNDClass içindeki pencere adı nesnesi serbest bırakılan menü nesnesini işgal eder.
Anahtar, bizim inşa edebileceğimiz adres yapısında herhangi bir veri yazılabilecek bir konum bulmaktır, hatta sadece bir bayt bile olsa. Sonunda xxxRedrawWindow fonksiyonundaki seçeneği tercih ettik, önceki nesnenin bellek verilerini kontrol etmek için bellek düzenini kullanarak fonksiyon içindeki nesne işaretçisini belirlemek amacıyla.
stabil bellek düzeni
En az üç ardışık 0x250 baytlık HWND nesnesi tasarlayın, ortadaki birini serbest bırakın ve HWNDClass nesnesi ile kaplayın. Önceki HWND nesnesinin sonundaki veriler, xxxRedrawWindow'daki bayraklarla kontrol etmek için kullanılır, sonraki HWND nesnesinin menü nesnesi ve HWNDClass nesnesi son okuma/yazma ilkel aracı olarak kullanılır.
Talep edilen pencere nesnelerinin beklenen sıraya göre sıralanıp sıralanmadığını kesin olarak belirlemek için, yığın bellekte sızan çekirdek tanımlayıcı adresini kullanın.
Okuma Yazma Primi
Herhangi bir okuma işlemi için GetMenuBarInfo(), herhangi bir yazma işlemi için SetClassLongPtr() kullanılır. TOKEN değişiminin dışındaki diğer yazma işlemleri, ilk pencere nesnesinin sınıf nesnesini kullanarak ofset ile yazılır.
Özet
win32k açığı uzun bir geçmişe sahiptir, ancak Microsoft ilgili kodu Rust ile yeniden yapılandırmaya çalışıyor, gelecekteki yeni sistemlerde bu tür açıkların ortadan kaldırılması mümkün olabilir.
Bu güvenlik açığı istismar süreci görece basittir, asıl zorluk ilk yazma işlemini nasıl kontrol edeceğimizdir. Masaüstü yığın işleme tutamağı adresinin sızdırılmasına ciddi şekilde bağımlıdır, bu da hala eski sistemlerin güvenlik açığıdır.
Bu açığın keşfi, daha kapsamlı bir kod kapsama testi sayesinde mümkün olmuş olabilir.
Açık istismar tespitinde, tetikleme fonksiyonu anahtar noktalarına odaklanmanın yanı sıra, anormal bellek düzeni ve pencere veri kaydırma okuma/yazma işlemlerine de odaklanılmalıdır.