Peneliti keamanan mengatakan Microsoft membuat backdoor BitLocker dan merilis eksploit

 (techspot.com)
4 poin oleh GN⁺ 25 hari lalu | 2 komentar | Bagikan ke WhatsApp
  • Peneliti keamanan Nightmare-Eclipse merilis YellowKey dan menyatakan bahwa enkripsi volume penuh BitLocker dapat dilewati sepenuhnya tanpa kata sandi
  • YellowKey dapat direproduksi dengan menyalin folder FsTx ke drive USB dengan sistem file yang kompatibel dengan Windows, lalu mengikuti urutan tertentu di WinRE
  • Setelah prosedur selesai, shell perintah akan terbuka dan memungkinkan penelusuran volume yang dilindungi BitLocker, penyalinan, serta operasi file lainnya
  • Nightmare-Eclipse mengangkat kemungkinan adanya backdoor yang disengaja, dengan mengatakan bahwa perilaku bypass hanya muncul pada image WinRE resmi
  • Target yang terdampak disebutkan mencakup Windows 11, Server 2022, Server 2025, dan ditambahkan bahwa Windows 10 tidak terdampak

Kondisi kerja YellowKey

  • Peneliti keamanan Nightmare-Eclipse merilis YellowKey dan menyatakan bahwa enkripsi volume penuh BitLocker dapat dilewati sepenuhnya
  • YellowKey dapat direproduksi dengan menyalin folder FsTx yang disertakan ke drive USB yang diformat dengan sistem file kompatibel Windows seperti NTFS, FAT32, atau exFAT
  • Disebutkan bahwa tanpa drive USB pun ini dapat bekerja dengan menyalin file FsTx ke partisi EFI Windows dan melepaskan disk terenkripsi dari sistem untuk sementara
  • Setelah itu, sistem yang dilindungi BitLocker harus di-boot ulang dan masuk ke Windows Recovery Environment (WinRE), lalu mengikuti urutan input tertentu
  • Jika prosedur diselesaikan dengan tepat, shell perintah akan muncul dan memungkinkan penelusuran serta penyalinan volume yang dilindungi BitLocker, atau menjalankan operasi file lain tanpa kata sandi

Dasar dugaan backdoor

  • Nightmare-Eclipse menyatakan bahwa YellowKey tampak tidak lazim untuk dianggap sebagai bug keamanan yang sebelumnya tidak diketahui, dan mengangkat kemungkinan bahwa Microsoft telah menaruh backdoor yang sah di sistem perlindungan data BitLocker
  • Dasarnya adalah bahwa komponen yang memicu masalah hanya ditemukan pada image WinRE resmi
  • Komponen yang sama juga ada di image instalasi Windows standar, tetapi disebutkan bahwa perilaku bypass BitLocker yang diamati pada sistem nyata tidak muncul
  • Nightmare-Eclipse mengatakan, “Saya tidak bisa memikirkan penjelasan selain fakta bahwa ini memang disengaja,” dan menambahkan bahwa Windows 10 tidak terdampak, sedangkan hanya Windows 11, Server 2022, Server 2025 yang terdampak

Verifikasi eksternal dan pengungkapan tambahan

  • Disebutkan bahwa peneliti pihak ketiga telah mengonfirmasi bahwa YellowKey bekerja sesuai cara yang tertulis pada materi GitHub milik Nightmare-Eclipse
  • Nightmare-Eclipse juga merilis eksploit kedua, GreenPlasma, yang diketahui memungkinkan peningkatan hak akses
  • GreenPlasma tidak merilis kode proof-of-concept lengkap untuk mencapai akses tingkat SYSTEM, dan mengisyaratkan bahwa detail tambahan dapat diungkap sebelum Patch Tuesday bulan depan

Arah mitigasi

  • Disampaikan bahwa mitigasi untuk dugaan perilaku backdoor pada YellowKey relatif sederhana
  • Pakar keamanan merekomendasikan untuk tidak hanya bergantung pada satu sistem enkripsi, dan juga mengevaluasi alternatif enkripsi seluruh disk yang telah ditinjau dengan baik
  • Sebagai contoh, VeraCrypt disebutkan

