Lewati Kontrol Akun Pengguna (UAC) dengan meniru direktori tepercaya

Pakar Keamanan Informasi David Wells telah menerbitkan cara untuk mem-bypass kontrol akun pengguna UAC di Windows 10

Halo semuanya!

Saat meneliti beberapa solusi baru untuk Kontrol Akun Pengguna (UAC), saya menemukan solusi yang sama sekali baru untuk UAC pada saat penulisan ini. Perlu dicatat bahwa Microsoft tidak menganggap UAC sebagai batas keamanan, namun, kami masih melaporkan berbagai bug di Microsoft dan saya ingin berbagi rincian kerentanan yang saya temukan di sini. Metode ini telah berhasil diuji pada Windows 10 Build 17134. Sebelum saya menyelami rincian temuan saya, pertama-tama saya akan memberikan sedikit penjelasan tentang cara kerja layanan UAC.

Primer Uac

Ketika pengguna yang merupakan anggota grup Administrators ingin menjalankan aplikasi yang memerlukan hak tinggi, UAC menampilkan permintaan yang sesuai dan pengguna yang merupakan anggota grup Administrator perlu mengkonfirmasi tindakan. Namun, permintaan UAC ini tidak terjadi untuk SEMUA file yang dapat dieksekusi secara administratif pada Windows. . Ada beberapa pengecualian yang akan "secara otomatis" meningkatkan hak istimewa dari file yang dapat dieksekusi tanpa menyebabkan permintaan UAC, melewati UAC (sangat mengejutkan Anda!). Kelompok khusus dari executable terpilih terpilih ini menjalani pemeriksaan keamanan tambahan oleh sistem untuk memastikan bahwa file-file ini benar-benar andal, oleh karena itu penyerang informasi biasanya tidak menyalahgunakan fitur ini. Pendekatan ini digunakan dalam metode memotong UAC sebelumnya dan akan menjadi dasar metode memotong baru saya. Namun, ada beberapa celah yang perlu kita ambil agar serangan kita berhasil. Mari kita lihat persyaratan yang harus dipenuhi jika kita ingin agar executable kita “secara otomatis ditingkatkan menjadi privilege”. Untuk melakukan ini, saya akan menunjukkan beberapa gambar perpustakaan appinfo.dll dibongkar (layanan AIS yang memproses permintaan eskalasi hak istimewa adalah salah satu komponen utama UAC).

Persyaratan 1: File dikonfigurasikan untuk secara otomatis meningkatkan hak istimewa

Ketika permintaan untuk eskalasi hak istimewa untuk suatu program muncul, layanan AIS (appinfo.dll) membuat panggilan RPC dengan jalur target yang dapat dieksekusi dilewatkan sebagai argumen. Layanan ini kemudian akan memetakan konten target file yang dapat dieksekusi untuk dibaca. Dalam manifes file yang dapat dieksekusi, upaya dilakukan untuk membaca nilai untuk mendapatkan kunci "autoElevate" (jika ada).

Gambar 1 - Membaca manifes file yang dapat dieksekusi untuk mendapatkan nilai kunci "autoElevate".



Jika nilai diterima dan itu Benar, maka file tersebut akan dianggap sebagai file yang dapat dieksekusi yang ditinggikan “otomatis” yang akan berjalan dengan eskalasi hak istimewa dan tidak memanggil kotak dialog layanan UAC (asalkan melewati persyaratan berikut yang disebutkan di bawah).

Gambar 2 - memanggil "bsearch" untuk memeriksa nama file yang dapat dieksekusi dalam daftar executable "elevating otomatis"



Beberapa file ini yang diprogram dengan keras dalam sistem masuk daftar putih:
'cttunesvr.exe', 'inetmgr.exe', 'migsetup.exe', 'mmc.exe', 'oobe.exe', 'pkgmgr.exe', 'provisionhare.exe', 'provisionstorage.exe', 'provisionstorage.exe', 'spinstall .exe ',' winsat.exe '

Persyaratan 2: Ditandatangani dengan benar

Diasumsikan bahwa kondisi kedua untuk "secara otomatis" meningkatkan hak istimewa setelah mengirim permintaan ke UAC adalah melakukan pemeriksaan tanda tangan menggunakan "wintrust! WTGetSignatureInfo ".

Ini berarti bahwa penyerang tidak akan dapat dengan mudah membuat manifesnya sendiri atau file yang dapat dieksekusi yang diperlukan untuk peningkatan hak "otomatis" dan berhasil, karena file biner penyerang kemungkinan besar akan ditandatangani secara tidak benar, dan persyaratan terakhir, eksekusi, juga tidak akan terpenuhi. dari direktori tepercaya.

Persyaratan 3: Eksekusi dari direktori tepercaya

