Analisis Kerentanan Serius Sistem Windows Microsoft

Baru-baru ini, Microsoft merilis tambalan keamanan yang memperbaiki kerentanan peningkatan hak akses di kernel Windows yang sedang dieksploitasi oleh peretas. Kerentanan ini terutama mempengaruhi versi awal sistem Windows, dan tidak dapat dipicu di Windows 11. Kerentanan semacam ini sudah ada sejak lama, artikel ini akan membahas bagaimana penyerang terus memanfaatkan kerentanan semacam ini di tengah latar belakang penguatan perlindungan keamanan saat ini.

Analisis ini dilakukan di lingkungan Windows Server 2016.

Latar Belakang Kerentanan

Ini adalah kerentanan zero-day, yang merujuk pada kerentanan sistem yang belum diumumkan dan belum diperbaiki. Peretas dapat mengeksploitasi kerentanan zero-day untuk menyerang tanpa sepengetahuan pengguna, yang memiliki potensi untuk menyebabkan kerusakan besar.

Kerentanan nol hari yang ditemukan kali ini terdapat pada tingkat kernel sistem Windows, di mana hacker dapat memperoleh kontrol penuh atas Windows melalui kerentanan ini. Ini dapat menyebabkan kebocoran privasi pengguna, keruntuhan sistem, kehilangan data, kerugian finansial, dan konsekuensi serius lainnya. Dari sudut pandang Web3, kunci pribadi pengguna dapat dicuri, dan aset digital menghadapi risiko dipindahkan. Dalam skala yang lebih besar, kerentanan ini bahkan dapat memengaruhi seluruh ekosistem Web3 yang berjalan di atas infrastruktur Web2.

Analisis Kerentanan

Analisis kode patch, kami menemukan bahwa masalah terletak pada jumlah referensi sebuah objek yang diproses beberapa kali. Melihat komentar kode sumber win32k sebelumnya, dapat dipahami bahwa kode sebelumnya hanya mengunci objek jendela, tanpa mengunci objek menu di dalam objek jendela, yang dapat menyebabkan objek menu dirujuk secara salah.

Analisis lebih lanjut menunjukkan bahwa menu yang diteruskan ke fungsi xxxEnableMenuItem() biasanya telah dikunci di dalam fungsi tingkat atas, jadi menu objek mana yang sebenarnya perlu dilindungi? Setelah diteliti, ada dua kemungkinan menu yang dikembalikan oleh fungsi MenuItemState dalam xxxEnableMenuItem: menu utama jendela, atau submenu dari menu( bahkan submenu dari submenu).

Eksploitasi Kerentanan

Untuk memverifikasi kerentanan, kami membangun struktur menu khusus empat lapis dan menetapkan beberapa kondisi tertentu:

1. ID menu dasar D harus berupa tipe menu sistem, seperti menutup menu (0xf060)
2. Menu tingkat atas A juga harus merupakan menu sistem, tetapi item menu 0xf060 harus dihapus.
3. Hapus referensi menu C di menu B
4. Keberadaan menu B tampaknya mempengaruhi peluncuran menu C

Ketika kerentanan terpicu, hapus asosiasi menu C dan B saat xxxRedrawTitle mengembalikan lapisan pengguna, berhasil melepaskan menu C. Ketika fungsi xxxEnableMenuItem di kernel kembali ke xxxRedrawTitle, objek menu C yang akan dirujuk telah tidak valid.

Analisis Pemanfaatan Kerentanan

Dalam merancang skema eksploitasi kerentanan, kami terutama mempertimbangkan dua arah:

1. Eksekusi shellcode: Merujuk pada metode CVE-2017-0263 dan CVE-2016-0167 yang lebih awal. Namun, pada versi Windows yang lebih tinggi, titik masuk eksekusi shellcode dan mekanisme keamanan seperti SMEP mungkin menghadapi hambatan.

2. Menggunakan primitif baca-tulis untuk memodifikasi alamat token: Metode ini memiliki universalitas yang baik. Kuncinya adalah menganalisis bagaimana mengontrol cbwndextra menjadi nilai yang sangat besar saat memanfaatkan kembali memori UAF untuk pertama kalinya.

Kami membagi eksploitasi kerentanan menjadi dua langkah: mengontrol nilai cbwndextra, dan mewujudkan primitif baca/tulis yang stabil.

Penulisan data pertama

Kesalahan sistem yang menggunakan data objek jendela yang dikendalikan memori terutama terjadi pada fungsi xxxEnableMenuItem MNGetPopupFromMenu() dan xxxMNUpdateShownMenu(). Kami memanfaatkan objek nama jendela dari kelas jendela WNDClass untuk membebaskan memori objek menu yang terpakai.

Kuncinya adalah menemukan struktur alamat yang dapat ditulis sembarangan, bahkan jika hanya satu byte. Akhirnya kami memilih solusi dalam fungsi xxxRedrawWindow, menulis ke cb-extra dari HWNDClass melalui operasi AND 2.

tata letak memori

Kami merancang tata letak memori untuk tiga objek HWND sepanjang 0x250 byte secara berurutan, membebaskan objek tengah dan menggunakan objek HWNDClass sepanjang 0x250 byte. Data di bagian akhir objek HWND sebelumnya digunakan untuk memverifikasi melalui xxxRedrawWindow, menu objek HWND berikutnya dan objek HWNDClass digunakan untuk operasi baca/tulis akhir.

Kami berusaha membuat ukuran objek jendela dan objek HWNDClass konsisten, dan dengan alamat pegangan kernel yang bocor, kami dapat secara akurat menentukan apakah susunan objek sesuai harapan.

Membaca dan Menulis Primitif

Gunakan GetMenuBarInfo() untuk membaca primitif apa pun, dan gunakan SetClassLongPtr() untuk menulis primitif apa pun. Selain penulisan TOKEN, penulisan lainnya memanfaatkan objek class dari objek jendela pertama untuk melakukan penulisan offset.

Ringkasan

1. Microsoft sedang merekonstruksi kode kernel terkait win32k menggunakan Rust, di masa depan kerentanan semacam ini mungkin dapat dihindari dalam sistem baru.

2. Proses eksploitasi kerentanan ini relatif sederhana, terutama bergantung pada kebocoran alamat pegangan tumpukan desktop. Jika masalah ini tidak diselesaikan secara menyeluruh, sistem yang sudah usang masih memiliki risiko keamanan.

3. Penemuan kerentanan ini mungkin disebabkan oleh deteksi cakupan kode yang lebih baik.

4. Untuk deteksi eksploitasi kerentanan, selain memperhatikan titik kunci fungsi pemicu kerentanan, juga harus memperhatikan deteksi penyimpangan baca/tulis data tambahan dari tata letak memori dan kelas jendela.