Bacaan terkait

2 komentar

 
GN⁺ 24 hari lalu
Komentar Lobste.rs
  • Frasa dalam artikelnya terdengar seolah ini juga bisa melewati perlindungan berbasis kata sandi, tapi sepertinya tidak begitu
    Backdoor ini diketahui memerlukan WinRE untuk membuka kunci drive agar bisa bekerja (posting sebelumnya), dan jika drive dilindungi kata sandi, tampaknya kata sandi itu tetap harus dimasukkan
    Kemungkinan target sebenarnya adalah BitLocker transparan yang hanya mengandalkan TPM dan tidak memakai kata sandi enkripsi disk. Dalam keadaan ini Windows penuh sudah lebih dulu boot, kunci enkripsi sudah ada di memori, dan hanya layar login yang mencegah akses, jadi tidak aman seperti yang terdengar
    Karena penyerang sudah berada di dalam Windows, permukaan serangannya sangat besar, dan selain “bugdoor” dari OP, sudah ada berbagai bug lain yang memungkinkan layar login dilewati. Selain itu, orang juga bisa mengendus bus TPM atau mengekstrak kunci dari memori lewat serangan cold boot
    Tentu ini tetap patut dikhawatirkan, tetapi ini tampaknya memang cara penggunaan BitLocker yang direkomendasikan, dan pengguna biasa tidak benar-benar diberi tahu risikonya saat tidak memakai kata sandi nyata untuk enkripsi disk. Namun, menurut saya kerentanan ini hanya berlaku bila BitLocker dipakai dengan cara yang pada dasarnya memang tidak aman, dan hanya membuat serangan yang sudah ada menjadi sedikit lebih mudah
    Tentu ceritanya berbeda kalau WinRE bisa secara ajaib membuka drive yang dienkripsi dengan kata sandi, tetapi kalau memang begitu rasanya seseorang sudah akan menyadarinya sejak beberapa tahun lalu
    • https://deadeclipse666.blogspot.com/2026/05/…
      “Kedua, tidak, TPM+PIN juga tidak membantu. Masalah ini tetap bisa dieksploitasi. Saya juga sempat bertanya pada diri sendiri, ‘Apakah ini juga bekerja di lingkungan TPM+PIN?’ dan jawabannya ya. Hanya saja saya tidak akan merilis PoC untuk itu. Menurut saya, yang sudah dipublikasikan saja sudah cukup buruk”
  • Sumber primer: https://github.com/Nightmare-Eclipse/YellowKey
  • Sejak TrueCrypt menghilang dengan cara yang sangat mencurigakan dan orang-orang malah disarankan memakai BitLocker, rasanya sudah jelas ada sesuatu di baliknya
    Dengan kata lain, sejak Paul Le Roux ditangkap atas kejahatan narkoba dan pembunuhan bayaran lalu mulai bekerja sama dengan pihak berwenang, pengguna TrueCrypt seolah diarahkan ke perangkat lunak yang memiliki backdoor
    • TrueCrypt dihentikan pada 2014, sedangkan backdoor ini muncul di Windows 11
      Menurut Wikipedia, Le Roux ditangkap pada 2012, jadi linimasa itu tampaknya tidak cocok
    • Sepemahaman saya, TrueCrypt memang berbasis E4M, tetapi Paul Le Roux tidak terlibat dalam TrueCrypt. Mengapa pengguna TrueCrypt harus mengikuti sarannya?
    • Saya ingat betapa mencurigakannya rekomendasi TrueCrypt saat itu. Pada 2014 hal ini juga dibahas di HN
      https://news.ycombinator.com/item?id=7812133
  • Jika kuncinya otomatis dicadangkan ke cloud, saya jadi berpikir kenapa harus repot menanam backdoor yang disengaja, kalau kunci pemulihan bisa diambil dengan mudah dari sana?
    • Bisa saja ada orang yang memakai BitLocker di lingkungan perusahaan, atau memakainya tanpa akun Microsoft
      Kalau mau memakai topi teori konspirasi yang makin terasa masuk akal, permintaan kunci cloud bisa meninggalkan jejak dan mungkin juga memerlukan persetujuan hukum
  • Apakah ada linimasa kapan ini diam-diam ditambal?
    Setelah memasang pembaruan Windows sekitar akhir April, saya sama sekali tidak bisa lagi mendekripsi volume BitLocker dengan PIN. Kode pemulihan masih berfungsi, tetapi PIN terus dianggap salah meskipun sudah diatur ulang berkali-kali
    Pada akhirnya saya tidak pernah menemukan penyebabnya dan malah memasang ulang Windows. Bug itu cukup menjengkelkan, dan kebetulannya juga lucu
  • Tidak bisa sekadar berkata “seseorang membuat klaim serius X” lalu mengemasnya seolah itu artikel berita
    Kalau saya memposting di suatu tempat bahwa ada backdoor di ECDSA, tempat yang bukan pemburu klik tidak akan menulisnya sebagai berita
    • Ada tautan ke PoC yang nyata di bagian lain thread ini. Walaupun itu tidak bisa melewati bagian BitLocker yang “menarik”, itu sendiri tetap cukup layak diperhatikan
      Mencurigai bahwa ini sampai taraf tertentu adalah backdoor yang disengaja juga bukan lompatan yang terlalu liar, tetapi itu tetap spekulasi
      Bagian yang belum ada buktinya adalah klaim bahwa BitLocker yang dikonfigurasi terpisah dengan PIN juga bisa dilewati. Ini tidak muncul di artikelnya
      Orang ini tampaknya punya rekam jejak yang cukup baik dalam menemukan kerentanan Windows, jadi bahkan tanpa PoC pun menurut saya ini klaim yang patut dicermati
  • Apakah ini benar-benar mengejutkan bagi siapa pun?
    • Saya justru akan benar-benar terkejut kalau ternyata Microsoft tidak menanam backdoor di sesuatu
      Jelas saja, apa pun yang perlu dilindungi dari pencurian sama sekali tidak boleh disimpan di Windows. Jangan gunakan Windows untuk perbankan, investasi, pajak, email, hosting, belanja, atau urusan pribadi
      Windows hanya seharusnya dipakai untuk (i) game dan (ii) build untuk Windows
 
