Intel is investigating the leak of alleged private keys used by the Intel Boot Guard security feature, potentially impacting its ability to block the installation of malicious UEFI firmware on MSI devices.
In March, the Money Message extortion gang attacked computer hardware make MSI, claiming to have stolen 1.5TB of data during the attack, including firmware, source code, and databases.
As first reported by BleepingComputer, the ransomware gang demanded a $4,000,000 ransom and, after not being paid, began leaking the data for MSI on their data leak site.
Last week, the threat actors began leaking MSI's stolen data, including the source code for firmware used by the company's motherboards.
Intel Boot Guard impacted by attack
On Friday, Alex Matrosov, the CEO of firmware supply chain security platform Binarly, warned that the leaked source code contains the image signing private keys for 57 MSI products and Intel Boot Guard private keys for 116 MSI products.
"Intel is aware of these reports and actively investigating. There have been researcher claims that private signing keys are included in the data including MSI OEM Signing Keys for Intel® BootGuard," Intel told BleepingComputer in response to our questions about the leak.
"It should be noted that Intel BootGuard OEM keys are generated by the system manufacturer, and these are not Intel signing keys."
Matrosov said that this leak may have caused Intel Boot Guard not to be effective on MSI devices using "11th Tiger Lake, 12th Adler Lake, and 13th Raptor Lake" CPUs.
"We have evidence the whole Intel ecosystem is impacted by this MSI data breach. It's a direct threat to MSI customers and unfortunately not only to them," Matrosov told BleepingComputer Friday afternoon.
"The signing keys for fw image allow an attacker to craft malicious firmware updates and it can be delivered through a normal bios update process with MSI update tools."
"The Intel Boot Guard keys leak impacts the whole ecosystem (not only MSI) and makes this security feature useless."
Intel Boot Guard is a security feature built into modern Intel hardware designed to prevent the loading of malicious firmware, known as UEFI bootkits. It is a critical feature used to meet Windows UEFI Secure Boot requirements.
This is because malicious firmware loads before the operating system, allowing it to hide its activities from the kernel and security software, persist even after an operating system is reinstalled, and help install malware on compromised devices.
To protect against malicious firmware, Intel Boot Guard will verify if a firmware image is signed using a legitimate private signing key using an embedded public key built into the Intel hardware.
If the firmware can be verified as legitimately signed, Intel Boot Guard will allow it to be loaded on the device. However, if the signature fails, the firmware will not be allowed to load.
The biggest problem with this leak is that the public keys used to verify firmware signed using the leaked keys are believed to be built into Intel hardware. If they cannot be modified, the security feature is no longer trustworthy on devices using those leaked keys.
"The Manifest (KM) and Boot Policy Manifest (BPM) private keys were found in the leaked MSI source code. These keys are used for Boot Guard technology which provides firmware image verification with a hardware Root of Trust," warns Binarly in an advisory shared on Twitter.
"The hash OEM Root RSA public key from the KM manager is programmed into chipset's Field Programmable (FPFs). The main purpose of the KM is to store the hash of an RSA public key from the BPM which in turn contains the information on the Boot Policy, Initial Boot Block (IBB) description and it's hash."
"The leaked private parts of the mentioned keys allows a potential attacker to sign the modified firmware for this device, so it would pass Intel Boot Guard's verification making this technology completely ineffective."
While these keys will not likely be helpful to most threat actors, some skilled attackers have previously used malicious firmware in attacks, such as CosmicStrand and BlackLotus UEFI malware.
"Now the feature can be compromised and attackers can craft malicious firmware updates on impacted devices without concern about Intel Boot Guard," Matrosov said in a final warning shared with BleepingComputer
Binarly has released a list of impacted MSI hardware, comprising 116 MSI devices reportedly compromised by the leaked Intel Boot Guard keys.
BleepingComputer has also contacted MSI and Intel with further questions, but a response was not immediately available.
Update 5/8/23: Added statement from Intel
Comments
ZeroYourHero - 1 year ago
There needs to be a small hidden mechanical switch on all laptops and PCs that disables all firmware updates until turned on. After the update the switch must be turned off to boot.
Kenjinn - 1 year ago
released a list of impacted MSI hardware, Link is broken and goes to an github error page.
alex2012 - 1 year ago
That is due to them changing the file name or he had a typo.
https://github.com/binarly-io/SupplyChainAttacks/blob/main/MSI/MsiImpactedDevices.md
Lawrence Abrams - 1 year ago
Yes, looks like they changed the URL. Fixed the link.
h_b_s - 1 year ago
I think it's pertinent to point out that while this does essentially break any security guarantees for Boot Guard, it doesn't make the feature entirely useless. Thanks to Intel's infinite wisdom in over-engineering UEFI, one of the base requirements for all UEFI implementations is that it must support FAT32 filesystem for storing part of the boot chain. The de facto policy then is that nearly every implementation only supports FAT32 for storing boot shims. The problem is that FAT32 is one of the worst FS for storing anything safely - it has no real safeguards against data corruption that more modern file systems like NTFS, Ext4, ZFS, etc. have. Part of the task of a signed boot chain is to not only protect the stored boot shim against malicious attack, but to make sure the computer's own hardware doesn't corrupt the boot shim files when writing them out to storage. While the former reasoning is now bunk thanks to MSI's utter incompetence, the second is still desirable for maintaining data integrity.
Edit to add: I'm not letting MSI off the hook here. As I have said before, MSI's security is a joke and it was only a matter of time they were targeted to steal exactly what was stolen in the breach. I'm only pointing out that regardless of what people think of SB as a security feature, it does have a secondary role in simple data integrity that shouldn't be ignored. Anyone of a certain age should remember how awful MSDOS and Windows 9x was at corrupting its own files to the point where reinstalling the OS every 6 months to a year was necessary. Part of the reason why has to do with just how awful FAT (16, 32, ex) and its descendants are for file integrity.