Analisis Kerentanan Zero-Day Sistem Windows Microsoft: Dapat Menyebabkan Dampak Besar pada Ekosistem Web3
Pembaruan keamanan Microsoft bulan lalu memperbaiki kerentanan eskalasi hak istimewa kernel Windows yang sedang dieksploitasi secara berbahaya. Kerentanan ini terutama mempengaruhi versi Windows yang lebih lama, sementara Windows 11 tampaknya tidak terpengaruh. Artikel ini akan menganalisis bagaimana penyerang mungkin terus mengeksploitasi jenis kerentanan ini dalam konteks penguatan langkah-langkah keamanan saat ini.
Kami telah menyelesaikan semua pekerjaan analisis di lingkungan Windows Server 2016.
Vulnérabilitas zero-day merujuk pada kerentanan sistem yang belum ditemukan dan diperbaiki, mirip dengan konsep perdagangan T+0 di pasar keuangan. Begitu vulernabilitas zero-day dieksploitasi secara jahat, biasanya akan menyebabkan kerusakan yang besar. Vulnérabilitas zero-day yang ditemukan kali ini pada sistem Windows dapat memungkinkan penyerang untuk mendapatkan kendali penuh atas sistem.
Konsekuensi dari sistem yang dikendalikan oleh penyerang sangat serius, termasuk namun tidak terbatas pada kebocoran privasi pribadi, kehilangan data akibat sistem yang crash, kerugian harta benda, dan penanaman malware. Bagi pengguna individu, hal ini dapat mengakibatkan pencurian kunci pribadi cryptocurrency dan transfer aset digital; dalam skala yang lebih besar, celah ini bahkan dapat mempengaruhi seluruh ekosistem Web3 yang berbasis pada infrastruktur Web2.
Analisis Patch
Setelah menganalisis patch, kami menemukan bahwa masalahnya tampaknya hanya karena hitungan referensi suatu objek telah diproses lebih dari sekali. Karena win32k adalah kode yang lebih awal, kami dapat menemukan beberapa komentar kode awal yang menunjukkan bahwa kode sebelumnya hanya mengunci objek jendela, tidak mengunci objek menu di dalam objek jendela, yang dapat menyebabkan objek menu direferensikan secara tidak benar.
Buktikan Konsep Eksploitasi Kerentanan ( PoC ) Implementasi
Menganalisis konteks fungsi kerentanan, kami menemukan bahwa menu yang diteruskan xxxEnableMenuItem() biasanya telah dikunci di fungsi lapisan atas, lalu menu objek mana yang sebenarnya ingin dilindungi di sini?
Analisis lebih lanjut tentang proses penanganan objek menu dalam xxxEnableMenuItem, kami menemukan bahwa fungsi MenuItemState mengembalikan dua kemungkinan menu: menu utama jendela, atau submenu ( bahkan sub-submenu ).
Dalam PoC, kami membangun struktur menu khusus dengan empat lapisan, di mana menu yang berdekatan memiliki hubungan orang tua dan anak. Menu ini memiliki beberapa fitur khusus untuk dideteksi dan dinilai melalui fungsi xxxEnableMenuItem.
Saat xxxRedrawTitle mengembalikan lapisan pengguna, kami menghapus hubungan referensi antara menu C dan menu B, berhasil membebaskan menu C. Akhirnya, ketika fungsi xxxEnableMenuItem di kernel kembali ke fungsi xxxRedrawTitle, objek menu C yang akan dirujuk sudah tidak valid.
Eksploitasi (Implementasi Eksploitasi )
Sebelum menentukan pendekatan eksploitasi, kami biasanya akan melakukan beberapa penilaian awal secara teoritis untuk menghindari pemborosan waktu pada rencana yang tidak dapat dilaksanakan. Eksploitasi kerentanan kali ini terutama mempertimbangkan dua arah:
Menjalankan kode shellcode: merujuk pada CVE-2017-0263 dan CVE-2016-0167 yang lebih awal. Namun, di versi Windows yang lebih tinggi, metode ini mungkin menghadapi beberapa masalah yang sulit diatasi.
Menggunakan primitif baca/tulis untuk memodifikasi alamat token: Dalam beberapa tahun terakhir, telah ada cara yang dipublikasikan yang dapat dijadikan referensi. Tata letak memori tumpukan desktop dan primitif baca/tulis memiliki kegunaan jangka panjang. Kami terutama perlu menganalisis bagaimana cara pertama kali mengontrol cbwndextra menjadi nilai besar saat memori UAF digunakan kembali.
Kami membagi seluruh proses pemanfaatan menjadi dua masalah: bagaimana memanfaatkan kerentanan UAF untuk mengontrol nilai cbwndextra, dan bagaimana mencapai primitif baca/tulis yang stabil setelah mengontrol nilai cbwndextra.
Akhirnya kami memilih untuk menulis cb-extra dari HWNDClass melalui operasi AND 2 pada flag di fungsi xxxRedrawWindow. Ini karena offset cb-extra dari HWNDClass relatif kecil, kami dapat mengontrol data memori dari objek sebelumnya melalui tata letak memori, sehingga dapat menentukan flag objek melalui fungsi xxxRedrawWindow.
Untuk mencapai tata letak memori yang stabil, kami merancang setidaknya tiga objek HWND dengan ukuran 0x250 byte yang berurutan. Setelah melepaskan objek tengah, posisi tersebut digunakan oleh objek HWNDClass dengan ukuran 0x250 byte. Data di bagian akhir objek HWND sebelumnya digunakan untuk memverifikasi melalui tanda xxxRedrawWindow, sedangkan objek menu dari objek HWND berikutnya dan objek HWNDClass digunakan sebagai media untuk operasi baca/tulis akhir.
Kami berusaha menjaga agar ukuran objek jendela dan objek HWNDClass tetap konsisten, dan memastikan bahwa data tambahan objek jendela cukup besar. Melalui alamat handle kernel yang bocor di memori heap, kami dapat secara akurat menentukan apakah objek jendela yang diminta disusun dalam urutan yang diharapkan.
Dalam hal membaca dan menulis primitif, kami menggunakan GetMenuBarInfo() untuk implementasi baca sembarang, dan SetClassLongPtr() untuk implementasi tulis sembarang. Selain penggantian operasi tulis TOKEN yang bergantung pada objek kelas jendela kedua, semua operasi tulis lainnya memanfaatkan objek kelas jendela pertama melalui offset.
Ringkasan
Status win32k: Microsoft sedang mencoba untuk merestrukturisasi kode inti terkait dalam versi pratinjau Windows 11 menggunakan Rust, sistem baru di masa depan mungkin dapat menghindari kerentanan semacam ini.
Proses eksploitasi kerentanan relatif sederhana: kecuali untuk bagaimana mengontrol penulisan pertama yang memerlukan percobaan yang hati-hati, pada dasarnya tidak perlu menggunakan teknik eksploitasi baru. Jenis kerentanan ini sangat bergantung pada kebocoran alamat pegangan tumpukan desktop.
Penemuan Kerentanan: Diduga mungkin bergantung pada deteksi cakupan kode yang lebih baik. Begitu API sistem dapat mencapai titik kerentanan terdalam dalam jalur eksekusi fungsi target, dan objek jendela berada dalam keadaan referensi bertumpuk, kerentanan tersebut mungkin dapat ditemukan melalui pengujian fuzz.
Jalur penemuan lainnya: Selain deteksi titik kunci fungsi pemicu kerentanan, deteksi terhadap tata letak memori yang tidak umum dan pembacaan/penulisan offset data tambahan untuk jendela atau kelas jendela juga dapat menjadi salah satu cara untuk menemukan kerentanan sejenis.
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.
12 Suka
Hadiah
12
2
Bagikan
Komentar
0/400
AltcoinHunter
· 15jam yang lalu
Melihat tetapi tidak mengatakannya, sudah menjadi suckers di dunia kripto.
Analisis Kerentanan Nol Hari Windows: Ekosistem Web3 Mungkin Terpengaruh Secara Signifikan
Analisis Kerentanan Zero-Day Sistem Windows Microsoft: Dapat Menyebabkan Dampak Besar pada Ekosistem Web3
Pembaruan keamanan Microsoft bulan lalu memperbaiki kerentanan eskalasi hak istimewa kernel Windows yang sedang dieksploitasi secara berbahaya. Kerentanan ini terutama mempengaruhi versi Windows yang lebih lama, sementara Windows 11 tampaknya tidak terpengaruh. Artikel ini akan menganalisis bagaimana penyerang mungkin terus mengeksploitasi jenis kerentanan ini dalam konteks penguatan langkah-langkah keamanan saat ini.
Kami telah menyelesaikan semua pekerjaan analisis di lingkungan Windows Server 2016.
Vulnérabilitas zero-day merujuk pada kerentanan sistem yang belum ditemukan dan diperbaiki, mirip dengan konsep perdagangan T+0 di pasar keuangan. Begitu vulernabilitas zero-day dieksploitasi secara jahat, biasanya akan menyebabkan kerusakan yang besar. Vulnérabilitas zero-day yang ditemukan kali ini pada sistem Windows dapat memungkinkan penyerang untuk mendapatkan kendali penuh atas sistem.
Konsekuensi dari sistem yang dikendalikan oleh penyerang sangat serius, termasuk namun tidak terbatas pada kebocoran privasi pribadi, kehilangan data akibat sistem yang crash, kerugian harta benda, dan penanaman malware. Bagi pengguna individu, hal ini dapat mengakibatkan pencurian kunci pribadi cryptocurrency dan transfer aset digital; dalam skala yang lebih besar, celah ini bahkan dapat mempengaruhi seluruh ekosistem Web3 yang berbasis pada infrastruktur Web2.
Analisis Patch
Setelah menganalisis patch, kami menemukan bahwa masalahnya tampaknya hanya karena hitungan referensi suatu objek telah diproses lebih dari sekali. Karena win32k adalah kode yang lebih awal, kami dapat menemukan beberapa komentar kode awal yang menunjukkan bahwa kode sebelumnya hanya mengunci objek jendela, tidak mengunci objek menu di dalam objek jendela, yang dapat menyebabkan objek menu direferensikan secara tidak benar.
Buktikan Konsep Eksploitasi Kerentanan ( PoC ) Implementasi
Menganalisis konteks fungsi kerentanan, kami menemukan bahwa menu yang diteruskan xxxEnableMenuItem() biasanya telah dikunci di fungsi lapisan atas, lalu menu objek mana yang sebenarnya ingin dilindungi di sini?
Analisis lebih lanjut tentang proses penanganan objek menu dalam xxxEnableMenuItem, kami menemukan bahwa fungsi MenuItemState mengembalikan dua kemungkinan menu: menu utama jendela, atau submenu ( bahkan sub-submenu ).
Dalam PoC, kami membangun struktur menu khusus dengan empat lapisan, di mana menu yang berdekatan memiliki hubungan orang tua dan anak. Menu ini memiliki beberapa fitur khusus untuk dideteksi dan dinilai melalui fungsi xxxEnableMenuItem.
Saat xxxRedrawTitle mengembalikan lapisan pengguna, kami menghapus hubungan referensi antara menu C dan menu B, berhasil membebaskan menu C. Akhirnya, ketika fungsi xxxEnableMenuItem di kernel kembali ke fungsi xxxRedrawTitle, objek menu C yang akan dirujuk sudah tidak valid.
Eksploitasi (Implementasi Eksploitasi )
Sebelum menentukan pendekatan eksploitasi, kami biasanya akan melakukan beberapa penilaian awal secara teoritis untuk menghindari pemborosan waktu pada rencana yang tidak dapat dilaksanakan. Eksploitasi kerentanan kali ini terutama mempertimbangkan dua arah:
Menjalankan kode shellcode: merujuk pada CVE-2017-0263 dan CVE-2016-0167 yang lebih awal. Namun, di versi Windows yang lebih tinggi, metode ini mungkin menghadapi beberapa masalah yang sulit diatasi.
Menggunakan primitif baca/tulis untuk memodifikasi alamat token: Dalam beberapa tahun terakhir, telah ada cara yang dipublikasikan yang dapat dijadikan referensi. Tata letak memori tumpukan desktop dan primitif baca/tulis memiliki kegunaan jangka panjang. Kami terutama perlu menganalisis bagaimana cara pertama kali mengontrol cbwndextra menjadi nilai besar saat memori UAF digunakan kembali.
Kami membagi seluruh proses pemanfaatan menjadi dua masalah: bagaimana memanfaatkan kerentanan UAF untuk mengontrol nilai cbwndextra, dan bagaimana mencapai primitif baca/tulis yang stabil setelah mengontrol nilai cbwndextra.
Akhirnya kami memilih untuk menulis cb-extra dari HWNDClass melalui operasi AND 2 pada flag di fungsi xxxRedrawWindow. Ini karena offset cb-extra dari HWNDClass relatif kecil, kami dapat mengontrol data memori dari objek sebelumnya melalui tata letak memori, sehingga dapat menentukan flag objek melalui fungsi xxxRedrawWindow.
Untuk mencapai tata letak memori yang stabil, kami merancang setidaknya tiga objek HWND dengan ukuran 0x250 byte yang berurutan. Setelah melepaskan objek tengah, posisi tersebut digunakan oleh objek HWNDClass dengan ukuran 0x250 byte. Data di bagian akhir objek HWND sebelumnya digunakan untuk memverifikasi melalui tanda xxxRedrawWindow, sedangkan objek menu dari objek HWND berikutnya dan objek HWNDClass digunakan sebagai media untuk operasi baca/tulis akhir.
Kami berusaha menjaga agar ukuran objek jendela dan objek HWNDClass tetap konsisten, dan memastikan bahwa data tambahan objek jendela cukup besar. Melalui alamat handle kernel yang bocor di memori heap, kami dapat secara akurat menentukan apakah objek jendela yang diminta disusun dalam urutan yang diharapkan.
Dalam hal membaca dan menulis primitif, kami menggunakan GetMenuBarInfo() untuk implementasi baca sembarang, dan SetClassLongPtr() untuk implementasi tulis sembarang. Selain penggantian operasi tulis TOKEN yang bergantung pada objek kelas jendela kedua, semua operasi tulis lainnya memanfaatkan objek kelas jendela pertama melalui offset.
Ringkasan
Status win32k: Microsoft sedang mencoba untuk merestrukturisasi kode inti terkait dalam versi pratinjau Windows 11 menggunakan Rust, sistem baru di masa depan mungkin dapat menghindari kerentanan semacam ini.
Proses eksploitasi kerentanan relatif sederhana: kecuali untuk bagaimana mengontrol penulisan pertama yang memerlukan percobaan yang hati-hati, pada dasarnya tidak perlu menggunakan teknik eksploitasi baru. Jenis kerentanan ini sangat bergantung pada kebocoran alamat pegangan tumpukan desktop.
Penemuan Kerentanan: Diduga mungkin bergantung pada deteksi cakupan kode yang lebih baik. Begitu API sistem dapat mencapai titik kerentanan terdalam dalam jalur eksekusi fungsi target, dan objek jendela berada dalam keadaan referensi bertumpuk, kerentanan tersebut mungkin dapat ditemukan melalui pengujian fuzz.
Jalur penemuan lainnya: Selain deteksi titik kunci fungsi pemicu kerentanan, deteksi terhadap tata letak memori yang tidak umum dan pembacaan/penulisan offset data tambahan untuk jendela atau kelas jendela juga dapat menjadi salah satu cara untuk menemukan kerentanan sejenis.