Microsoft Windows Sistem Sıfır Gün Açığı Analizi: Web3 Ekosisteminde Önemli Etkilere Neden Olabilir
Geçen ay Microsoft'un güvenlik güncellemeleri, kötü niyetli bir şekilde kullanılan bir Windows çekirdek yükseltme açığını düzeltti. Bu açık, daha eski Windows sistemlerini özellikle etkiliyor, Windows 11'in etkilenmediği görünmektedir. Bu makalede, mevcut güvenlik önlemlerinin sürekli güçlendiği bir bağlamda, saldırganların bu tür açıkları nasıl kullanmaya devam edebileceğini analiz edeceğiz.
Windows Server 2016 ortamında tüm analiz çalışmalarını tamamladık.
Sıfırıncı gün açığı, henüz keşfedilmemiş ve düzeltilmemiş sistem açıklarını ifade eder ve finansal piyasalardaki T+0 işlem kavramına benzer. Sıfırıncı gün açığı kötüye kullanıldığında genellikle büyük zararlara yol açar. Bu sefer keşfedilen Windows sistem sıfırıncı gün açığı, saldırganların sistemi tamamen kontrol etmesine olanak tanır.
Saldırıya uğrayan sistemlerin kontrol edilmesi ciddi sonuçlar doğurur; bunlar arasında ancak bunlarla sınırlı olmamak üzere kişisel gizliliğin ihlali, sistem çökmesi, veri kaybı, mal kaybı ve kötü amaçlı yazılımların yerleştirilmesi yer alır. Bireysel kullanıcılar için bu, kripto para özel anahtarlarının çalınması ve dijital varlıkların aktarılmasıyla sonuçlanabilir; daha geniş bir çerçevede, bu açık Web2 altyapısına dayanan Web3 ekosistemini bile etkileyebilir.
Yaman Analizi
Yamanın analizi sırasında, sorunun yalnızca bir nesnenin referans sayısının bir kez daha işlenmiş gibi göründüğünü keşfettik. Win32k daha eski bir kod olduğu için, daha önceki kod yorumlarını bulabiliriz, bu yorumlar önceki kodun yalnızca pencere nesnesini kilitlediğini, pencere nesnesindeki menü nesnesini kilitlemediğini gösteriyor. Bu, menü nesnesinin yanlış bir şekilde referans alınmasına neden olabilir.
Açık Kullanım Kavram Kanıtı ( PoC ) Uygulaması
Açıklar fonksiyon bağlamını analiz ettiğimizde, xxxEnableMenuItem() ile geçirilen menünün genellikle üst fonksiyon içinde kilitlendiğini görüyoruz, peki burada hangi menü nesnesini korumaya çalışıyoruz?
xxxEnableMenuItem içindeki menü nesnesinin işleme sürecini daha ayrıntılı analiz ettiğimizde, MenuItemState fonksiyonunun döndürdüğü menünün iki olasılığı olduğunu keşfediyoruz: pencerenin ana menüsü veya menünün alt menüsü ( hatta alt alt menüsü ).
PoC'de, özel bir dört katmanlı menü yapısı oluşturduk, komşu menüler arasında ebeveyn-çocuk ilişkisi vardır. Bu menülerin xxxEnableMenuItem fonksiyonundaki tespit ve değerlendirme ile belirli özellikleri vardır.
xxxRedrawTitle kullanıcı katmanına geri döndüğünde, Menü C ve Menü B'nin referans ilişkisini sildik ve Menü C'yi başarıyla serbest bıraktık. Sonunda, çekirdekteki xxxEnableMenuItem fonksiyonu xxxRedrawTitle fonksiyonuna geri döndüğünde, referans verilen Menü C nesnesi zaten geçersizdir.
Açık Kullanımı (Açık )gerçekleştirme
Bir fikir kullanmadan önce, genellikle uygulanabilir olmayan bir çözüm üzerinde zaman kaybetmemek için bazı teorik ön değerlendirmeler yaparız. Bu güvenlik açığı istismarında iki ana yön dikkate alınmıştır:
Shellcode kodunu çalıştırma: Önceki CVE-2017-0263 ve CVE-2016-0167'ye bakın. Ancak yüksek sürüm Windows'larda, bu yöntem bazı zorlayıcı sorunlarla karşılaşabilir.
Token adresini değiştirmek için okuma-yazma primitiflerini kullanmak: Son yıllarda referans alabileceğimiz kamuya açık yöntemler bulunmaktadır. Masaüstü yığın bellek düzeni ve okuma-yazma primitifleri uzun süre genel geçerlik taşımaktadır. Öncelikle UAF belleği yeniden kullanılırken cbwndextra'yı ilk kontrol etmenin nasıl yapılacağını analiz etmemiz gerekiyor.
Tüm fayda sağlama sürecini iki soruya ayırıyoruz: UAF açığını kullanarak cbwndextra değerini nasıl kontrol edeceğiz ve cbwndextra değerini kontrol ettikten sonra istikrarlı bir okuma/yazma ilkesini nasıl gerçekleştireceğiz.
Sonunda, xxxRedrawWindow fonksiyonunda HWNDClass'ın cb-extra'sına yazmak için bayrakların AND 2 işlemi ile kullanmaya karar verdik. Bunun nedeni, HWNDClass'ın cb-extra'sının küçük bir kaydırmaya sahip olmasıdır; bu sayede bir önceki nesnenin bellek verilerini kontrol etmek için bellek düzenini kullanabiliriz ve xxxRedrawWindow fonksiyonunda nesne bayrağının değerlendirilmesiyle bunu gerçekleştirebiliriz.
Stabil bir bellek düzeni sağlamak için en az üç ardışık 0x250 baytlık HWND nesnesi tasarladık. Ara nesneleri serbest bıraktıktan sonra, bu konumu 0x250 baytlık HWNDClass nesnesi ile dolduruyoruz. Önceki HWND nesnesinin son verileri, xxxRedrawWindow bayrağıyla kontrol için kullanılırken, sonraki HWND nesnesinin menü nesnesi ve HWNDClass nesnesi nihai okuma/yazma işlemleri için bir aracı olarak kullanılır.
Pencere nesnesi ile HWNDClass nesnesinin boyutunu tutmaya çalışıyoruz ve pencere nesnesinin genişletilmiş verilerinin yeterince büyük olduğundan emin oluyoruz. Bellekte sızan çekirdek tanıtıcı adresi ile, talep edilen pencere nesnesinin beklenen sırayla sıralanıp sıralanmadığını kesin olarak belirleyebiliriz.
Okuma ve yazma işlemleri açısından, herhangi bir okuma işlemi gerçekleştirmek için GetMenuBarInfo() kullanıyoruz, herhangi bir yazma işlemi için ise SetClassLongPtr() kullanıyoruz. TOKEN'ın yazma işlemini ikinci pencerenin class nesnesine değiştirmek dışında, diğer tüm yazma işlemleri ilk pencere nesnesinin class nesnesini kaydırma ile gerçekleştiriyor.
Özet
win32k durumu: Microsoft, Windows 11 önizleme sürümündeki ilgili çekirdek kodunu Rust ile yeniden yapılandırmaya çalışıyor, gelecekteki yeni sistem bu tür açıkları ortadan kaldırabilir.
Açık istismar süreci nispeten basittir: İlk yazmanın nasıl kontrol edileceği dışında, temel olarak yeni istismar teknikleri kullanmaya gerek yoktur. Bu tür açıklar, masaüstü yığın işleme adresinin sızdırılmasına ciddi şekilde bağımlıdır.
Açık Bulma: Daha kapsamlı bir kod kapsama testi gerektirdiği tahmin edilmektedir. Sistem API'si hedef fonksiyon yürütme yolundaki en derin açık noktaya ulaştığında ve pencere nesnesi çok katmanlı bir referans durumunda olduğunda, bu açık bulanık test ile keşfedilebilir.
Diğer bulma yolları: Açık tetikleme işlevi anahtar noktalarının tespiti dışında, nadir görülen bellek düzenleri ve pencere veya pencere sınıfı ek veri anormal kaydırma okuma/yazma tespitinin de benzer açıkları keşfetmenin yollarından biri olabileceği düşünülebilir.
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.
12 Likes
Reward
12
2
Share
Comment
0/400
AltcoinHunter
· 19h ago
Görmek ama söylememek, kripto dünyası eski enayiler.
Windows sıfırıncı gün açığı analizi: Web3 ekosistemi büyük ölçüde etkilenebilir
Microsoft Windows Sistem Sıfır Gün Açığı Analizi: Web3 Ekosisteminde Önemli Etkilere Neden Olabilir
Geçen ay Microsoft'un güvenlik güncellemeleri, kötü niyetli bir şekilde kullanılan bir Windows çekirdek yükseltme açığını düzeltti. Bu açık, daha eski Windows sistemlerini özellikle etkiliyor, Windows 11'in etkilenmediği görünmektedir. Bu makalede, mevcut güvenlik önlemlerinin sürekli güçlendiği bir bağlamda, saldırganların bu tür açıkları nasıl kullanmaya devam edebileceğini analiz edeceğiz.
Windows Server 2016 ortamında tüm analiz çalışmalarını tamamladık.
Sıfırıncı gün açığı, henüz keşfedilmemiş ve düzeltilmemiş sistem açıklarını ifade eder ve finansal piyasalardaki T+0 işlem kavramına benzer. Sıfırıncı gün açığı kötüye kullanıldığında genellikle büyük zararlara yol açar. Bu sefer keşfedilen Windows sistem sıfırıncı gün açığı, saldırganların sistemi tamamen kontrol etmesine olanak tanır.
Saldırıya uğrayan sistemlerin kontrol edilmesi ciddi sonuçlar doğurur; bunlar arasında ancak bunlarla sınırlı olmamak üzere kişisel gizliliğin ihlali, sistem çökmesi, veri kaybı, mal kaybı ve kötü amaçlı yazılımların yerleştirilmesi yer alır. Bireysel kullanıcılar için bu, kripto para özel anahtarlarının çalınması ve dijital varlıkların aktarılmasıyla sonuçlanabilir; daha geniş bir çerçevede, bu açık Web2 altyapısına dayanan Web3 ekosistemini bile etkileyebilir.
Yaman Analizi
Yamanın analizi sırasında, sorunun yalnızca bir nesnenin referans sayısının bir kez daha işlenmiş gibi göründüğünü keşfettik. Win32k daha eski bir kod olduğu için, daha önceki kod yorumlarını bulabiliriz, bu yorumlar önceki kodun yalnızca pencere nesnesini kilitlediğini, pencere nesnesindeki menü nesnesini kilitlemediğini gösteriyor. Bu, menü nesnesinin yanlış bir şekilde referans alınmasına neden olabilir.
Açık Kullanım Kavram Kanıtı ( PoC ) Uygulaması
Açıklar fonksiyon bağlamını analiz ettiğimizde, xxxEnableMenuItem() ile geçirilen menünün genellikle üst fonksiyon içinde kilitlendiğini görüyoruz, peki burada hangi menü nesnesini korumaya çalışıyoruz?
xxxEnableMenuItem içindeki menü nesnesinin işleme sürecini daha ayrıntılı analiz ettiğimizde, MenuItemState fonksiyonunun döndürdüğü menünün iki olasılığı olduğunu keşfediyoruz: pencerenin ana menüsü veya menünün alt menüsü ( hatta alt alt menüsü ).
PoC'de, özel bir dört katmanlı menü yapısı oluşturduk, komşu menüler arasında ebeveyn-çocuk ilişkisi vardır. Bu menülerin xxxEnableMenuItem fonksiyonundaki tespit ve değerlendirme ile belirli özellikleri vardır.
xxxRedrawTitle kullanıcı katmanına geri döndüğünde, Menü C ve Menü B'nin referans ilişkisini sildik ve Menü C'yi başarıyla serbest bıraktık. Sonunda, çekirdekteki xxxEnableMenuItem fonksiyonu xxxRedrawTitle fonksiyonuna geri döndüğünde, referans verilen Menü C nesnesi zaten geçersizdir.
Açık Kullanımı (Açık )gerçekleştirme
Bir fikir kullanmadan önce, genellikle uygulanabilir olmayan bir çözüm üzerinde zaman kaybetmemek için bazı teorik ön değerlendirmeler yaparız. Bu güvenlik açığı istismarında iki ana yön dikkate alınmıştır:
Shellcode kodunu çalıştırma: Önceki CVE-2017-0263 ve CVE-2016-0167'ye bakın. Ancak yüksek sürüm Windows'larda, bu yöntem bazı zorlayıcı sorunlarla karşılaşabilir.
Token adresini değiştirmek için okuma-yazma primitiflerini kullanmak: Son yıllarda referans alabileceğimiz kamuya açık yöntemler bulunmaktadır. Masaüstü yığın bellek düzeni ve okuma-yazma primitifleri uzun süre genel geçerlik taşımaktadır. Öncelikle UAF belleği yeniden kullanılırken cbwndextra'yı ilk kontrol etmenin nasıl yapılacağını analiz etmemiz gerekiyor.
Tüm fayda sağlama sürecini iki soruya ayırıyoruz: UAF açığını kullanarak cbwndextra değerini nasıl kontrol edeceğiz ve cbwndextra değerini kontrol ettikten sonra istikrarlı bir okuma/yazma ilkesini nasıl gerçekleştireceğiz.
Sonunda, xxxRedrawWindow fonksiyonunda HWNDClass'ın cb-extra'sına yazmak için bayrakların AND 2 işlemi ile kullanmaya karar verdik. Bunun nedeni, HWNDClass'ın cb-extra'sının küçük bir kaydırmaya sahip olmasıdır; bu sayede bir önceki nesnenin bellek verilerini kontrol etmek için bellek düzenini kullanabiliriz ve xxxRedrawWindow fonksiyonunda nesne bayrağının değerlendirilmesiyle bunu gerçekleştirebiliriz.
Stabil bir bellek düzeni sağlamak için en az üç ardışık 0x250 baytlık HWND nesnesi tasarladık. Ara nesneleri serbest bıraktıktan sonra, bu konumu 0x250 baytlık HWNDClass nesnesi ile dolduruyoruz. Önceki HWND nesnesinin son verileri, xxxRedrawWindow bayrağıyla kontrol için kullanılırken, sonraki HWND nesnesinin menü nesnesi ve HWNDClass nesnesi nihai okuma/yazma işlemleri için bir aracı olarak kullanılır.
Pencere nesnesi ile HWNDClass nesnesinin boyutunu tutmaya çalışıyoruz ve pencere nesnesinin genişletilmiş verilerinin yeterince büyük olduğundan emin oluyoruz. Bellekte sızan çekirdek tanıtıcı adresi ile, talep edilen pencere nesnesinin beklenen sırayla sıralanıp sıralanmadığını kesin olarak belirleyebiliriz.
Okuma ve yazma işlemleri açısından, herhangi bir okuma işlemi gerçekleştirmek için GetMenuBarInfo() kullanıyoruz, herhangi bir yazma işlemi için ise SetClassLongPtr() kullanıyoruz. TOKEN'ın yazma işlemini ikinci pencerenin class nesnesine değiştirmek dışında, diğer tüm yazma işlemleri ilk pencere nesnesinin class nesnesini kaydırma ile gerçekleştiriyor.
Özet
win32k durumu: Microsoft, Windows 11 önizleme sürümündeki ilgili çekirdek kodunu Rust ile yeniden yapılandırmaya çalışıyor, gelecekteki yeni sistem bu tür açıkları ortadan kaldırabilir.
Açık istismar süreci nispeten basittir: İlk yazmanın nasıl kontrol edileceği dışında, temel olarak yeni istismar teknikleri kullanmaya gerek yoktur. Bu tür açıklar, masaüstü yığın işleme adresinin sızdırılmasına ciddi şekilde bağımlıdır.
Açık Bulma: Daha kapsamlı bir kod kapsama testi gerektirdiği tahmin edilmektedir. Sistem API'si hedef fonksiyon yürütme yolundaki en derin açık noktaya ulaştığında ve pencere nesnesi çok katmanlı bir referans durumunda olduğunda, bu açık bulanık test ile keşfedilebilir.
Diğer bulma yolları: Açık tetikleme işlevi anahtar noktalarının tespiti dışında, nadir görülen bellek düzenleri ve pencere veya pencere sınıfı ek veri anormal kaydırma okuma/yazma tespitinin de benzer açıkları keşfetmenin yollarından biri olabileceği düşünülebilir.