Kebocoran "Kunci Emas" baru-baru ini dari Microsoft ditambah dengan kehadiran mode Debug telah memungkinkan boot aman dinonaktifkan pada perangkat Windows. Baca terus!
OS berbasis Windows tidak lagi menjadi default dan pilihan utama di kancah seluler. Sifat Open Source Android telah menemukan banyak penggemar di OEM, dan sebagai hasilnya, semakin sedikit ponsel yang menggunakan Windows saat ini.
Namun jika Anda termasuk orang yang masih terus menggunakan perangkat Windows dalam kehidupan sehari-hari, ada sedikit kabar untuk Anda. Baik atau buruk, itu bergantung pada pendirian dan interpretasi Anda terhadap kasus penggunaan berita ini.
Seperti dilansir oleh Ars Teknik Dan Pendaftaran dengan berita yang berasal dari a situs web yang kemungkinan besar akan membuat Anda pusing (tidak bercanda), beberapa pengembang (@never_released Dan @TheWack0lian) telah menemukan bahwa pintu belakang yang dibuat Microsoft untuk tujuan debug telah membuka kemungkinan untuk menonaktifkan boot aman pada perangkat Windows.
Boot Aman dan apa itu?
Saat Anda pertama kali mem-boot perangkat Windows, prosedur booting berjalan dalam urutan umum ini: UEFI (Unified Extensible Firmware Interface, yang merupakan pengganti BIOS) -> Boot Manager -> Boot Loader -> jendela. UEFI adalah tempat hadirnya fungsionalitas Boot Aman. Sesuai dengan namanya dengan Boot Aman, ini bertujuan untuk meningkatkan keamanan dengan mewajibkan tanda tangan digital pada langkah selanjutnya. Pada dasarnya, jika bootloader tidak ditandatangani dengan kunci yang diharapkan UEFI, prosedur booting perangkat Anda tidak akan selesai.
Boot Aman adalah fitur opsional, tetapi Microsoft telah mewajibkan fitur ini untuk mendapatkan sertifikasi Windows mulai dari Windows 8 dan seterusnya. Alasannya di sini adalah bahwa Boot Aman akan mempersulit pembuat malware untuk memasukkan kode ke dalam prosedur boot. Namun, efek samping dari Secure Boot adalah membuatnya agak rumit untuk melakukan dual-boot pada mesin Windows baik OS kedua dan semua prasyaratnya juga harus ditandatangani secara digital, atau Boot Aman harus dengan disabilitas. Ada banyak masalah lain dalam hal ini, dan pengguna dual-boot berpengalaman akan mengetahuinya lebih banyak daripada yang bisa saya jelaskan dalam satu paragraf.
Sekarang, ada beberapa perangkat yang Boot Amannya tidak dapat dinonaktifkan oleh pengguna meskipun mereka menginginkannya. Ini adalah bidang di mana pokok bahasan kami dipersempit secara drastis dari semua perangkat Windows (termasuk desktop) ke perangkat Windows tertentu seperti perangkat Windows Phone, perangkat Windows RT, beberapa perangkat Surface, dan bahkan Lensa Holo. Perangkat pengguna akhir ini memiliki Boot Aman terkunci, artinya an pengguna akhir tidak dapat mengubah atau menonaktifkan aspek yang terkait dengan Boot Aman, dan lebih jauh lagi, mereka tidak dapat menyentuh OS dengan cara yang tidak diizinkan oleh Microsoft untuk pengguna akhir.
Namun untuk keperluan pengembangan resmi yang sedang berlangsung, Secure Boot perlu sedikit dilonggarkan. Pada perangkat yang Boot Amannya dikunci, terdapat Kebijakan Boot Aman yang dapat membantu pengembangan resmi tanpa perlu menonaktifkan Boot Aman. Seperti yang disebutkan oleh pengguna yang meneliti, file Kebijakan Boot Aman ini dimuat oleh Boot Manager di awal proses boot untuk windows. File Kebijakan juga dapat berisi aturan registri yang pada gilirannya memiliki kemampuan untuk memuat konfigurasi kebijakan itu sendiri. Sekali lagi, file Kebijakan harus ditandatangani dan terdapat ketentuan lain yang berlaku untuk memastikan bahwa hanya Microsoft yang dapat menyediakan perubahan ini.
Elemen penandatanganan juga bergantung pada apa yang disebut DeviceID, yang digunakan saat melamar. Saya akan membiarkan postingan blog menjelaskannya di sini, karena ada beberapa bagian yang tidak begitu jelas bagi saya:
Juga, ada yang disebut DeviceID. Ini adalah 64 bit pertama dari hash SHA-256 asin, dari beberapa keluaran UEFI PRNG. Ini digunakan saat menerapkan kebijakan di Windows Phone, dan di Windows RT (mobilestartup menyetelnya di Phone, dan SecureBootDebug.efi saat diluncurkan pertama kali di RT). Di Ponsel, kebijakan harus ditempatkan di tempat tertentu pada partisi EFIESP dengan nama file termasuk bentuk hex dari DeviceID. (Dengan Redstone, ini diubah menjadi UnlockID, yang diatur oleh bootmgr, dan hanya merupakan keluaran UEFI PRNG mentah).
Pada dasarnya, bootmgr memeriksa kebijakan saat dimuat, jika kebijakan tersebut menyertakan DeviceID, yang tidak cocok dengan DeviceID perangkat yang menjalankan bootmgr, kebijakan akan gagal dimuat. Kebijakan apa pun yang memungkinkan pengaktifan penandatanganan tes (MS menyebut kebijakan Buka Kunci Perangkat Ritel / RDU ini, dan untuk menginstalnya membuka kunci perangkat), seharusnya dikunci ke DeviceID (UnlockID di Redstone dan di atas). Memang saya punya beberapa kebijakan (ditandatangani dengan sertifikat produksi Windows Phone) seperti ini, yang perbedaannya hanya pada DeviceID yang disertakan, dan tanda tangannya. Jika tidak ada kebijakan valid yang diinstal, bootmgr kembali menggunakan kebijakan default yang terletak di sumber dayanya. Kebijakan ini adalah kebijakan yang memblokir pengaktifan penandatanganan tes, dll, menggunakan aturan BCD.
Ini adalah bagian di mana segala sesuatunya menjadi menarik. Selama pengembangan Windows 10 v1607, Microsoft membuat Kebijakan Boot Aman jenis baru (selanjutnya disebut SBP agar singkatnya) untuk tujuan pengujian dan debugging internal. Kebijakan ini bersifat "tambahan" tanpa adanya DeviceID, dan menyebabkan pengaturannya digabungkan ke dalam Kebijakan Boot yang ada. Boot Manager memuat jenis SBP yang lebih lama, lalu memverifikasi penandatanganan dan keasliannya, lalu memuat kebijakan boot tambahan ini. Persoalannya di sini adalah tidak ada verifikasi lebih lanjut mengenai kebijakan tambahan itu sendiri. Selain itu, Manajer Boot sebelum Windows 10 v1511 tidak mengetahui keberadaan sifat tambahan dari kebijakan ini, dan karenanya, bereaksi seolah-olah mereka memuat kebijakan yang benar-benar valid dan ditandatangani. Sekali lagi, perilaku ini kemungkinan besar untuk pengembangan internal, sehingga pengembang tidak perlu menandatangani setiap versi OS dan perubahan kecil yang harus mereka lakukan pada perangkat.
SBP ini disebut sebagai "Kunci Emas" karena pada dasarnya meniadakan tujuan pemeriksaan tanda tangan. SBP ini secara tidak sengaja dikirimkan pada perangkat retail, meskipun dalam keadaan dinonaktifkan. Para pengembang menemukan SBP ini dan mengumumkan temuan mereka. Sekarang, SBP bisa ditemukan beredar di internet, dengan zip khusus ini digunakan untuk menginstal SBP pada perangkat Windows RT.
Apa artinya ini?
Jika Anda memuat SBP tambahan, Anda dapat mengaktifkan penandatanganan pengujian untuk Windows agar Anda dapat memuat driver yang tidak ditandatangani. Selanjutnya, karena Kebijakan ini mulai berlaku sebelum tahap Boot Manager dalam prosedur boot, Anda dapat membahayakan keamanan seluruh pesanan dan menjalankan kode yang tidak sah (baca yang ditandatangani sendiri). Hal ini membuka banyak kemungkinan, bagi pengguna yang ingin memodifikasi bagian Windows di luar otorisasi dan juga bagi pembuat malware.
Para penulis temuan ini fokus pada ironi dari keseluruhan kegagalan tersebut. Microsoft mengunci Boot Aman pada perangkat tertentu untuk mencegah perubahan yang tidak sah, tetapi kemudian membangun pintu belakang agar perubahan dapat dilanjutkan dengan pengembangan dan debugging. Namun pintu belakang ini membuka jalan bagi Boot Aman untuk dinonaktifkan pada semua perangkat yang menjalankan Windows, menjadikan seluruh cobaan ini tidak ada gunanya.
Pengguna yang bersedia sekarang tidak hanya dapat menginstal distro Linux (dan mungkin Android) di Tablet khusus Windows dan Ponsel, pengguna yang tidak mau juga dapat menginstal bootkit berbahaya jika mereka membahayakan akses fisik ke ponsel mereka perangkat. Meskipun yang pertama adalah sesuatu yang bisa kita lakukan, yang terakhir tidak benar-benar menanamkan banyak kepercayaan diri. Hal ini berlaku dua arah dan menunjukkan kepada kita mengapa keamanan adalah pedang bermata dua. Lebih lanjut, SBP bersifat universal, memungkinkan penggunaannya pada perangkat apa pun, apa pun arsitekturnya. Ini tidak terlalu berguna untuk kasus desktop di mana Boot Aman dapat dimatikan dengan mudah, namun cakupannya sangat luas untuk perangkat yang tidak dapat dipusingkan dengan Boot Aman.
Jadi, apa perbaikannya?
Microsoft memang merilis beberapa perbaikan, namun pengembang bersikeras bahwa masalah ini belum sepenuhnya teratasi. Anda dapat memeriksa tambalan ini (MS16-094 Dan MS16-100) dan kemudian membaca di postingan blog sendiri tentang mengapa mereka tidak menyelesaikan masalah tersebut. Jika benar, masalah ini tidak memiliki perbaikan atau patch yang terlihat, meskipun hal itu tidak akan menghentikan Microsoft untuk mencoba memberikan lebih banyak hambatan.
Apa selanjutnya?
Ada banyak sekali kemungkinan, dan beberapa di antaranya muncul di Forum Windows kami. Anda dapat memeriksa forum kami di Pengembangan dan Peretasan Windows Phone 8 dan forum kami untuk Windows 8, Windows RT dan Pengembangan dan Peretasan Permukaan. Anda juga dapat menemukannya utas instruksi untuk beberapa perangkat, di mana pengguna lain mendiskusikan hal yang sama.
Kehadiran backdoor debug dan kebocoran SBP ini penting tidak hanya bagi pihak ketiga saja pengembangan perangkat Windows yang terkunci, mereka juga menunjukkan kepada kita pengingat yang suram tentang apa yang bisa terjadi jika disengaja pintu belakang tertinggal. Fokus baru-baru ini pada keamanan telah beralih ke badan-badan investigasi yang mendesak agar keberadaan pintu belakang tersebut digunakan untuk membantu tujuan investigasi hukum mereka. Tapi cepat atau lambat, metode ini akan jatuh ke tangan yang salah. Apa yang dimaksudkan untuk digunakan sebagai alat untuk memerangi kejahatan dan membantu keadilan, suatu hari nanti akan menjadi alat untuk kejahatan itu sendiri.
Bagaimana pendapat Anda mengenai bocoran Debug SBP ini? Apakah menurut Anda "Kunci Emas" seperti ini seharusnya ada? Beri tahu kami di komentar di bawah!