GN⁺ 25 hari lalu
Opini di Hacker News

  • Dari tulisan peneliti yang menemukan kerentanan ini, Nightmare-Eclipse, tampaknya ini sudah berlanjut sejak hampir seminggu lalu
    Pada Selasa, 12 Mei 2026, ia menulis “kali ini ada dua kerentanan [YellowKey] [GreenPlasma] [...] Microsoft akan mendapat kejutan besar pada Patch Tuesday berikutnya”, dan pada Rabu, 13 Mei, ia menulis “begitu saya bisa mengungkap seluruh ceritanya, orang-orang akan melihat bahwa ledakan emosi saya cukup masuk akal, dan ini juga sama sekali tidak akan terlihat baik bagi Microsoft”
    Blog penulis: https://deadeclipse666.blogspot.com/
    Dalam tulisan pertamanya pada Maret 2026, ada isi seperti “seseorang melanggar kesepakatan kami, dan saya jatuh miskin serta kehilangan rumah. Mereka menikam saya dari belakang meski tahu ini akan terjadi. Ini bukan keputusan saya, ini keputusan mereka”
    Saya tidak tahu harus memandang ini bagaimana, tetapi terdengar seperti orang dalam yang pada dasarnya sedang “membocorkan” sesuatu, dan orang lain tampaknya juga bisa mereproduksi hasilnya

    • Saya membacanya bukan sebagai orang dalam, melainkan seseorang yang sedang menjalani proses pengungkapan kerentanan dengan Microsoft lalu karena suatu alasan marah dan akhirnya membukanya ke publik
    • Ini sudah dibahas beberapa kali di HN, misalnya di sini: https://news.ycombinator.com/item?id=48130519
      Apakah ini backdoor atau bukan pada akhirnya tergantung pada bagaimana biasanya Anda memandang “bug atau backdoor”, dan ini bukan cerita sederhana ala media teknologi seperti “Microsoft kena, BitLocker diretas”
      Intinya adalah bug pada fitur replay log transaksi NTFS di Windows Recovery Environment WinRE, yang memungkinkan log transaksi NTFS dari volume eksternal dibaca dan diterapkan ke filesystem yang ter-mount. Akibatnya, penyerang bisa melewati autentikasi WinRE
      Pada BitLocker tanpa PIN atau kata sandi, bypass autentikasi apa pun berarti bypass enkripsi disk. Alasannya, bootloader sudah lebih dulu melakukan unseal terhadap disk, dan “cacat” struktural seperti ini juga ada di Linux dengan konfigurasi yang sama. Misalnya pada kasus memakai kotak centang Hardware Disk Encryption yang relatif baru ditambahkan di installer Ubuntu
      Tanpa bukti tambahan, apakah masalah log transaksi NTFS ini adalah backdoor yang sengaja ditanam atau sekadar bug enumerasi biasa tergantung pada tingkat teori konspirasi yang umum dalam pengembangan exploit. Menurut saya pribadi ini tampak seperti bug yang masuk akal, dan kelemahan unseal saat boot sudah dikenal luas dan cukup jelas, jadi saya tidak melihat ini sebagai pengungkapan yang mengguncang dunia, tetapi tetap bug yang menarik
    • Saya ingin cepat-cepat membaca tulisan blognya tentang apa yang sebenarnya terjadi dan mengapa orang ini sampai membongkar M$ seperti ini

  • Ringkasan yang lebih baik: https://infosec.exchange/@wdormann/116565129854382214
    Exploit yang dipublikasikan tidak memengaruhi BitLocker yang memakai PIN. Tanpa PIN, BitLocker memang pada dasarnya tidak aman
    Penulis aslinya mengklaim punya exploit yang tetap bekerja meski ada PIN, tetapi sejauh ini belum menunjukkan buktinya

    • Apakah perusahaan mewajibkan PIN? Lebih penting lagi, apakah perusahaan asuransi siber yang dibayar perusahaan mewajibkan PIN?
      Saya belum pernah melihat perusahaan yang mewajibkan PIN untuk BitLocker
    • Di BitLocker ada tingkat di atas PIN, yaitu bisa memakai USB stick yang menyimpan kunci yang hanya dipakai saat boot. Karena datanya tidak disimpan di perangkat, sepertinya ini aman dari serangan ini
    • Jika kita anggap klaim versi PIN itu benar, menarik juga mengapa yang dirilis justru versi yang dilemahkan dan kurang berguna, bukan versi PIN. Saya punya beberapa dugaan, tapi semuanya tanpa dasar

  • Sumber: https://infosec.exchange/@wdormann/116565129854382214
    “Sesi WinRE biasa memiliki direktori X:\Windows\System32 dan di dalamnya ada file winpeshl.ini”
    “Tetapi pada exploit YellowKey, fragmen Transactional NTFS dari drive USB tampaknya dapat menghapus file winpeshl.ini di drive lain”
    Menarik. Saya tidak terlalu paham lingkungan ini, tetapi apakah ini masalah naif dalam membuat atau meneruskan file handle? Kalau begitu, mengapa perlu input keyboard saat reboot WinRE?
    Saya juga penasaran sejauh mana patch memungkinkan. Banyak sekali drive USB WinRE yang tak akan bisa disentuh, jadi mungkinkah sisi BitLocker yang diperbarui hak aksesnya? Apakah perlu decrypt/encrypt ulang? Rasanya masih akan banyak lanjutan soal ini

    • Bagian yang hilang adalah mengapa WinRE punya otorisasi. Windows menyimpan kunci dekripsi di TPM, sehingga WinRE bisa mendekripsi disk tanpa recovery key
      Karena itu serangan ini tidak bisa dilakukan dengan boot dari Ubuntu live CD atau semacamnya, melainkan membutuhkan WinRE
      Selain itu, tidak perlu menambal semua drive USB WinRE yang sudah ada. Jika tanda tangan Secure Boot dicabut, ia tidak akan lolos verifikasi TPM, dan karena itu tidak akan bisa mendekripsi disk mana pun

  • “Para pakar keamanan umumnya menyarankan agar tidak bergantung pada satu sistem enkripsi saja dan mengevaluasi alternatif full-disk encryption yang telah ditinjau dengan baik seperti VeraCrypt”
    Jika mereka benar-benar menanam backdoor di FDE, akan lebih masuk akal menyuruh orang berhenti memakai Windows sama sekali dan beralih ke Linux
    Jika mereka menaruh backdoor di FDE, maka kita juga harus berasumsi sistem operasinya sendiri tidak cuma punya satu backdoor. Perangkat lunak proprietari sama sekali tak boleh dipercaya, dan open source yang belum diaudit dengan baik juga tak boleh dipercaya

    • Saya memang umumnya tidak memakai produk Microsoft, tetapi bahkan di komputer Anda sendiri saya tetap tidak akan menjalankan VeraCrypt
    • Atau cukup pakai sesuatu yang open source seperti VeraCrypt

  • Ini tampaknya bukan masalah khusus BitLocker, melainkan lebih mirip bypass login. Jika hanya mengandalkan TPM tanpa PIN, disk akan didekripsi secara otomatis
    Biasanya ini seharusnya baik-baik saja karena penyerang tetap tidak bisa melewati layar login, tetapi exploit ini tampaknya menunjukkan cara mendapatkan shell tanpa batas di lingkungan pemulihan
    Peneliti itu mengklaim ia juga punya cara untuk melewati PIN, tetapi belum dipublikasikan

    • Karena tidak mendapat bayaran dari proses pengungkapan, mungkin ia memutuskan lebih baik menjualnya ke seseorang yang mau membayar

  • Kapan para profesional keamanan akan mulai menolak peran “keamanan produk Microsoft”? Saya sendiri sudah sampai di titik itu
    Keamanan produk Microsoft hanyalah pekerjaan sibuk sampai akhirnya runtuh lagi diterjang gelombang berikutnya dari utang teknis gila dan kerakusan MS. Sekarang bahkan ada backdoor juga

    • Itu bukan peran “keamanan”, melainkan peran kepatuhan. Bagi kebanyakan pelanggan perusahaan, hanya itu yang benar-benar mereka pedulikan
      Mereka sudah memenuhi semua aturan kepatuhan dan mengikuti “best practice” yang dipengaruhi MS, jadi apa pun yang terjadi nanti tidak dianggap sebagai kesalahan mereka
    • iOS juga secara default membuat backup iCloud yang tidak terenkripsi end-to-end, sehingga aparat penegak hukum bisa meminta chat, riwayat browsing, dan sebagainya. Signal adalah pengecualian yang menonjol
      Memang bisa mengaktifkan ADP untuk backup terenkripsi end-to-end, tetapi kemungkinan besar lawan bicara Anda tidak mengaktifkannya, jadi itu mungkin tidak banyak membantu
      Bukan bermaksud membela Microsoft, tetapi intinya semua perusahaan seperti ini sama-sama bagian dari PRISM
    • Di pasar enterprise, uang yang dihasilkan dari ini terlalu besar, jadi saya rasa orang tidak akan mulai menolak pekerjaan hanya karena merasa repot
    • “Sekarang bahkan ada backdoor”? “Sekarang”?
      Mau bicara soal kenapa pada suatu versi lama Windows NT, ketika Microsoft tanpa sengaja merilisnya dengan debug symbol aktif, nama kunci yang mereka klaim sebagai “kunci tambahan” itu ternyata ..._NSAKEY?
      Hanya sekali, benar-benar cuma sekali, Windows dirilis dengan debug symbol aktif, dan kebetulan nama kunci enkripsinya “NSAKEY”
      Tentu saja orang-orang yang terus menutup mata terhadap kesalahan negara akan bilang itu sepenuhnya normal, lalu mengulang alasan “itu bukan backdoor” yang saat itu susah payah dibangun Microsoft

  • Setelah menggali exploit ini sedikit lebih jauh, tampaknya ini menargetkan BitLocker mode TPM-only. Artinya tidak ada autentikasi pra-boot atau semacamnya
    Jika Secure Boot memverifikasi rantai boot, TPM akan mengeluarkan kunci enkripsi dengan sendirinya. Dengan akses fisik, perbedaannya memang tidak besar
    Anda bisa boot dengan USB berisi exploit untuk mendapatkan shell darurat, atau membeli mikrokontroler seharga 5 dolar lalu menyoldernya ke pin tertentu di motherboard untuk menyadap kunci TPM
    Microsoft pada dasarnya menjual sesuatu yang tidak aman sebagai enkripsi disk penuh. Siapa pun yang bisa menaruh exploit di flash drive lalu memperoleh shell untuk menelusuri dan menyalin file juga bisa membeli mikrokontroler dan mengikuti video solder di YouTube
    Jadi masalahnya bukan “exploit”-nya itu sendiri, melainkan rasa aman palsu yang dijual Microsoft

    • Cara “masuk ke shell darurat dengan stik yang bisa di-boot” itu tidak akan berhasil. TPM hanya mengeluarkan kunci saat boot ke sistem operasi yang “disetujui”, tepatnya saat status PCR yang menjadi pengikat kunci enkripsi cocok
      Menyadap kunci TPM dengan mikrokontroler 5 dolar yang disolder ke pin tertentu hanya mungkin pada dTPM. fTPM tidak rentan terhadap ini, dan jauh lebih umum digunakan daripada dTPM
    • Ubuntu juga meluncurkan FDE berbasis TPM beberapa versi lalu. Saat itu saya punya pemikiran yang sama, jadi memutuskan tidak memakainya
      Mengetik passphrase saat boot sudah menjadi muscle memory, dan memberikan keamanan sederhana yang bisa dipercaya
      Data juga masih bisa dipulihkan tanpa motherboard
      Untuk penggunaan harian, mungkin pendekatan hibrida masuk akal: memakai slot gabungan Secure Boot+TPM+passphrase untuk mencegah serangan evil maid, lalu menyiapkan satu slot passphrase cadangan lagi
    • Memang diklaim ada exploit TPM+PIN juga, tetapi apakah itu bisa dipercaya masih harus dilihat
      https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...
    • Linux LUKS juga bisa dikonfigurasi dengan cara yang persis sama
      Ini tampaknya bukan serangan terhadap BitLocker, melainkan terhadap rantai Secure Boot
      Nilai dari unlock tanpa PIN ada ketika model ancamannya terbatas pada pembuangan disk, pelepasan disk, atau pemisahan TPM dan disk
      Jika perangkat dipakai secara rutin oleh banyak pengguna, memasukkan PIN bisa merepotkan atau bahkan mustahil. Karena itu kontrol verifikasi akses dialihkan ke komponen sistem operasi yang dipercaya
    • Ini memang bug yang sangat serius, tetapi BitLocker tetap merupakan enkripsi disk penuh. Hanya saja autentikasinya bisa dibypass

  • Ada yang ingat kalimat “Menggunakan TrueCrypt tidak aman karena mungkin mengandung masalah keamanan yang belum diperbaiki”? ;)

    • Ini mengingatkan pada TrueCrypt/VeraCrypt. Kemungkinan besar itu solusi enkripsi yang lebih aman. Setelah kejadian ini, jelas terlihat lebih aman