Pada habr sudah ada
berita tentang kerentanan ini , tetapi, sayangnya, tanpa detail teknis. Saya sarankan Anda mencari di dalam
arsip yang diterbitkan (penulis -
SandboxEscaper ).
Di bawah pemotong adalah terjemahan dari dokumen deskripsi di arsip.
Deskripsi Kerentanan
Layanan Penjadwal Tugas memiliki antarmuka RPC (dapat diakses melalui transportasi ALPC) yang mendukung metode SchRpcSetSecurity.
Ini adalah prototipe dari metode ini:
long _SchRpcSetSecurity( [in][string] wchar_t* arg_1,
Tugas yang dibuat oleh penjadwal tugas membuat direktori / file yang sesuai di c: \ windows \ system32 \ tugas. Mungkin, metode ini dimaksudkan untuk merekam tugas DACL yang terletak di sana. Tetapi rekaman akan terjadi setelah peniruan. Namun, untuk beberapa alasan, implementasi metode ini juga memeriksa keberadaan file .job dalam tugas c: \ windows \ dan menulis DACL untuknya
tanpa peniruan . Karena pengguna (bahkan pengguna dalam grup tamu) dapat membuat file di direktori ini, kami cukup membuat hardlink ke file lain yang dapat kita baca. Menggunakan hardlink semacam itu, kita dapat memaksa layanan scheduler (mengeksekusi dengan hak istimewa SYSTEM) untuk menulis DACL sewenang-wenang (lihat parameter SchRpcSetSecurity kedua) ke file pilihan kita.
Jadi: untuk file apa pun yang dapat dibaca, Anda dapat mengubah DACL, yang memungkinkan Anda untuk menimpanya sepenuhnya.
Eksploitasi kerentanan
Kerentanan ini memberi kita primitif yang sangat kuat! Masalah utama adalah bahwa setelah instalasi (secara default), banyak file penting hanya dapat dimodifikasi oleh pengguna TrustedInstaller (tetapi tidak oleh pengguna SYSTEM).
Arsip berisi skrip PowerShell untuk daftar file yang dapat Anda kontrol. Jalankan saja:
./enumerate.ps1 >output.txt
Sistem memiliki banyak tujuan. Anda dapat mengontrol File Program, dan jika file target Anda digunakan oleh administrator / pengguna lain, file yang telah Anda timpa dapat diluncurkan dengan hak istimewa yang diperlukan.
Masalah kedua adalah bahwa walaupun kita dapat mengontrol banyak file, menulis kepada mereka seringkali tidak mungkin, karena DLL ini sudah dimuat di suatu tempat untuk dieksekusi. Mencoba menulis DACL untuk file yang diunggah untuk dieksekusi akan menyebabkan kesalahan akses bersama. Tetapi kerentanan dapat digunakan untuk jenis file lain, yang mungkin merupakan target yang lebih baik daripada DLL.
Untuk operasi, file C: \ Windows \ System32 \ DriverStore \ FileRepository \ prnms003.inf_amd64_4592475aca2acf83 \ Amd64 \ printconfig.dll dipilih (nama direktori dapat bervariasi, ini diperhitungkan dalam PoC). Sepertinya file ini milik printer XPS dan tidak dimuat ke dalam layanan cetak secara default (mungkin saja file tersebut sudah dimuat ... tetapi lebih sering tidak).
Dan ketika kita memulai pekerjaan cetak menggunakan printer XPS, layanan akan memuat DLL ini, yang dapat kita tulis ulang sebelumnya. Vektor serangan semacam itu (pembajakan) dapat dengan mudah diterapkan untuk sesuatu yang lebih baik. Saya dapat mencoba menemukan opsi terbaik ... cukup beri tahu saya.
Catatan : Di laptop lama, di mana Windows 10 telah berjalan selama beberapa tahun, ada dua direktori prnms003.inf_amd64_ *. Versi baru tidak menghapus yang lama, yang berarti tidak ada jaminan bahwa FindFirstFile (digunakan dalam PoC) akan menemukan direktori saat ini. Oleh karena itu, Anda dapat memperluas kode dengan menimpa semua printconfig.dll yang ditemukan atau memeriksa atribut catatan terakhir dalam file dan memilih yang lebih baru.
Demo
Anda juga dapat menemukan video dengan demonstrasi di arsip: