Closed zero77 closed 8 years ago
It does not appear to be actual keys, but a method by which you can alter the boot process to bypass the protections of a properly-signed bootloader. through side-loading of a supplemental policy. Relevant portion of the original disclosure
The "supplemental" policy does NOT contain a DeviceID. And, because they were
meant to be merged into a base policy, they don't contain any BCD rules either,
which means that if they are loaded, you can enable testsigning. Not just for
windows (to load unsigned driver, ie rootkit), but for the {bootmgr} element
as well, which allows bootmgr to run what is effectively an unsigned .efi
(ie bootkit)!!! (In practise, the .efi file must be signed, but it can be
self-signed) You can see how this is very bad!! A backdoor, which MS put
in to secure boot because they decided to not let the user turn it off in
certain devices, allows for secure boot to be disabled everywhere!
What portions of framework would benefit from this ability? Are you thinking about a post module that creates a supplemental policy that allows self-signed bootkit to load during startup or to disable driver signing? Maybe both?
Yes, I think both would be useful, although as two separate post modules.
This is kind of a heavy lift for a feature request. It could potentially be an entire project on its own.
Microsoft has accidentally leaked the Secret keys that allow anyone to unlock devices protected by UEFI.
Can you add these keys to the metasploit framework.
https://thehackernews.com/2016/08/uefi-secure-boot-hack.html