Bypass tanda tangan driver Windows membuka kemungkinan pemasangan rootkit kernel
(bleepingcomputer.com)- Bahkan pada Windows yang tampak sudah menerima patch terbaru, jika proses Windows Update dikuasai maka sistem dapat dikembalikan ke komponen kernel lama, yang berujung pada bypass Driver Signature Enforcement dan distribusi rootkit kernel
- Peneliti SafeBreach, Alon Leviev, mendemonstrasikan serangan downgrade/rollback versi di BlackHat dan DEFCON, dan pengambilalihan Windows Update masih belum ditambal sepenuhnya
- Penyerang dengan hak administrator dapat mengganti ci.dll ke versi yang belum ditambal bahkan di Windows 11 terbaru, sehingga memungkinkan pemuatan driver kernel tanpa tanda tangan
- Virtualization-based Security bergantung pada kunci UEFI dan pengaturan registri, sehingga pada konfigurasi tanpa flag Mandatory, modifikasi registri atau penggantian file inti dapat menjadi jalur bypass
- Microsoft sedang mengembangkan pembaruan keamanan yang membuang file sistem VBS lama, tetapi waktu rilisnya belum jelas karena penyelidikan versi yang terdampak, uji kompatibilitas, dan pencegahan regresi
Serangan downgrade yang melumpuhkan status patch terbaru
- Penyerang dapat mengendalikan proses Windows Update untuk memasukkan kembali komponen lama yang rentan ke sistem yang terlihat mutakhir
- Sistem operasi tetap tampak sepenuhnya ditambal, tetapi sebenarnya kembali terpapar celah yang sebelumnya sudah diperbaiki
- Target downgrade mencakup DLL, driver, dan NT kernel
- Alon Leviev merilis alat Windows Downdate untuk menunjukkan bahwa downgrade kustom dapat dibuat
Bypass Driver Signature Enforcement dan risiko rootkit
- Leviev menunjukkan bahwa bypass Driver Signature Enforcement(DSE) masih dimungkinkan bahkan setelah keamanan kernel diperkuat
- Jika bypass DSE berhasil, penyerang dapat memuat driver kernel tanpa tanda tangan
- Driver semacam ini dapat digunakan untuk menyebarkan malware rootkit yang menonaktifkan kontrol keamanan dan mempersulit deteksi kompromi
- Leviev menyebut metodenya sebagai bypass DSE
"ItsNotASecurityBoundary"- Metode ini berupa downgrade terhadap eksploit ItsNotASecurityBoundary
- Eksploit tersebut memanfaatkan kelas kerentanan Windows berupa false file immutability yang diidentifikasi oleh Gabriel Landau dari Elastic, sehingga memungkinkan eksekusi kode arbitrer dengan hak kernel
Penggantian ci.dll dan syarat reboot
- Dalam riset baru, Leviev menunjukkan bahwa penyerang dengan hak administrator dapat menyalahgunakan proses Windows Update untuk membypass perlindungan DSE bahkan pada Windows 11 yang sepenuhnya diperbarui
- Intinya adalah mengganti ci.dll yang menegakkan DSE dengan versi belum ditambal yang mengabaikan tanda tangan driver
- Setelah komponen diturunkan ke versi rentan, sistem perlu di-restart seperti dalam proses pembaruan normal
- Leviev merilis demonstrasi yang membalik patch DSE melalui downgrade pada sistem Windows 11 23H2 yang sepenuhnya ditambal, lalu mengeksploitasi komponen tersebut
Jalur bypass yang terbuka saat konfigurasi VBS lemah
- Leviev juga membahas cara menonaktifkan atau membypass Virtualization-based Security(VBS) milik Microsoft
- VBS membuat lingkungan terisolasi untuk melindungi sumber daya wajib dan aset keamanan Windows
- Target perlindungannya mencakup skci.dll, mekanisme integritas kode kernel keamanan, serta kredensial pengguna yang telah diautentikasi
- VBS umumnya bergantung pada perlindungan seperti kunci UEFI dan konfigurasi registri
- Jika VBS tidak dikonfigurasi dengan flag “Mandatory”, yang merupakan pengaturan keamanan tertinggi, maka VBS dapat dinonaktifkan lewat modifikasi kunci registri yang ditargetkan
- Jika VBS hanya diaktifkan sebagian, file inti VBS seperti SecureKernel.exe dapat diganti dengan versi yang telah dikompromikan untuk mengganggu operasi VBS
- Kondisi ini dapat membuka jalur menuju bypass “ItsNotASecurityBoundary” dan penggantian ci.dll
Respons Microsoft dan celah yang masih tersisa
- CVE-2024-21302 dan CVE-2024-38202 yang digunakan dalam serangan downgrade yang dipublikasikan di BlackHat dan DEFCON telah ditangani, tetapi masalah pengambilalihan Windows Update masih tersisa
- Microsoft menilai masalah ini tidak melampaui batas keamanan yang didefinisikan, dan menganggap memperoleh eksekusi kode kernel dengan hak administrator bukan pelanggaran batas keamanan
- Leviev menekankan bahwa hingga Microsoft memperbaiki masalah ini, solusi keamanan harus memantau dan mendeteksi serangan downgrade
- Microsoft menyatakan sedang aktif mengembangkan mitigasi untuk mencegah risiko tersebut
- Perusahaan sedang mengembangkan pembaruan keamanan yang membuang file sistem VBS lama dan belum ditambal
- Proses ini mencakup investigasi semua versi yang terdampak, pengembangan pembaruan, dan pengujian kompatibilitas
- Kegagalan integrasi atau regresi harus dihindari untuk melindungi pelanggan dan meminimalkan gangguan operasional
- Karena kompleksitas masalah, waktu penyediaan pembaruan masih belum jelas
- Dalam pembaruan 27 Oktober, diperjelas bahwa serangan ini memerlukan hak administrator, dan ditambahkan informasi untuk mengurangi kebingungan bahwa Microsoft tidak mengambil langkah mitigasi
1 komentar
Opini Hacker News
MS mengatakan UAC bukan batas keamanan, dan ini soal sebagian pengguna naik ke hak administrator
Namun, seperti pada kasus ini, perpindahan dari administrator ke kernel juga disebut bukan batas keamanan, sementara pada saat yang sama pemberlakuan penandatanganan driver disebut sebagai fitur keamanan
Di sini justru fitur itu yang dilewati, tetapi tetap dikatakan tidak melintasi batas keamanan; saya ingin mereka menjelaskannya secara konsisten
UAC ditujukan untuk pengguna yang sudah termasuk dalam grup administrator, bukan fitur untuk “membuat sebagian pengguna menjadi administrator”
Batas keamanan ada di sekitar pengguna standar, bukan pengguna administrator
Mungkin Anda tidak menyukainya, tetapi jika menginginkan batas keamanan, jangan masukkan pengguna ke grup Administrators
Menurut saya, konflik pendapat umumnya terjadi karena ketidakselarasan definisi dan ketidakselarasan sistem nilai
Dalam kasus ini, Microsoft menilai penting untuk mengecilkan masalah ini, dan jika itu berada di prioritas paling atas, keputusan mereka bisa terlihat konsisten menurut tolok ukur tersebut
Ketidakselarasan definisi relatif lebih mudah diselesaikan. Misalnya, dalam membahas desain sistem perangkat lunak, semua orang memakai istilah design pattern, tetapi jika masing-masing memahami A secara berbeda sebagai A′ atau A″, kebingungan besar bisa muncul
Hal yang sama berlaku untuk perangkat lunak open source yang dikelola perusahaan
Pertanyaan sebenarnya adalah mengapa orang-orang mencurahkan energi intelektual untuk riset keamanan gratis bagi Microsoft, bukannya memperbaiki desktop Linux
UAC dan sudo sama-sama lebih mirip jendela persetujuan cookie di tingkat sistem operasi, dan menurut saya ketiganya lebih baik dihapus
Tinggalkan model eskalasi hak berbasis pengguna seperti UAC/sudo, dan seperti Android serta iOS, yang harus di-sandbox bukan pengguna, melainkan aplikasi
Menarik juga bahwa di Windows maupun Linux, akun lokal dengan hak biasa pada kenyataannya hampir bertindak seperti hak yang setara root
Di Linux, pengguna dilatih untuk menambahkan sudo di depan pekerjaan terkait sistem, sementara di Windows pengguna dilatih untuk melewati prompt UAC dengan mengkliknya
Kapan terakhir kali sudo berkata “tidak boleh” kepada seseorang karena alasan selain salah ketik kata sandi?
UAC sedikit lebih baik karena UAC adalah UI yang dikelola sistem, sedangkan sudo hanyalah program, sehingga penyerang bisa mengganti sudo dengan alias shell berbahaya untuk mencuri kata sandi
Pada pengaturan bawaan, lebih baik menghapus sudo dan UAC, dan tidak berpura-pura bahwa ada batas keamanan yang kuat antara root dan akun lokal pengguna utama; itu lebih nyaman bagi pengguna sekaligus lebih sesuai dengan kondisi keamanan sebenarnya
Di terminal pun pkexec bisa digunakan sebagai pengganti sudo
Alih-alih menjalankan perintah sembarang sebagai root, aplikasi bisa memakai tindakan yang sudah ditentukan sebelumnya seperti
org.freedesktop.udisks2.filesystem-mount, lalu menampilkan kepada pengguna, dalam pesan yang dilokalkan, apa yang ingin dilakukan aplikasi agar pengguna bisa memutuskan apakah akan mengizinkannyaAdministrator sistem juga dapat mengatur agar tindakan tertentu, seperti pembaruan flatpak, tidak memerlukan autentikasi, atau sebaliknya memblokir tindakan tertentu sepenuhnya
Saya melihat ada asumsi bahwa pengguna yang melakukan instalasi harus mengendalikan sistem. Toh sejak awal ia juga bisa saja tidak menginstalnya
Seperti UAC, sudo bukan alat untuk mengatakan “tidak boleh” kepada seseorang. Keduanya dibuat agar manusia bisa mengatakan “tidak boleh” ketika administrator mencoba melakukan pekerjaan administratif yang tidak ia duga
Orang yang tidak punya hak administrator tetapi membutuhkan pekerjaan seperti itu harus mendapat persetujuan administrator
Jika bukan sistem untuk satu orang, orang yang menyiapkan mesin harus membuat akun terbatas untuk penggunaan sehari-hari
Saya jarang perlu menjadi root, dan ketika perlu biasanya ada beberapa pekerjaan yang dilakukan berurutan
Menurut saya sudo berguna di komputer multi-pengguna, seperti komputer milik dan dikelola perusahaan, ketika administrator ingin mengizinkan sebagian pengguna melakukan hanya pekerjaan berhak istimewa yang terbatas
Alasan utama selalu memakai akun selain root lebih untuk mencegah kesalahan daripada keamanan. Tujuannya menghindari penghapusan atau penimpaan file yang tidak dimaksudkan
Jadi, sesekali harus memasukkan kata sandi untuk berganti peran menurut saya cukup bisa dibenarkan
Hanya saja tidak ada trik “tekan ctrl+alt+delete untuk mengonfirmasi”
Windows punya keunggulan karena tidak semua hal perlu dibuat sebagai skrip
Jika mau, semua tool bisa dibungkus dengan
runas/System.Management.Automation.PSCredential, tetapi dalam kebanyakan kasus itu tidak perluTampaknya kernel menerapkan aturan berbagi file dengan menelusuri semua handle file yang terbuka saat membuka file untuk memeriksa mandatory locking yang bentrok, tetapi tidak memeriksa memory mapping yang memiliki hak bentrok
Ini memang kesalahan, tetapi perbaikannya tampak relatif sederhana
Menariknya, Linux baru saja menghapus sisa terakhir mandatory locking. Kini menulis ke executable yang sedang dimuat tidak lagi menghasilkan EBUSY
Menarik bahwa fitur yang sama di satu sistem operasi menjadi bagian yang menopang beban infrastruktur keamanan, sementara di sistem operasi lain menjadi sisa legacy yang harus dihapus
Saya bukan pakar keamanan dan hanya memahami hal-hal dasar, tetapi rasanya ada model konseptual yang terlewat
Saya penasaran kenapa Windows begitu mudah diretas
Windows adalah target yang menguntungkan, terutama karena merupakan sistem operasi desktop yang paling luas dipakai di lingkungan perusahaan, sehingga banyak waktu dan investasi dicurahkan untuk membobolnya
Investasi untuk membuat platform komputasi yang benar-benar aman belum dilakukan secara memadai
Platform keamanan yang ideal seharusnya menyediakan build yang reproducible di atas infrastruktur yang dapat diverifikasi secara publik seperti fdroid, memvirtualisasikan semua aplikasi yang tidak tepercaya di dalam sandbox, dan menerapkan model least privilege
Saat ini kondisinya adalah yang terburuk dari sisi keamanan. Di semua ring, mulai dari ME pada CPU, komponen UEFI, hingga driver pihak ketiga di sistem operasi, berjalan kode tidak aman yang tidak jelas asal-usulnya dan kemungkinan belum cukup diuji
SeL4 memiliki kernel yang sepenuhnya terverifikasi, tetapi belum melakukan virtualisasi
Sebagian besar malware Windows pada suatu titik bergantung pada driver kernel pihak ketiga yang rentan
Sebaliknya, di Linux modul kernel pihak ketiga jarang dan dipandang buruk, sedangkan di macOS sama sekali dilarang
Dan terlalu mudah meyakinkan pengguna untuk menjalankan apa saja dengan hak yang ditinggikan
Baru ditangani pada 2022 setelah analis CERT Will Dormann menanyakan alasannya
Sekarang memang diperbarui secara rutin, tetapi ini benar-benar tidak masuk akal https://www.bleepingcomputer.com/news/microsoft/microsoft-fi...
Untuk kasus ini, saya cukup setuju dengan posisi Microsoft
Administrator bisa melakukan apa saja pada komputer, dan itu bukan hal baru
Saya tidak tahu apakah ada perbedaan detail yang membuat tingkat keparahannya lebih tinggi
Tulisan Raymond Chen yang merangkum jenis serangan seperti ini juga layak dibaca
https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
Jika seseorang sudah bisa mengganti DLL arbitrer di sistem, prasyarat agar “exploit” ini bekerja sudah terpenuhi, dan pada titik itu semuanya bisa dibilang sudah berakhir
Kemampuan melewati tanda tangan driver mungkin termasuk hal yang paling kecil di antara berbagai kekhawatiran
Serangannya terlihat mencurigakan karena terlalu sederhana
Caranya adalah mengelabui proses update agar memasang komponen kernel lama yang memiliki kerentanan yang sudah diketahui
Bahkan yang bukan pakar pun rasanya akan bertanya-tanya apakah Microsoft seharusnya sudah memikirkan hal seperti ini dan memiliki daftar blokir atau mekanisme deprecation
Intinya adalah apakah akar penyebabnya masalah desain sistem operasi, atau kegagalan proses karena hash yang rusak atau buruk tidak dicatat di lokasi yang benar
Jika yang terakhir, itu jauh lebih mudah diperbaiki, tetapi seperti biasa, pengumuman keamanan yang agak dipoles tampaknya mengarah ke yang pertama
Sulit dipercaya Microsoft membantahnya padahal ada demo
Akun Vimeo itu juga punya banyak temuan keamanan lain. Misalnya ada yang menunjukkan WhatsApp menjalankan skrip Python; saya penasaran apakah itu sungguhan atau penipuan
Ada kriteria bahwa “proses administrator dan pengguna dianggap sebagai bagian dari trusted computing base (TCB) Windows, sehingga tidak diisolasi secara kuat dari batas kernel” [0]
Ada juga contoh lain yang lebih baru
https://arstechnica.com/security/2024/03/hackers-exploited-w...
[0] https://www.microsoft.com/en-us/msrc/windows-security-servic...
Saya teringat kerepotan yang dialami semua orang saat Microsoft pertama kali mewajibkan driver signing di Windows [1]
Saat itu kami sedang membuat driver deep packet inspection untuk [2], dan pada pandangan pertama prosedurnya tampak bahkan lebih ketat daripada persetujuan aplikasi Apple Store, sementara dokumentasinya sama sekali tidak jelas
Mengingat sumber daya yang dicurahkan perusahaan-perusahaan untuk memenuhi persyaratan Microsoft, fakta bahwa ini disalahgunakan dengan cara seperti ini terasa seperti kemunduran besar
Kerentanan memang selalu ada, tetapi akan lebih menenangkan jika ada seseorang yang menemukannya lebih awal
Apresiasi untuk Alon Leviev dan SafeBreach yang menemukannya
[1] https://www.nektra.com/
[2] https://www.verizon.com/business/en-nl/products/security/man...
Ungkapan “dimungkinkan dengan memperoleh eksekusi kode kernel sebagai administrator” pada akhirnya hanyalah cerita biasa bahwa pengguna root bisa memasang rootkit
Jangan lupa memberinya nama yang keren. Ah, penelitinya sudah merilis alat bernama Windows Downdate
Karena sudah mendapatkan ketenaran selama 0xF menit, bisa dibilang cukup berhasil
Akun pengguna pun hanyalah objek di dalam sistem operasi, dan meskipun membatasi akun superuser, kita bisa merancang sistem operasi yang memaksakan aturan tertentu pada semua akun pengguna
Misalnya, bahkan saat akun administrator dibobol, mungkin ada alasan sah untuk melindungi rahasia tertentu seperti TPM, atau mencegah administrator secara tidak sengaja merusak sistem hingga tidak bisa boot
Tujuan yang lebih kontroversial juga mencakup pemaksaan DRM
Inilah tepatnya yang ingin dilakukan Microsoft di Windows. Sistem operasi berusaha mencegah akun administrator mencampuri kernel atau memasang rootkit
Dalam diskusi ini, selalu penting untuk membedakan akun pengguna administrator di dalam sistem operasi dengan orang “administrator” yang memiliki akses fisik dan perangkat keras
0xFMemang tidak salah, tetapi pilihannya terasa agak unik sehingga membuat penasaran. Saya bertanya-tanya apakah itu sekadar soal gaya
Saat harus memakai Windows, saya selalu menganggap komputer itu sudah dibobol