마이크로소프트 '시큐어 부트', 10년간 뚫려 있었다

Text settings Story text Size Small Standard Large Width * Standard Wide Links Standard Orange * Subscribers only Learn more Minimize to nav An industry-wide standard Microsoft invented to protect Windows, and later Linux, devices from firmware infections has been trivial to bypass for 13 of its 14 years of existence. The discovery was made by researchers at security firm ESET after identifying 11 firmware images, at least one from 2013, that were known to be defective but remained signed by the software company anyway. The images are known as shims , which were invented to extend Secure Boot to Linux devices and utility software. Using a technique simple enough to be performed by novice hackers, these old, forgotten shims can be used to completely circumvent the protection, which is embedded into the UEFI (Unified Extensible Firmware Interface) of the device’s motherboard. The gaffe is the result of Microsoft, which oversees the signing of shims, failing to revoke the publicly available images once vulnerabilities were found in them. Threat extends to Windows and Linux users The threat extends to Windows and Linux users alike, since the shim can be installed on devices running both operating systems. From there, an attacker can subvert the mandated chain of digitally signed firmware to install malicious firmware that loads early in the boot process and persists after either the OS is reinstalled or a hard drive is replaced. “What makes these old shims dangerous is not a novel vulnerability,” ESET researcher Martin Smolár wrote Tuesday . “It’s that no new vulnerability is needed to bypass UEFI Secure Boot. An attacker needs no complicated exploitation primitives—only a copy of an old, still-trusted, but unrevoked shim binary and a basic understanding of how UEFI shims work. That is enough to bypass such an essential security feature as UEFI Secure Boot.” Secure boot was introduced in 2012 to blunt the threat of bootkits, the term for such malicious firmware. Without Secure Boot, attackers with brief physical access to a device—even when it’s turned off—can install bootkits similar to LoJax used by Russia state hackers in 2018, MosaicRegressor found in 2020, CosmicStrand in 2022, and BlackLotus in 2023. A handful of other in-the-wild bootkits are tracked under names including ESpecter, FinSpy, and MoonBounce . Most but not all bootkit malware requires attackers to have physical access to targeted devices. Such access is one of the threat models Secure Boot is explicitly required to protect against. A list of all 11 shims compiled by CERT shows that some were used by Linux distributors such as Redhat, OpenSuse, and Oracle. Others were part of third-party software such as PC-Doctor Finland’s Matriculation Examination Board. Many of them were built before certain protections, including SBAT and MOK deny lists, existed. Others contain accumulated bugs in their code or in second-stage binaries they authorize. Microsoft’s digitally signed UEFI bootloader for Windows is the sole anchor of trust on Windows machines. For a component to load during the boot process, the certificate must explicitly sign all other code executed during bootup. Shims work differently. They’re a secondary trust anchor, and they’re signed by Microsoft using one of its other UEFI certificates. From there, a certificate belonging to the motherboard or software maker that is embedded into the shim authorizes all software that’s subsequently loaded. When vulnerabilities are found in shims, Microsoft revokes them. In the case of the 11 shims, the company failed to do so, in some cases for more than a decade. The company finally revoked them in its regular monthly patch release in June, after ESET brought them to CERT’s and Microsoft’s attention. Complexity is the enemy of execution Microsoft has yet to explain how or why the lapse occurred. One possible cause is the highly complex way that Secure Boot works. Both the Windows Boot Manager and UEFI shims load two databases. The db database lists all allowed signing certificates and Authenticode hashes. The dbx contains certificates and hashes that are no longer trusted. For a component to be loaded, it must be authorized through the db and not revoked in the dbx. Given the high number of Linux components executed during bootup, listing each of them in these databases isn’t possible, since the dbx is allotted only 32kb of space. So Microsoft has resorted to other revocation methods, specifically SBAT (Secure Boot Advanced Targeting) and Secure Boot Security Version Number (SVN). “In short, where dbx revokes binaries, SBAT and Microsoft’s Secure Boot SVN revoke versions,” Smolár explained. “When a vulnerability is found in a UEFI application supporting one of these version-based revocation mechanisms, what really needs to be kept out is every build up to and including the broken one—and that can be captured by a version number much easier than by a long list of hashes.” Each component in the UEFI loader carries metadata that is signed by the same certificate authenticating the binary itself. This metadata names the component and assigns it a generation number that is incremented each time a new security fix ships. A boot-only variable in the UEFI stores the minimum acceptable generation number allowed for each component. The variable number is enforced by the shim rather than the firmware. The shim also embeds the policy so enforcement doesn’t rely exclusively on the external variable. This allows the incorporation of new policy through a mechanism known as the SbatLevel. “At every boot, the shim first verifies its own SBAT metadata against the policy—so an outdated shim can be made to reject itself—and then applies the same test to every binary it loads, refusing anything whose generation number falls below the minimum that the policy demands,” the researcher wrote. The complexity of the process doesn’t stop there. The upshot is that shims embed both a vendor-managed and built-in shim certificate that authorize all bootloaders and utilities loaded subsequently. Readers who want a more thorough description can consult this section of Tuesday’s post. Further complicating the process, even the expiration of the Microsoft certificate that signed the shims, which took place late last month , isn’t enough to revoke the ones ESET identified. A rogue’s gallery of defective shims The shims identified by ESET authorize secondary components that are known to be vulnerable to various exploits. The Oracle shim, for instance, signs a binary vulnerable to CVE-2015-5381 . Smolár said the skill required to exploit the vulnerability is low. Other vulnerable shims fail to support protections, such as MOK deny-list enforcement and SBAT enforcement, both of which came into effect after the affected shim was released. Still other identified shims contain vulnerabilities in their own code. In the interest of brevity, many additional details included in Tuesday’s report are omitted from this article. An unsettling prospect As noted, these vulnerable shims can be used against Windows and Linux machines alike, although likely not Windows 11 Secured-core PCs in their default state. Any Windows user who has installed Microsoft’s June update batch is no longer vulnerable. Linux users should check the Linux Vendor Firmware Service or consult their distributor. Revocation statuses are available using the uefi-dbx-audit script. The prospect that attackers have had the means to bypass Secure Boot for more than a decade through what amounts to hack-by-numbers scripts isn’t much of an endorsement of the mechanism proposed by Microsoft in partnership with hardware makers. As mentioned earlier, a key contributor to this debacle is its complexity. “This is a solid rebuke of the entire secure boot model,” HD Moore, a firmware security expert, CEO and founder of runZero, and a long-time critic of Secure Boot, said in an interview. His complaints include Microsoft being the de fa