Bulan lalu, patch keamanan Microsoft menyertakan sebuah kerentanan eskalasi hak istimewa win32k yang dapat dieksploitasi. Kerentanan ini tampaknya hanya ada di versi sistem yang lebih awal, dan tidak dapat dipicu di Windows 11. Eksploitasi jenis kerentanan ini telah ada sejak lama, artikel ini akan menganalisis bagaimana para penyerang mungkin terus mengeksploitasi kerentanan ini dalam konteks perbaikan langkah-langkah mitigasi baru yang terus berkembang. Kami menyelesaikan seluruh proses analisis di lingkungan Windows Server 2016.
0day vulnerability adalah celah yang belum diungkapkan dan diperbaiki, yang dapat dieksploitasi oleh hacker tanpa terdeteksi, sering kali memiliki potensi kerusakan yang besar. Kerentanan 0day yang ditemukan kali ini berada pada tingkat sistem Windows, di mana hacker dapat memperoleh kendali penuh atas Windows. Setelah terkendali, hal ini dapat menyebabkan pencurian informasi pribadi, keruntuhan sistem, kehilangan data, kerugian finansial, dan penanaman perangkat lunak berbahaya. Dalam skala kecil, hal ini dapat menyebabkan pencurian kunci pribadi dan pemindahan aset digital; dalam skala besar, dapat membahayakan seluruh ekosistem Web3 yang berjalan di infrastruktur Web2.
Analisis patch menunjukkan bahwa ini tampaknya hanya masalah hitungan referensi objek yang diproses lebih dari sekali. Namun, melihat komentar kode sebelumnya, ditemukan bahwa kode sebelumnya hanya mengunci objek jendela, tidak mengunci objek menu di dalam objek jendela, yang dapat menyebabkan objek menu dirujuk secara salah.
Menganalisis konteks fungsi kerentanan, kami menemukan bahwa menu yang diteruskan ke xxxEnableMenuItem() biasanya sudah dikunci di fungsi tingkat atas, jadi menu objek mana yang sebenarnya harus dilindungi di sini? Analisis lebih lanjut menunjukkan bahwa menu yang dikembalikan dalam xxxEnableMenuItem memiliki dua kemungkinan: menu utama jendela atau submenu dari menu ( bahkan submenu dari submenu ).
Untuk membangun POC, kami merancang struktur menu khusus empat lapis, dan telah melakukan pengaturan khusus pada masing-masing menu agar dapat terdeteksi melalui fungsi. Saat xxxRedrawTitle mengembalikan lapisan pengguna, kami menghapus hubungan referensi antara menu C dan menu B, berhasil melepaskan menu C. Dengan cara ini, saat fungsi xxxEnableMenuItem kembali, objek menu C yang dirujuk sudah tidak valid.
Untuk implementasi EXP, kami terutama mempertimbangkan dua arah: menjalankan kode shellcode dan menggunakan primitif baca/tulis untuk memodifikasi alamat token. Mengingat mekanisme keamanan Windows versi tinggi, kami memilih yang kedua. Seluruh proses eksploitasi dapat dibagi menjadi dua bagian: bagaimana memanfaatkan kerentanan UAF untuk mengontrol nilai cbwndextra, dan bagaimana membangun primitif baca/tulis yang stabil.
Kami merancang tata letak memori dengan cermat, memanfaatkan objek nama jendela dari kelas jendela yang mengambil alih objek menu yang dilepaskan, dan menemukan momen untuk menulis data di fungsi xxxRedrawWindow. Untuk mencapai tata letak memori yang stabil, kami merancang struktur dari tiga objek HWND yang berurutan, dan menggunakan alamat pegangan kernel yang bocor di memori tumpukan untuk secara akurat menentukan urutan penataan objek.
Dalam hal membaca dan menulis primitif, kami menggunakan GetMenuBarInfo() untuk membaca sembarang, SetClassLongPtr() untuk menulis sembarang. Selain mengganti operasi penulisan TOKEN yang bergantung pada objek class jendela kedua, semua penulisan lainnya menggunakan objek class jendela pertama melalui offset.
Secara keseluruhan, meskipun kerentanan win32k sudah ada sejak lama, Microsoft telah mencoba untuk merestrukturisasi bagian kode inti tersebut menggunakan Rust di versi pratinjau Windows 11, dan kerentanan semacam ini mungkin dapat dihindari di masa depan. Proses pemanfaatan kerentanan kali ini relatif sederhana, dengan tantangan utama terletak pada bagaimana mengontrol penulisan pertama. Penemuan kerentanan ini mungkin bergantung pada deteksi cakupan kode yang lebih baik. Untuk deteksi kerentanan, selain memperhatikan titik-titik kunci dari fungsi pemicu, deteksi terhadap tata letak memori yang tidak biasa dan pembacaan serta penulisan offset data juga merupakan kemungkinan jalan untuk menemukan kerentanan serupa.
Lihat Asli
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
16 Suka
Hadiah
16
5
Bagikan
Komentar
0/400
TopBuyerBottomSeller
· 19jam yang lalu
Satu alasan lagi untuk upgrade ke Windows 11~
Lihat AsliBalas0
FlatTax
· 07-20 03:35
Skandal, Microsoft yang lama jangan berbuat trik lagi.
Lihat AsliBalas0
SurvivorshipBias
· 07-20 03:34
Siapa yang masih menggunakan sistem win32k ini?
Lihat AsliBalas0
just_another_wallet
· 07-20 03:33
Hampir meledakkan koin lamaku, melihatnya membuat kulit kepala merinding.
Lihat AsliBalas0
MrRightClick
· 07-20 03:14
Satu-satunya versi sistem yang bahkan anjing pun tidak mau lihat adalah windows11
Kerentanan 0day Microsoft Terungkap, Keamanan Infrastruktur Web3 Mungkin Terancam
Analisis Kerentanan 0day Microsoft: Berpotensi Mengancam Keamanan Infrastruktur Web3
Bulan lalu, patch keamanan Microsoft menyertakan sebuah kerentanan eskalasi hak istimewa win32k yang dapat dieksploitasi. Kerentanan ini tampaknya hanya ada di versi sistem yang lebih awal, dan tidak dapat dipicu di Windows 11. Eksploitasi jenis kerentanan ini telah ada sejak lama, artikel ini akan menganalisis bagaimana para penyerang mungkin terus mengeksploitasi kerentanan ini dalam konteks perbaikan langkah-langkah mitigasi baru yang terus berkembang. Kami menyelesaikan seluruh proses analisis di lingkungan Windows Server 2016.
0day vulnerability adalah celah yang belum diungkapkan dan diperbaiki, yang dapat dieksploitasi oleh hacker tanpa terdeteksi, sering kali memiliki potensi kerusakan yang besar. Kerentanan 0day yang ditemukan kali ini berada pada tingkat sistem Windows, di mana hacker dapat memperoleh kendali penuh atas Windows. Setelah terkendali, hal ini dapat menyebabkan pencurian informasi pribadi, keruntuhan sistem, kehilangan data, kerugian finansial, dan penanaman perangkat lunak berbahaya. Dalam skala kecil, hal ini dapat menyebabkan pencurian kunci pribadi dan pemindahan aset digital; dalam skala besar, dapat membahayakan seluruh ekosistem Web3 yang berjalan di infrastruktur Web2.
Analisis patch menunjukkan bahwa ini tampaknya hanya masalah hitungan referensi objek yang diproses lebih dari sekali. Namun, melihat komentar kode sebelumnya, ditemukan bahwa kode sebelumnya hanya mengunci objek jendela, tidak mengunci objek menu di dalam objek jendela, yang dapat menyebabkan objek menu dirujuk secara salah.
Menganalisis konteks fungsi kerentanan, kami menemukan bahwa menu yang diteruskan ke xxxEnableMenuItem() biasanya sudah dikunci di fungsi tingkat atas, jadi menu objek mana yang sebenarnya harus dilindungi di sini? Analisis lebih lanjut menunjukkan bahwa menu yang dikembalikan dalam xxxEnableMenuItem memiliki dua kemungkinan: menu utama jendela atau submenu dari menu ( bahkan submenu dari submenu ).
Untuk membangun POC, kami merancang struktur menu khusus empat lapis, dan telah melakukan pengaturan khusus pada masing-masing menu agar dapat terdeteksi melalui fungsi. Saat xxxRedrawTitle mengembalikan lapisan pengguna, kami menghapus hubungan referensi antara menu C dan menu B, berhasil melepaskan menu C. Dengan cara ini, saat fungsi xxxEnableMenuItem kembali, objek menu C yang dirujuk sudah tidak valid.
Untuk implementasi EXP, kami terutama mempertimbangkan dua arah: menjalankan kode shellcode dan menggunakan primitif baca/tulis untuk memodifikasi alamat token. Mengingat mekanisme keamanan Windows versi tinggi, kami memilih yang kedua. Seluruh proses eksploitasi dapat dibagi menjadi dua bagian: bagaimana memanfaatkan kerentanan UAF untuk mengontrol nilai cbwndextra, dan bagaimana membangun primitif baca/tulis yang stabil.
Kami merancang tata letak memori dengan cermat, memanfaatkan objek nama jendela dari kelas jendela yang mengambil alih objek menu yang dilepaskan, dan menemukan momen untuk menulis data di fungsi xxxRedrawWindow. Untuk mencapai tata letak memori yang stabil, kami merancang struktur dari tiga objek HWND yang berurutan, dan menggunakan alamat pegangan kernel yang bocor di memori tumpukan untuk secara akurat menentukan urutan penataan objek.
Dalam hal membaca dan menulis primitif, kami menggunakan GetMenuBarInfo() untuk membaca sembarang, SetClassLongPtr() untuk menulis sembarang. Selain mengganti operasi penulisan TOKEN yang bergantung pada objek class jendela kedua, semua penulisan lainnya menggunakan objek class jendela pertama melalui offset.
Secara keseluruhan, meskipun kerentanan win32k sudah ada sejak lama, Microsoft telah mencoba untuk merestrukturisasi bagian kode inti tersebut menggunakan Rust di versi pratinjau Windows 11, dan kerentanan semacam ini mungkin dapat dihindari di masa depan. Proses pemanfaatan kerentanan kali ini relatif sederhana, dengan tantangan utama terletak pada bagaimana mengontrol penulisan pertama. Penemuan kerentanan ini mungkin bergantung pada deteksi cakupan kode yang lebih baik. Untuk deteksi kerentanan, selain memperhatikan titik-titik kunci dari fungsi pemicu, deteksi terhadap tata letak memori yang tidak biasa dan pembacaan serta penulisan offset data juga merupakan kemungkinan jalan untuk menemukan kerentanan serupa.