- Nhà nghiên cứu bảo mật Nightmare-Eclipse đã công bố YellowKey và cho biết có thể vượt qua mã hóa toàn bộ ổ đĩa của BitLocker mà không cần mật khẩu
- YellowKey có thể được tái hiện bằng cách sao chép thư mục FsTx vào ổ USB dùng hệ thống tệp tương thích Windows rồi thực hiện một trình tự cụ thể trong WinRE
- Sau khi hoàn tất quy trình, một command shell sẽ mở ra và được cho là có thể duyệt, sao chép và thao tác tệp trên volume được BitLocker bảo vệ
- Nightmare-Eclipse cho rằng hành vi vượt qua này chỉ xuất hiện trong ảnh WinRE chính thức, từ đó nêu nghi vấn về một backdoor có chủ đích
- Các hệ bị ảnh hưởng được nêu là Windows 11, Server 2022, Server 2025, đồng thời nói thêm rằng Windows 10 không bị ảnh hưởng
Điều kiện hoạt động của YellowKey
- Nhà nghiên cứu bảo mật Nightmare-Eclipse đã công bố YellowKey và cho biết có thể vượt qua hoàn toàn cơ chế mã hóa toàn bộ ổ đĩa của BitLocker
- YellowKey có thể được tái hiện bằng cách sao chép thư mục FsTx đi kèm vào ổ USB được định dạng bằng hệ thống tệp tương thích Windows như NTFS, FAT32 hoặc exFAT
- Cũng có thông tin cho rằng ngay cả khi không có ổ USB, nó vẫn có thể hoạt động nếu sao chép các tệp FsTx vào phân vùng EFI của Windows và tạm thời tháo đĩa đã mã hóa ra khỏi hệ thống
- Sau đó cần khởi động lại hệ thống được BitLocker bảo vệ, vào Windows Recovery Environment (WinRE) rồi thực hiện theo một chuỗi nhập liệu cụ thể
- Nếu quy trình được hoàn tất chính xác, một command shell sẽ xuất hiện, cho phép duyệt, sao chép volume được BitLocker bảo vệ hoặc thực hiện các thao tác tệp khác mà không cần mật khẩu
Cơ sở cho nghi vấn backdoor
- Nightmare-Eclipse cho rằng YellowKey có đặc điểm bất thường nếu xem như một lỗi bảo mật chưa từng được biết đến trước đây, và đặt ra khả năng Microsoft đã cài một backdoor hợp thức vào hệ thống bảo vệ dữ liệu của BitLocker
- Cơ sở được nêu là thành phần gây ra vấn đề chỉ được tìm thấy trong ảnh WinRE chính thức
- Thành phần tương tự cũng tồn tại trong ảnh cài đặt Windows tiêu chuẩn, nhưng theo mô tả thì không xuất hiện hành vi vượt qua BitLocker được quan sát trên hệ thống thực tế
- Nightmare-Eclipse nói rằng “ngoài việc đây là chủ đích thì tôi không thể nghĩ ra lời giải thích nào khác”, đồng thời cho biết Windows 10 không bị ảnh hưởng và chỉ Windows 11, Server 2022, Server 2025 bị tác động
Xác nhận từ bên ngoài và công bố bổ sung
- Có thông tin cho biết các nhà nghiên cứu bên thứ ba đã xác nhận YellowKey hoạt động theo cách được mô tả trong tài liệu GitHub của Nightmare-Eclipse
- Nightmare-Eclipse cũng đã công bố exploit thứ hai là GreenPlasma, được cho là có thể nâng quyền
- GreenPlasma chưa công bố mã proof-of-concept đầy đủ để đạt được quyền truy cập cấp SYSTEM, nhưng có ám chỉ rằng có thể sẽ công bố thêm chi tiết trước Patch Tuesday vào tháng tới
Hướng giảm thiểu
- Việc giảm thiểu nghi vấn hành vi mang tính backdoor của YellowKey được cho là tương đối đơn giản
- Các chuyên gia bảo mật khuyến nghị không nên chỉ phụ thuộc vào một hệ thống mã hóa duy nhất, mà nên đánh giá thêm các giải pháp mã hóa toàn bộ đĩa đã được thẩm định kỹ
- Ví dụ được đưa ra là VeraCrypt
1 bình luận
Ý kiến trên Hacker News
Đọc các bài viết của nhà nghiên cứu Nightmare-Eclipse đã phát hiện lỗ hổng này thì có vẻ câu chuyện đã kéo dài từ gần một tuần trước
Vào thứ Ba, ngày 12 tháng 5 năm 2026, người này viết rằng: “Lần này có hai lỗ hổng [YellowKey] [GreenPlasma] [...] Microsoft sẽ nhận một bất ngờ lớn vào kỳ Patch Tuesday tới”, và đến thứ Tư, ngày 13 tháng 5, lại viết: “Khi tôi có thể công khai toàn bộ câu chuyện, mọi người sẽ thấy cơn bùng nổ của tôi là khá hợp lý, và chuyện này tuyệt đối sẽ không đẹp mặt gì với Microsoft”
Blog của tác giả: https://deadeclipse666.blogspot.com/
Trong bài đầu tiên vào tháng 3 năm 2026 có đoạn kiểu như: “Ai đó đã phá vỡ thỏa thuận của chúng tôi, và tôi mất sạch tiền bạc lẫn nhà cửa. Họ đâm sau lưng tôi dù biết trước chuyện này sẽ xảy ra. Đây không phải quyết định của tôi, mà là quyết định của họ”
Tôi không biết nên nhìn nhận chuyện này thế nào, nhưng nghe hơi giống một người trong nội bộ đang thực chất “làm rò rỉ”, và có vẻ những người khác cũng có thể tái hiện kết quả
Có phải backdoor hay không thì cuối cùng phụ thuộc vào cách bạn thường nhìn nhận chuyện “đây là lỗi hay là backdoor”, chứ không phải kiểu câu chuyện đơn giản mà báo công nghệ thích như “Microsoft bị 1, BitLocker bị hack”
Cốt lõi là một lỗi trong tính năng phát lại nhật ký giao dịch NTFS của Windows Recovery Environment WinRE, cho phép đọc nhật ký giao dịch NTFS của một volume bên ngoài và áp dụng nó lên hệ thống tệp đang được mount. Nhờ đó kẻ tấn công có thể vượt qua xác thực WinRE
Với BitLocker không dùng PIN hay mật khẩu, bất kỳ hình thức vượt qua xác thực nào cũng tương đương với vượt qua mã hóa đĩa. Lý do là bootloader đã unseal đĩa từ trước, và kiểu “khiếm khuyết” mang tính cấu trúc này cũng tồn tại trên Linux với cùng cấu hình. Ví dụ, trường hợp dùng ô chọn Hardware Disk Encryption được thêm tương đối gần đây trong trình cài đặt Ubuntu cũng vậy
Nếu không có thêm bằng chứng, chuyện vấn đề nhật ký giao dịch NTFS là backdoor được cài cắm hay chỉ là một lỗi liệt kê thông thường sẽ phụ thuộc vào mức độ thuyết âm mưu vốn rất phổ biến trong giới phát triển exploit. Cá nhân tôi thấy đây là một lỗi khá hợp lý, và điểm yếu của việc unseal lúc khởi động vốn đã quá rõ và được biết đến từ lâu nên tôi không xem đây là một màn bóc trần chấn động thế giới, dù đúng là một lỗi thú vị
Bản tóm tắt tốt hơn: https://infosec.exchange/@wdormann/116565129854382214
Exploit đã công bố không ảnh hưởng đến BitLocker có dùng PIN. Nếu không có PIN thì BitLocker vốn dĩ đã không an toàn
Tác giả ban đầu nói rằng họ có exploit hoạt động cả khi có PIN, nhưng đến giờ vẫn chưa đưa ra bằng chứng
Tôi chưa từng thấy công ty nào bắt buộc PIN cho BitLocker
Nguồn: https://infosec.exchange/@wdormann/116565129854382214
“Một phiên WinRE thông thường có thư mục X:\Windows\System32 và trong đó có tệp winpeshl.ini”
“Nhưng trong exploit YellowKey, có vẻ như các mảnh Transactional NTFS trên USB drive có thể xóa tệp winpeshl.ini trên một drive khác”
Thú vị thật. Tôi không rành môi trường này, nhưng liệu đây có phải kiểu vấn đề ngây thơ trong việc tạo hoặc truyền file handle không? Nếu vậy thì tại sao lại cần nhập phím trong lúc WinRE khởi động lại?
Tôi cũng tò mò không biết mức độ vá lỗi sẽ khả thi đến đâu. Sẽ có vô số USB drive WinRE không thể động vào, vậy phía BitLocker có thể cập nhật quyền truy cập không? Có cần giải mã/mã hóa lại không? Có vẻ vẫn còn nhiều thông tin nữa sẽ xuất hiện
Vì thế cuộc tấn công này không thể dùng kiểu khởi động bằng Ubuntu live CD, mà bắt buộc cần WinRE
Ngoài ra cũng không cần vá toàn bộ các USB drive WinRE hiện có. Chỉ cần thu hồi chữ ký Secure Boot là chúng sẽ không qua được kiểm tra của TPM, và vì vậy sẽ không thể giải mã bất kỳ đĩa nào
“Các chuyên gia bảo mật thường khuyên không nên phụ thuộc vào một hệ thống mã hóa duy nhất mà nên đánh giá các lựa chọn mã hóa toàn bộ ổ đĩa đã được thẩm định kỹ như VeraCrypt”
Nếu đúng là đã cài backdoor vào FDE, thì hợp lý hơn là bảo mọi người ngừng dùng Windows luôn và chuyển sang Linux
Nếu đã cài backdoor vào FDE, thì cũng nên giả định hệ điều hành tự thân không chỉ có đúng một backdoor. Không nên tin phần mềm độc quyền chút nào, và cũng không nên tin mã nguồn mở chưa được kiểm toán tử tế
Cái này có vẻ không hẳn là vấn đề riêng của BitLocker mà gần hơn với vượt qua đăng nhập. Nếu chỉ dựa vào TPM mà không có PIN thì nó sẽ tự động giải mã
Bình thường thì kẻ tấn công đáng ra vẫn không vượt qua được màn hình đăng nhập, nên lẽ ra vẫn ổn, nhưng exploit này có vẻ cho thấy cách lấy được shell không bị hạn chế trong môi trường phục hồi
Nhà nghiên cứu nói rằng họ cũng có cách vượt qua cả PIN, nhưng chưa công bố
Đến bao giờ thì các chuyên gia bảo mật bắt đầu từ chối vai trò “bảo mật sản phẩm Microsoft”? Tôi thì đã đến mức đó rồi
Bảo mật cho sản phẩm Microsoft chỉ là một công việc bận rộn cho đến khi nó lại sụp đổ dưới làn sóng nợ kỹ thuật điên rồ và lòng tham tiếp theo của MS. Giờ thì đến cả backdoor cũng có
Họ đã đáp ứng mọi quy định tuân thủ và làm theo “best practice” do ảnh hưởng của MS định hình, nên dù có chuyện gì xảy ra thì cũng không còn là trách nhiệm của họ
Bạn có thể bật ADP để có sao lưu mã hóa đầu cuối, nhưng có lẽ cũng không giúp được nhiều vì những người bạn trò chuyện cùng rất có thể chưa bật
Không phải tôi muốn bào chữa cho Microsoft, mà là nói rằng những công ty này đều từng là một phần của PRISM
Hay ta nói về chuyện vì sao khi một bản Windows NT nào đó vô tình được phát hành với debug symbol bật sẵn, cái khóa mà Microsoft bảo là “khóa phụ” lại có tên là ..._NSAKEY
Chỉ đúng một lần, đúng nghĩa chỉ một lần, Windows được phát hành với debug symbol bật sẵn, và đúng lúc đó tên khóa mã hóa lại là “NSAKEY”
Tất nhiên những người luôn làm ngơ trước sai trái của nhà nước sẽ bảo đó hoàn toàn bình thường, rồi lặp lại nguyên xi lời biện hộ “đó không phải backdoor” mà Microsoft đã dày công chuẩn bị hồi đó
Đào sâu exploit thêm một chút thì đây là thứ nhắm vào BitLocker ở chế độ chỉ dùng TPM, tức không có xác thực trước khởi động
Nếu Secure Boot xác minh chuỗi khởi động thì TPM sẽ tự nhả khóa mã hóa. Khi đã có truy cập vật lý thì khác biệt không còn nhiều
Bạn có thể khởi động bằng USB chứa exploit để lấy shell khẩn cấp, hoặc mua một vi điều khiển 5 đô rồi hàn vào vài chân cụ thể trên mainboard để sniff khóa TPM
Microsoft về cơ bản đang bán một thứ không an toàn như thể đó là mã hóa toàn bộ ổ đĩa. Một người có thể nhét exploit vào flash drive, lấy shell rồi lục và sao chép tệp thì cũng có thể mua vi điều khiển, xem video hàn trên YouTube và làm theo
Vậy nên vấn đề không nằm ở bản thân “exploit”, mà ở cảm giác an toàn giả tạo mà Microsoft đang bán
Việc dùng vi điều khiển 5 đô hàn vào chân cụ thể để sniff khóa TPM chỉ khả thi với dTPM. fTPM không bị kiểu này và cũng được dùng rộng rãi hơn nhiều so với dTPM
Việc gõ mật khẩu mã hóa lúc khởi động đã thành trí nhớ cơ bắp và mang lại một lớp bảo mật đơn giản, đáng tin cậy
Bạn cũng có thể khôi phục dữ liệu mà không cần mainboard
Với nhu cầu hằng ngày, có lẽ mô hình lai dùng slot kết hợp Secure Boot+TPM+mật khẩu để chống evil maid attack, cùng thêm một slot mật khẩu dự phòng nữa, sẽ ổn
https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...
Đây có vẻ giống một cuộc tấn công vào chuỗi Secure Boot hơn là một cuộc tấn công riêng vào BitLocker
Giá trị của kiểu mở khóa không cần PIN chỉ tồn tại khi mô hình đe dọa của bạn giới hạn ở việc tiêu hủy ổ đĩa, tháo rời ổ đĩa hoặc tách TPM khỏi ổ đĩa
Nếu thiết bị được nhiều người dùng thường xuyên, việc nhập PIN có thể bất tiện hoặc bất khả thi. Vì vậy người ta mới chuyển việc kiểm chứng truy cập sang các thành phần hệ điều hành được tin cậy
Có ai còn nhớ câu “Sử dụng TrueCrypt là không an toàn và có thể chứa những vấn đề bảo mật chưa được khắc phục” không? ;)