Persyaratan terakhir untuk mendapatkan peningkatan hak "otomatis" adalah bahwa target yang dapat dieksekusi ada di "direktori tepercaya", misalnya, "C: \ Windows \ System32". Gambar 3 menunjukkan bahwa AIS melakukan pemeriksaan jalur ini dengan permintaan peningkatan, dalam hal ini salah satu jalur yang dianggap "tepercaya" adalah "C: \ Windows \ System32".

Gambar 3



Judul artikel ini adalah "Bypass User Account Control (UAC) dengan meniru direktori tepercaya," sehingga Anda mungkin dapat dengan mudah menebak apa yang akan terjadi selanjutnya.

Bypass UAC

Seperti yang disebutkan sebelumnya di bagian UAC Primer, hak istimewa otomatis (bypass UAC) akan dilakukan untuk file yang dapat dieksekusi yang:

1. Dikonfigurasi untuk menerima eskalasi hak istimewa "otomatis"
2. Ditandatangani dengan benar
3. Jalankan dari direktori tepercaya ("C: \ Windows \ System32")

Appinfo.dll (AIS) menggunakan RtlPrefixUnicodeString API untuk memeriksa apakah jalur file yang dapat dieksekusi cocok dengan “C: \ Windows \ System32 \” untuk memeriksa salah satu direktori tepercaya. Ini adalah tes beton yang cukup diperkuat, mengingat perbandingannya dengan lokasi file kanonik.

Oleh karena itu, untuk mengatur bypass pemeriksaan ini, saya membuat direktori bernama "C: \ Windows \" (perhatikan spasi setelah "Windows"). Tentu saja, menggunakan tindakan ini Anda masih tidak dapat melewati pemeriksaan RtlPrefixUnicodeString, dan saya juga akan menyebutkan bahwa ini adalah nama direktori yang agak tidak valid (atau setidaknya "tidak ramah"), karena Windows tidak mengizinkan spasi ditambahkan ke akhir nama saat membuat direktori (coba )

Namun, menggunakan API CreateDirectory dan menambahkan "\\? \ "Untuk nama direktori yang ingin saya buat, kita dapat mengabaikan beberapa aturan penyaringan nama ini dan mengirim permintaan untuk membuat direktori secara langsung ke sistem file.



Ini mengarah pada pembuatan direktori yang merepotkan yang dengan senang hati hidup berdampingan dalam sistem file bersama dengan "C: \ Windows \" yang sebenarnya (kecuali ketika Anda mencoba melakukan sesuatu dengannya di Windows Explorer).



Sekarang kita memiliki direktori "C: \ Windows \", kita dapat membuat direktori "System32" di dalamnya dan menyalin salah satu file yang dapat dieksekusi yang ditandatangani (yang diizinkan oleh sistem untuk "secara otomatis" meningkatkan hak istimewa) dari direktori nyata "C: \ Windows \ System32 ".
Untuk melakukan ini, saya menyalin "winSAT.exe" (salah satu file dalam daftar putih file yang dapat dieksekusi Windows dengan peningkatan "otomatis" hak istimewa yang diizinkan oleh sistem).
Ketika kami mencoba menjalankan file ini dari direktori baru kami "C: \ Windows \ System32 \ winSAT.exe", itu akan melalui API berikut (lihat Gambar 6) di appinfo.dll sebelum melakukan pemeriksaan direktori tepercaya. Ini penting, dan landasan mengapa solusi ini bekerja.

Gambar 6



Ketika jalur yang tidak nyaman ini dengan ruang dikirim ke AIS untuk meminta eskalasi hak istimewa, jalur dilewatkan ke GetLongPathNameW, yang mengubahnya kembali menjadi "C: \ Windows \ System32 \ winSAT.exe" (spasi dihapus).

Hebat!

Sekarang ini adalah baris di mana pemeriksaan direktori yang valid dilewatkan (menggunakan RtlPrefixUnicodeString) untuk sisa pemeriksaan.

Keindahan solusi saya adalah bahwa setelah memeriksa direktori tepercaya, jalur yang dikonversi ini dieksekusi, yang kemudian dibebaskan, dan sisanya dari pemeriksaan (dan permintaan akhir untuk eskalasi hak istimewa) dilakukan dengan nama asli dari direktori yang dapat dieksekusi (dengan ruang tambahan).

Ini memungkinkan saya untuk melalui semua pemeriksaan lainnya dan menyebabkan appinfo.dll menerima salinan winSAT.exe saya sebagai memiliki peningkatan hak "otomatis" (karena ditandatangani dengan benar dan ditambahkan ke daftar putih untuk peningkatan hak "otomatis").

Untuk benar-benar menggunakan kode jahat, saya hanya menyalin WINMM.dll palsu (diimpor winSAT.exe) di direktori saya saat ini "C: \ Windows \ System32 \" untuk menipu dll lokal. Konsep lengkapnya bisa dilihat pada gambar di bawah ini.

Gambar 7



→ Tautan ke Github