Analisis dan Pemanfaatan Kerentanan 0day Sistem Microsoft
Pendahuluan
Baru-baru ini, patch keamanan Microsoft telah memperbaiki kerentanan eskalasi hak istimewa win32k yang sedang dieksploitasi oleh peretas. Kerentanan ini terutama mempengaruhi versi awal sistem Windows, tampaknya tidak berpengaruh pada Windows 11. Artikel ini akan menganalisis secara mendalam bagaimana jenis kerentanan ini dapat terus dimanfaatkan oleh penyerang dalam konteks perbaikan langkah-langkah perlindungan yang terus berkembang saat ini. Lingkungan analisis kami adalah Windows Server 2016.
Latar Belakang Kerentanan
0day adalah istilah yang merujuk pada kerentanan keamanan yang belum dipublikasikan dan belum diperbaiki, mirip dengan konsep perdagangan T+0 di pasar keuangan. Kerentanan jenis ini, jika dieksploitasi secara jahat, sering kali dapat menyebabkan kerusakan yang besar. Kerentanan 0day tingkat sistem Windows yang ditemukan kali ini dapat memberikan pengendali penuh atas sistem kepada penyerang.
Konsekuensi serius dari sistem yang dikendalikan oleh penyerang termasuk kebocoran informasi pribadi, kehilangan data akibat keruntuhan sistem, kerugian harta benda, dan penanaman program jahat. Bagi pengguna cryptocurrency, kunci pribadi dapat dicuri, dan aset digital dapat dipindahkan. Dari sudut pandang yang lebih luas, kerentanan ini bahkan dapat mempengaruhi seluruh ekosistem Web3 yang berbasis pada infrastruktur Web2.
Analisis Patch
Menganalisis kode patch, masalah tampaknya berasal dari penghitungan referensi suatu objek yang diproses beberapa kali. Dengan melihat komentar kode sebelumnya, kami menemukan bahwa kode sebelumnya hanya mengunci objek jendela, tidak mengunci objek menu dalam jendela, yang dapat menyebabkan objek menu direferensikan secara salah.
Verifikasi Kerentanan
Analisis konteks fungsi kerentanan, kami menemukan bahwa menu yang diteruskan ke xxxEnableMenuItem() biasanya telah dikunci dalam fungsi tingkat atas, jadi objek menu mana yang harus dilindungi? Analisis lebih lanjut terhadap penanganan objek menu dalam xxxEnableMenuItem menunjukkan bahwa fungsi MenuItemState mengembalikan dua kemungkinan menu: menu utama jendela atau submenu( termasuk submenu dari submenu).
Untuk memverifikasi celah, kami membangun struktur menu khusus empat lapisan dan menetapkan beberapa kondisi tertentu untuk menghindari deteksi dalam fungsi xxxEnableMenuItem. Ketika xxxRedrawTitle mengembalikan lapisan pengguna, kami menghapus hubungan referensi menu C dan B, berhasil melepaskan menu C. Akhirnya, ketika fungsi xxxEnableMenuItem di kernel kembali ke fungsi xxxRedrawTitle, objek menu C yang akan direferensikan sudah tidak valid.
Eksploitasi Kerentanan
Pemikiran keseluruhan
Sebelum menentukan rencana pemanfaatan, kami biasanya akan melakukan beberapa analisis teori untuk menghindari pemborosan waktu pada rencana yang tidak dapat dilaksanakan. Eksploitasi kerentanan kali ini terutama mempertimbangkan dua arah:
Eksekusi shellcode: Merujuk pada kerentanan serupa di masa lalu, tetapi mungkin menghadapi beberapa masalah yang sulit dipecahkan di versi Windows yang lebih tinggi.
Menggunakan primitif baca/tulis untuk memodifikasi token: bahkan dalam dua tahun terakhir masih ada kasus publik yang dapat dijadikan referensi. Kita perlu fokus pada bagaimana mengontrol cbwndextra menjadi nilai besar saat memori UAF digunakan kembali.
Oleh karena itu, kami membagi seluruh proses pemanfaatan menjadi dua bagian: bagaimana memanfaatkan kerentanan UAF untuk mengontrol nilai cbwndextra, dan bagaimana mewujudkan primitif baca-tulis yang stabil setelah mengontrol nilai tersebut.
Penulisan data pertama
Setelah memicu kerentanan, sistem tidak selalu akan langsung mogok. Kesalahan dalam menggunakan data objek jendela dari memori yang dikendalikan terutama terjadi pada fungsi xxxEnableMenuItem MNGetPopupFromMenu() dan xxxMNUpdateShownMenu().
Kami menggunakan objek nama jendela dalam kelas WNDClass untuk menggunakan memori objek menu yang dibebaskan. Kuncinya adalah menemukan lokasi dalam struktur alamat yang dapat kita bangun di mana kita bisa menulis data sembarangan, bahkan hanya satu byte.
Akhirnya, kami menemukan dua solusi yang dapat dilakukan dalam fungsi xxxRedrawWindow. Mengingat beberapa faktor pembatas, kami memilih solusi yang bergantung pada operasi AND 2 pada flag, dan memutuskan untuk menulis cb-extra dari HWNDClass daripada cb-extra dari objek jendela.
tata memori yang stabil
Kami merancang tata letak memori untuk setidaknya tiga objek HWND berukuran 0x250 byte yang berurutan. Lepaskan objek tengah, menggunakan objek HWNDClass berukuran 0x250 byte. Data ekor objek HWND sebelumnya digunakan untuk memverifikasi dengan tanda xxxRedrawWindow, dan objek menu dari objek HWND berikutnya serta objek HWNDClass sebagai media read-write akhir.
Kami berusaha mengontrol ukuran objek jendela dan objek HWNDClass agar konsisten, dan memastikan bahwa data ekstensi objek jendela cukup besar. Melalui alamat pegangan kernel yang bocor dalam memori heap, kami dapat menentukan dengan tepat apakah objek jendela yang diminta diatur dalam urutan yang diharapkan.
Implementasi primitif baca-tulis
Untuk membaca bahasa asli, gunakan GetMenuBarInfo(). Untuk menulis bahasa asli, gunakan SetClassLongPtr(). Selain operasi tulis yang menggantikan TOKEN yang bergantung pada objek kelas jendela kedua, operasi tulis lainnya memanfaatkan objek kelas jendela pertama menggunakan offset untuk diimplementasikan.
Ringkasan
Kerentanan win32k telah ada sejak lama, tetapi Microsoft sedang membangun kembali kode kernel terkait dengan Rust, dan sistem baru di masa depan mungkin dapat mencegah kerentanan semacam ini.
Proses eksploitasi kerentanan ini tidak terlalu sulit, tantangan utamanya adalah bagaimana mengontrol penulisan pertama. Kerentanan ini masih sangat bergantung pada kebocoran alamat pegangan tumpukan desktop, yang tetap menjadi risiko keamanan untuk sistem lama.
Penemuan celah ini mungkin berkat deteksi cakupan kode yang lebih baik. Setelah API sistem dapat mencapai titik celah terdalam dalam jalur eksekusi fungsi target, dan objek jendela berada dalam keadaan referensi bersarang ganda, pengujian fuzz mungkin dapat menemukan celah ini.
Untuk deteksi eksploitasi kerentanan, selain memperhatikan titik kunci fungsi pemicu kerentanan, juga harus memperhatikan tata letak memori yang tidak biasa dan pembacaan/penulisan offset ekstra data jendela atau kelas jendela yang tidak konvensional, yang dapat membantu menemukan kerentanan jenis yang sama.
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.
Analisis mendalam dan teknik pemanfaatan kerentanan 0day tingkat sistem Windows
Analisis dan Pemanfaatan Kerentanan 0day Sistem Microsoft
Pendahuluan
Baru-baru ini, patch keamanan Microsoft telah memperbaiki kerentanan eskalasi hak istimewa win32k yang sedang dieksploitasi oleh peretas. Kerentanan ini terutama mempengaruhi versi awal sistem Windows, tampaknya tidak berpengaruh pada Windows 11. Artikel ini akan menganalisis secara mendalam bagaimana jenis kerentanan ini dapat terus dimanfaatkan oleh penyerang dalam konteks perbaikan langkah-langkah perlindungan yang terus berkembang saat ini. Lingkungan analisis kami adalah Windows Server 2016.
Latar Belakang Kerentanan
0day adalah istilah yang merujuk pada kerentanan keamanan yang belum dipublikasikan dan belum diperbaiki, mirip dengan konsep perdagangan T+0 di pasar keuangan. Kerentanan jenis ini, jika dieksploitasi secara jahat, sering kali dapat menyebabkan kerusakan yang besar. Kerentanan 0day tingkat sistem Windows yang ditemukan kali ini dapat memberikan pengendali penuh atas sistem kepada penyerang.
Konsekuensi serius dari sistem yang dikendalikan oleh penyerang termasuk kebocoran informasi pribadi, kehilangan data akibat keruntuhan sistem, kerugian harta benda, dan penanaman program jahat. Bagi pengguna cryptocurrency, kunci pribadi dapat dicuri, dan aset digital dapat dipindahkan. Dari sudut pandang yang lebih luas, kerentanan ini bahkan dapat mempengaruhi seluruh ekosistem Web3 yang berbasis pada infrastruktur Web2.
Analisis Patch
Menganalisis kode patch, masalah tampaknya berasal dari penghitungan referensi suatu objek yang diproses beberapa kali. Dengan melihat komentar kode sebelumnya, kami menemukan bahwa kode sebelumnya hanya mengunci objek jendela, tidak mengunci objek menu dalam jendela, yang dapat menyebabkan objek menu direferensikan secara salah.
Verifikasi Kerentanan
Analisis konteks fungsi kerentanan, kami menemukan bahwa menu yang diteruskan ke xxxEnableMenuItem() biasanya telah dikunci dalam fungsi tingkat atas, jadi objek menu mana yang harus dilindungi? Analisis lebih lanjut terhadap penanganan objek menu dalam xxxEnableMenuItem menunjukkan bahwa fungsi MenuItemState mengembalikan dua kemungkinan menu: menu utama jendela atau submenu( termasuk submenu dari submenu).
Untuk memverifikasi celah, kami membangun struktur menu khusus empat lapisan dan menetapkan beberapa kondisi tertentu untuk menghindari deteksi dalam fungsi xxxEnableMenuItem. Ketika xxxRedrawTitle mengembalikan lapisan pengguna, kami menghapus hubungan referensi menu C dan B, berhasil melepaskan menu C. Akhirnya, ketika fungsi xxxEnableMenuItem di kernel kembali ke fungsi xxxRedrawTitle, objek menu C yang akan direferensikan sudah tidak valid.
Eksploitasi Kerentanan
Pemikiran keseluruhan
Sebelum menentukan rencana pemanfaatan, kami biasanya akan melakukan beberapa analisis teori untuk menghindari pemborosan waktu pada rencana yang tidak dapat dilaksanakan. Eksploitasi kerentanan kali ini terutama mempertimbangkan dua arah:
Eksekusi shellcode: Merujuk pada kerentanan serupa di masa lalu, tetapi mungkin menghadapi beberapa masalah yang sulit dipecahkan di versi Windows yang lebih tinggi.
Menggunakan primitif baca/tulis untuk memodifikasi token: bahkan dalam dua tahun terakhir masih ada kasus publik yang dapat dijadikan referensi. Kita perlu fokus pada bagaimana mengontrol cbwndextra menjadi nilai besar saat memori UAF digunakan kembali.
Oleh karena itu, kami membagi seluruh proses pemanfaatan menjadi dua bagian: bagaimana memanfaatkan kerentanan UAF untuk mengontrol nilai cbwndextra, dan bagaimana mewujudkan primitif baca-tulis yang stabil setelah mengontrol nilai tersebut.
Penulisan data pertama
Setelah memicu kerentanan, sistem tidak selalu akan langsung mogok. Kesalahan dalam menggunakan data objek jendela dari memori yang dikendalikan terutama terjadi pada fungsi xxxEnableMenuItem MNGetPopupFromMenu() dan xxxMNUpdateShownMenu().
Kami menggunakan objek nama jendela dalam kelas WNDClass untuk menggunakan memori objek menu yang dibebaskan. Kuncinya adalah menemukan lokasi dalam struktur alamat yang dapat kita bangun di mana kita bisa menulis data sembarangan, bahkan hanya satu byte.
Akhirnya, kami menemukan dua solusi yang dapat dilakukan dalam fungsi xxxRedrawWindow. Mengingat beberapa faktor pembatas, kami memilih solusi yang bergantung pada operasi AND 2 pada flag, dan memutuskan untuk menulis cb-extra dari HWNDClass daripada cb-extra dari objek jendela.
tata memori yang stabil
Kami merancang tata letak memori untuk setidaknya tiga objek HWND berukuran 0x250 byte yang berurutan. Lepaskan objek tengah, menggunakan objek HWNDClass berukuran 0x250 byte. Data ekor objek HWND sebelumnya digunakan untuk memverifikasi dengan tanda xxxRedrawWindow, dan objek menu dari objek HWND berikutnya serta objek HWNDClass sebagai media read-write akhir.
Kami berusaha mengontrol ukuran objek jendela dan objek HWNDClass agar konsisten, dan memastikan bahwa data ekstensi objek jendela cukup besar. Melalui alamat pegangan kernel yang bocor dalam memori heap, kami dapat menentukan dengan tepat apakah objek jendela yang diminta diatur dalam urutan yang diharapkan.
Implementasi primitif baca-tulis
Untuk membaca bahasa asli, gunakan GetMenuBarInfo(). Untuk menulis bahasa asli, gunakan SetClassLongPtr(). Selain operasi tulis yang menggantikan TOKEN yang bergantung pada objek kelas jendela kedua, operasi tulis lainnya memanfaatkan objek kelas jendela pertama menggunakan offset untuk diimplementasikan.
Ringkasan
Kerentanan win32k telah ada sejak lama, tetapi Microsoft sedang membangun kembali kode kernel terkait dengan Rust, dan sistem baru di masa depan mungkin dapat mencegah kerentanan semacam ini.
Proses eksploitasi kerentanan ini tidak terlalu sulit, tantangan utamanya adalah bagaimana mengontrol penulisan pertama. Kerentanan ini masih sangat bergantung pada kebocoran alamat pegangan tumpukan desktop, yang tetap menjadi risiko keamanan untuk sistem lama.
Penemuan celah ini mungkin berkat deteksi cakupan kode yang lebih baik. Setelah API sistem dapat mencapai titik celah terdalam dalam jalur eksekusi fungsi target, dan objek jendela berada dalam keadaan referensi bersarang ganda, pengujian fuzz mungkin dapat menemukan celah ini.
Untuk deteksi eksploitasi kerentanan, selain memperhatikan titik kunci fungsi pemicu kerentanan, juga harus memperhatikan tata letak memori yang tidak biasa dan pembacaan/penulisan offset ekstra data jendela atau kelas jendela yang tidak konvensional, yang dapat membantu menemukan kerentanan jenis yang sama.