Microsoft Windows sistemindeki güvenlik açığı Web3 güvenlik risklerine yol açabilir
Geçen ay Microsoft'un yayımladığı güvenlik yamasında, kötüye kullanılan bir win32k yetki yükseltme açığı bulunuyor. Bu açığın yalnızca erken Windows sistem sürümlerinde mevcut olduğu, Windows 11'de tetiklenemediği anlaşılıyor.
Bu tür açıkların istismarı uzun zamandır var. Mevcut yeni güvenlik önlemlerinin sürekli olarak geliştirilmesi bağlamında, saldırganların bu açığı nasıl kullanmaya devam edebileceğini analiz etmeyi umuyoruz. Bu makalenin analiz süreci Windows Server 2016 ortamında tamamlanmıştır.
Bu sıfırıncı gün açığı, halka açıklanmadan ve düzeltilmeden kötüye kullanılabilir ve fark edilmeden kalabilir, bu da büyük yıkıcılığa yol açar. Bu açık aracılığıyla, hackerlar Windows sisteminin tam kontrolünü ele geçirebilir. Bu, kişisel bilgilerin çalınmasına, sistem çökmesine, veri kaybına, finansal kayıplara, kötü amaçlı yazılımın yerleştirilmesine gibi ciddi sonuçlara yol açabilir. Web3 kullanıcıları açısından, özel anahtarlar çalınabilir, dijital varlıklar aktarılabilir. Daha geniş bir bakış açısıyla, bu açık, Web2 altyapısı üzerinde çalışan tüm Web3 ekosistemini bile etkileyebilir.
Yaman analiz yoluyla, nesnenin referans sayısının bir kez fazla işlenmiş olduğunu tespit ettik. win32k eski bir kod olup, eski kaynak kodu yorumları, önceki kodun yalnızca pencere nesnesini kilitlediğini, pencere nesnesindeki menü nesnesini kilitlemediğini gösteriyor; bu durum menü nesnesinin hatalı bir şekilde referans edilmesine neden olabilir.
(PoC)'i gerçekleştirme aşamasında, xxxEnableMenuItem()'e gelen menünün genellikle üst fonksiyonda kilitlendiğini ve burada hangi menü nesnesinin korunması gerektiğinin belirsiz olduğunu fark ettik. Daha ileri analizler, MenuItemState fonksiyonunun döndürdüğü menünün ana pencere menüsü, alt menü veya hatta alt-alt menü olabileceğini ortaya koydu.
Bir açığı tetiklemek için, özel bir dört katmanlı menü yapısı oluşturduk ve xxxEnableMenuItem fonksiyonunun kontrolünü geçmek 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. Sonunda, xxxEnableMenuItem fonksiyonu xxxRedrawTitle'a döndüğünde, referans alınan menü C nesnesi geçersiz hale gelmişti.
(Exp) üzerinde bir güvenlik açığı geliştirilirken, temel olarak iki çözüm yolu düşündük: shellcode çalıştırmak ve token adresini değiştirmek için okuma/yazma ilkelere başvurmak. Uygulanabilirliği göz önünde bulundurarak, ikincisini seçtik. Tüm istismar süreci iki adıma ayrılabilir: UAF açığını kullanarak cbwndextra değerini nasıl kontrol edeceğimiz ve kararlı okuma/yazma ilkelere nasıl ulaşacağımız.
Bellek düzenini dikkatlice tasarlayarak, WNDClass içindeki pencere adı nesnelerini serbest bırakılan menü nesnelerini işgal etmek için kullandık. xxxRedrawWindow fonksiyonundaki belirli işlemlerle, verilerin ilk kez yazılmasını sağladık.
Dengeli bir bellek düzeni sağlamak için, ardışık üç HWND nesnesi tasarladık, ortadakini serbest bıraktık ve HWNDClass nesnesi ile doldurduk. Önceki ve sonraki HWND nesneleri, kontrol ve okuma/yazma ilkelelerini gerçekleştirmek için kullanılır. Ayrıca, nesne sıralamasının beklenildiği gibi olup olmadığını kesin olarak belirlemek için çekirdek tanıtıcı adres sızıntısını kullandık.
Okuma ve yazma işlemlerini gerçekleştirmek için GetMenuBarInfo() ile rastgele okuma, SetClassLongPtr() ile rastgele yazma kullanıyoruz. TOKEN değiştirme işlemi dışında, diğer tüm yazma işlemleri ilk pencere nesnesinin sınıf nesnesi üzerinden ofset ile gerçekleştirilir.
Win32k açığı uzun zamandır var olmasına rağmen, Microsoft ilgili çekirdek kodunu 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 açığın istismar süreci görece basit, ana zorluk ilk yazma işlemini nasıl kontrol edeceğiniz. Bu açık, masaüstü yığın tutucu adres sızıntısına ciddi şekilde bağımlıdır, bu da eski sistemlerin güvenlik açıklarını oluşturuyor.
Bu açığın keşfinin daha iyi bir kod kapsama testi sayesinde olabileceğini düşünüyoruz. Açık istismar tespiti için, kritik noktaları izlemekten başka, anormal bellek düzeni ve pencere verisi okuma/yazma ile ilgili hedefli tespitler de bu tür açıkların bulunmasına yardımcı olabilir.
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.
Windows sistemi açıkları, Web3 varlık güvenliğini tehdit ediyor; Özel Anahtarın çalınma riski var.
Microsoft Windows sistemindeki güvenlik açığı Web3 güvenlik risklerine yol açabilir
Geçen ay Microsoft'un yayımladığı güvenlik yamasında, kötüye kullanılan bir win32k yetki yükseltme açığı bulunuyor. Bu açığın yalnızca erken Windows sistem sürümlerinde mevcut olduğu, Windows 11'de tetiklenemediği anlaşılıyor.
Bu tür açıkların istismarı uzun zamandır var. Mevcut yeni güvenlik önlemlerinin sürekli olarak geliştirilmesi bağlamında, saldırganların bu açığı nasıl kullanmaya devam edebileceğini analiz etmeyi umuyoruz. Bu makalenin analiz süreci Windows Server 2016 ortamında tamamlanmıştır.
Bu sıfırıncı gün açığı, halka açıklanmadan ve düzeltilmeden kötüye kullanılabilir ve fark edilmeden kalabilir, bu da büyük yıkıcılığa yol açar. Bu açık aracılığıyla, hackerlar Windows sisteminin tam kontrolünü ele geçirebilir. Bu, kişisel bilgilerin çalınmasına, sistem çökmesine, veri kaybına, finansal kayıplara, kötü amaçlı yazılımın yerleştirilmesine gibi ciddi sonuçlara yol açabilir. Web3 kullanıcıları açısından, özel anahtarlar çalınabilir, dijital varlıklar aktarılabilir. Daha geniş bir bakış açısıyla, bu açık, Web2 altyapısı üzerinde çalışan tüm Web3 ekosistemini bile etkileyebilir.
Yaman analiz yoluyla, nesnenin referans sayısının bir kez fazla işlenmiş olduğunu tespit ettik. win32k eski bir kod olup, eski kaynak kodu yorumları, önceki kodun yalnızca pencere nesnesini kilitlediğini, pencere nesnesindeki menü nesnesini kilitlemediğini gösteriyor; bu durum menü nesnesinin hatalı bir şekilde referans edilmesine neden olabilir.
(PoC)'i gerçekleştirme aşamasında, xxxEnableMenuItem()'e gelen menünün genellikle üst fonksiyonda kilitlendiğini ve burada hangi menü nesnesinin korunması gerektiğinin belirsiz olduğunu fark ettik. Daha ileri analizler, MenuItemState fonksiyonunun döndürdüğü menünün ana pencere menüsü, alt menü veya hatta alt-alt menü olabileceğini ortaya koydu.
Bir açığı tetiklemek için, özel bir dört katmanlı menü yapısı oluşturduk ve xxxEnableMenuItem fonksiyonunun kontrolünü geçmek 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. Sonunda, xxxEnableMenuItem fonksiyonu xxxRedrawTitle'a döndüğünde, referans alınan menü C nesnesi geçersiz hale gelmişti.
(Exp) üzerinde bir güvenlik açığı geliştirilirken, temel olarak iki çözüm yolu düşündük: shellcode çalıştırmak ve token adresini değiştirmek için okuma/yazma ilkelere başvurmak. Uygulanabilirliği göz önünde bulundurarak, ikincisini seçtik. Tüm istismar süreci iki adıma ayrılabilir: UAF açığını kullanarak cbwndextra değerini nasıl kontrol edeceğimiz ve kararlı okuma/yazma ilkelere nasıl ulaşacağımız.
Bellek düzenini dikkatlice tasarlayarak, WNDClass içindeki pencere adı nesnelerini serbest bırakılan menü nesnelerini işgal etmek için kullandık. xxxRedrawWindow fonksiyonundaki belirli işlemlerle, verilerin ilk kez yazılmasını sağladık.
Dengeli bir bellek düzeni sağlamak için, ardışık üç HWND nesnesi tasarladık, ortadakini serbest bıraktık ve HWNDClass nesnesi ile doldurduk. Önceki ve sonraki HWND nesneleri, kontrol ve okuma/yazma ilkelelerini gerçekleştirmek için kullanılır. Ayrıca, nesne sıralamasının beklenildiği gibi olup olmadığını kesin olarak belirlemek için çekirdek tanıtıcı adres sızıntısını kullandık.
Okuma ve yazma işlemlerini gerçekleştirmek için GetMenuBarInfo() ile rastgele okuma, SetClassLongPtr() ile rastgele yazma kullanıyoruz. TOKEN değiştirme işlemi dışında, diğer tüm yazma işlemleri ilk pencere nesnesinin sınıf nesnesi üzerinden ofset ile gerçekleştirilir.
Win32k açığı uzun zamandır var olmasına rağmen, Microsoft ilgili çekirdek kodunu 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 açığın istismar süreci görece basit, ana zorluk ilk yazma işlemini nasıl kontrol edeceğiniz. Bu açık, masaüstü yığın tutucu adres sızıntısına ciddi şekilde bağımlıdır, bu da eski sistemlerin güvenlik açıklarını oluşturuyor.
Bu açığın keşfinin daha iyi bir kod kapsama testi sayesinde olabileceğini düşünüyoruz. Açık istismar tespiti için, kritik noktaları izlemekten başka, anormal bellek düzeni ve pencere verisi okuma/yazma ile ilgili hedefli tespitler de bu tür açıkların bulunmasına yardımcı olabilir.