Microsoft is scrambling to fix an issue that unlocks Windows tablets, phones, and other devices protected by Secure Boot.
Security researchers my123 (@never_released) and slipstream (@TheWack0lian) are warning that attackers can use a special script to install operating systems not issued by the Redmond-based tech giant onto Windows.
Why is that a problem? Well, that includes malicious OS packages, or “bootkits,” which attackers can use to eavesdrop on unsuspecting users’ communications or to steal their credentials.
Let’s get into the weeds of this issue by answering the following question: what is “Secure Boot”?
Secure Boot remedies the insecurities of the Standard Boot process. In a standard boot process a computer loads up firmware, calls a bootloader, and initializes certain hardware during the boot-up process. The only problem is that few of those components are actually verified by the computer, meaning someone could tamper with the bootloader and replace it with a malicious one.
Secure Boot, a feature of UEFI (Unified Extensible Firmware Interface), fixes that issue by requiring certain components to be signed and verified by Microsoft. That means the computer will call only a verified bootloader before moving on to the kernel drivers, user drivers, and applications.
You can read more about how Secure Boot works in this Microsoft blog post.
Secure Boot is made up of different policies, or rules, which govern how a computer should execute the startup process.
It’s here that Microsoft screwed up.
To enable testsigning, or a state where developers can load fresh operating system builds without needing to sign each one, the tech giant created a new Secure Boot policy that doesn’t require the normal amount of checks and and whose conditions are unchecked by the Windows boot manager.
That policy isn’t available on commercial products, but if you obtain it and load it into your firmware, you can essentially trick your Windows device into thinking you’re loading up a verified OS while installing a self-signed – or malicious – binary.
Well… it just turns out someone leaked that policy online, meaning any number of computer criminals can get their hands on it.
The research duo informed Microsoft of their research concerning this flawed policy between March and April.
After ignoring the issue for several months, Microsoft issued a bug bounty award and created two patches. Neither of those updates has successfully resolved the issue, however.
At this time, users can’t do anything to protect themselves except make sure their Microsoft patches are up-to-date on all Windows devices.
Such a state of helplessness illustrates how backdooring cryptosystems can threaten users’ and their security, as the researchers explain:
“About the FBI: are you reading this? If you are, then this is a perfect real world example about why your idea of backdooring cryptosystems with a “secure golden key” is very bad! Smarter people than me have been telling this to you for so long, it seems you have your fingers in your ears. You seriously don’t understand still? Microsoft implemented a ‘secure golden key’ system. And the golden keys got released from MS own stupidity. Now, what happens if you tell everyone to make a ‘secure golden key’ system?”
For more information, please read the security researchers’ blog post.
Found this article interesting? Follow Graham Cluley on Twitter or Mastodon to read more of the exclusive content we post.
One comment on “Microsoft rushes to fix issue that unlocks devices protected by Secure Boot”
So: a law enforcement agency in possession of the hardware and a warrant, or a bad person in possession of the hardware, can load a new or modified OS. And a person who paid for the hardware can load a new or modified OS according to personal preference. All this on hardware that never commanded much market share and for which Microsoft has announced end of support life. I am shocked.
Portraying secure boot as a security feature, as the article did, is quite disingenuous. Secure boot, as Microsoft did for ARM based systems, had almost nothing to do with security except as it ensured Microsoft control over installation of operating systems and other software, and corresponding Microsoft revenue streams.