Zranitelnost UEFI Secure bootu u zařízení s MS Windows umožňuje hackerům spuštění bootkitů/rootkitů na zařízeních s MS Windows. Microsoft se sice pokouší tuto chybu opravit, avšak doposud ne zcela úspěšně. Zranitelnost Secure bootu je možné využít k obejití bezpečnostních mechanismů secure bootu a k následné instalaci bootkitu/rootkitu na zařízení s MS Windows. Bezpečnostní analytici se domnívají, že tento bezpečnostní problém nemůže být zcela eliminován.

Secure Boot Bypass Allows Hackers to Load Bootkits/Rootkits on Windows Devices

Microsoft has been attempting to patch a serious Secure Boot vulnerability that can be exploited to bypass the security feature and install rootkits and bootkits on Windows devices. Researchers believe the security flaw cannot be fully patched.

Secure Boot is a UEFI (Unified Extensible Firmware Interface) feature that should prevent unauthorized programs or drivers from being loaded during the boot process of devices running Windows 8 and later. The feature is designed to ensure that every component loaded at boot is signed and validated.

On systems where Secure Boot is locked down and cannot be disabled (e.g. Windows RT, HoloLens, Windows Phone), configuration changes can be made using policies, signed files loaded by the boot manager (bootmgr) from a UEFI variable. There are some boot loader executables (EFI files) signed by Microsoft that can be used to provision such policies.

Before loading a policy, bootmgr checks it to make sure it’s valid. However, researchers discovered that Microsoft introduced a new type of Secure Boot policy during the development of Windows 10 Anniversary Update (v1607) that can be abused to bypass the security feature.

The researchers known online as Slipstream and My123 discovered that these new policies, dubbed “supplemental” policies, are loaded by the boot manager without being checked properly.

Loading a supplemental policy can be used to enable “test-signing,” a feature that allows developers to install self-signed third-party drivers on a Windows machine. Once test-signing is enabled, an attacker can bypass Secure Boot and load a rootkit or a bootkit onto the device.

“You can see how this is very bad,” Slipstream explained in a blog post. “A backdoor, which MS put into secure boot because they decided to not let the user turn it off in certain devices, allows for secure boot to be disabled everywhere!”

The vulnerability was first reported to Microsoft this spring, but the tech giant initially said it had no plans to address the issue. As researchers were working on developing a proof-of-concept (PoC), Microsoft had a change of heart and decided to award a bug bounty.

The first patch was released by the company in July with the MS16-094 bulletin rated important. Microsoft noted in an advisory that the flaw (CVE-2016-3287) can be exploited to bypass Secure Boot security features by installing an affected policy on the targeted device. The company pointed out that the attack can only be carried out by an attacker who has admin privileges or physical access to the targeted system.

Microsoft initially attempted to address the problem by blacklisting affected policies, but researchers quickly found a way to bypass the fix by replacing the boot manager with an earlier version. The vendor once again tried to patch the vulnerability (CVE-2016-3320) this month (MS16-100) by blacklisting affected boot managers, but the experts claim this fix is not efficient either.

In fact, Slipstream believes the vulnerability “cannot be truly patched.” The researcher has published the files needed to unlock Secure Boot on Windows RT devices.

SecurityWeek has reached out to Microsoft for comment and will update this article if the company responds.

Microsoft has confirmed that the flaw affects Windows 8.1, Windows RT 8.1, Windows Server 2012 and Windows 10. Researchers claim the attack works on every type of Windows device, including PCs, phones, tablets, IoT Core systems, and HoloLens.

UPDATE. Microsoft provided the following statement to SecurityWeek:

“The jailbreak technique described in the researchers’ report on August 10 does not apply to desktop or enterprise PC systems. It requires physical access and administrator rights to ARM and RT devices and does not compromise encryption protections.”