By HardcoreMatrix
The HardcoreMatrix team specializes in firmware and infrastructure security, supply chain security, and threat modeling. We vividly illustrate the severe consequences that underlying threats pose to enterprise and personal information security.
One “Leak” can rule them all!
In March 2023, Micro-Star International (MSI) suffered a significant attack orchestrated by the Money Message ransomware group. Unfortunately, this is not just another random leak. The aftermath revealed a leak of internal data, including highly sensitive information such as the BootGuard private key. This key, integral to Intel’s hardware trust and cryptographic key management system, signifies an exploit vector can’t be fixed easily, allowing for bypassing of the primary security mechanism in specific device models. Additionally, the leaked data also exposed the UEFI firmware image signing key, further exacerbating the severity of the breach.
Why BootGuard matters to UEFI/x86 ecosystem
The BootGuard security mechanism, alongside CPU Microcode and CSME, forms the foundation of Intel’s core security mechanisms. It serves as a critical integrity protection mechanism rooted in the hardware trust system, while the UEFI firmware acts as a vital low-level software component within the computer system. The compromise of BootGuard, whether through successful attacks via vulnerability (e.g: CVE-2020-8705) or acquisition of the private key from OEM/ODM manufacturers, enables threat actors to exploit UEFI implementation flaws, configuration errors, and other vulnerabilities to achieve bypass numerous established security measures and mitigations, e.g: SMM_BWP, BWE/BLE, PRx hardware security mechanisms, SecureBoot and kernel security mitigation technologies such as HCVI, PatchGuard, kASLR, KDEP, SMEP, SMAP. Furthermore, mainstream antivirus software and EDR/XDR systems become ineffective, granting attackers persistent control over the compromised device.
Demonstration of Supply Chain Threats
Following extensive research, the HardcoreMatrix team reconstructed internal tools that were missing from the manufacturer’s arsenal and successfully executed a comprehensive attack chain targeting the MSI Modern-15-B12M laptop (equipped with an Intel 12th Gen CPU: i5-1235U). The demonstration encompassed activities such as BootGuard private key re-signing, capsule update re-signing, and SMM Rootkit deployment. This compelling demonstration video underscores the severity of supply chain threats, showcasing their real-world impact. The demo does not cover OS kernel attack techniques or SMM bootkit since these techniques has been documented well with multiple open source implementation.
The hardware specification of MSI Modern-15-B12M system is as follows:
First, we checked the UEFI BIOS hardware write protection status:
And we extracted the UEFI image:
Before the experiment, we developed a custom DXE module to display a logo. We injected the custom module into the UEFI image.
We attempted to perform a write operation on the unsigned BIOS image:
As expected, the write operation failed. After analyzing the leaked data, we managed to locate the BootGuard private key for the corresponding model and signed the BIOS image.
Since the BIOS write protection SMM_BWP=1 under AMI’s framework, we need to use AFU to flash the BIOS image. In this particular scenario, both the Capsule verification process and the verification carried out during AFU image writing employ the same public key. Therefore, we also need to sign the BIOS image using the Capsule private key.
Finally, we successfully flashed the signed image using AFU.
After reboot, the custom module works as expected!
Full demo:
Mitigation
OEM vendors usually would only suggesting you upgrade to the latest firmware. The latest firmware replaces the leaked capsule key, making it more difficult for attackers to target UEFI. But there are some effective defense mechanisms to mitigate the risks while facing such risks. Three aspects are inevitable. Firstly, it is crucial to strengthen protection at the OS level. This can be achieved through the implementation of runtime protection such as PaX/GRsecurity and VED, as well as adopting MAC (Mandatory Access Control) and sandboxing techniques. These measures fortify the system against various exploit vectors. At the firmware level, a recommended approach is to consider transitioning from UEFI to coreboot. Coreboot represents the next-generation firmware and empowers users to become OEM manufacturers themselves. This paradigm shift gives users the right to perform hardware security provisioning, effectively granting them control over the entire supply chain. By embracing coreboot, users align with the principles of self-sovereignty, reducing the inherent security risks associated with the supply chain and vulnerabilities.
The second aspect involves leveraging trusted computing in a comprehensive manner. Trusted computing is a powerful concept, but it presents a delicate balance. If users have the right and capability for secure provisioning, trusted computing becomes an ally, enhancing security and trust. However, if users lack control and transparency as UEFI, they may fall into the trap of treacherous computing, as discussed by Richard Stallman. MSI’s leaked materials put all x86 users to a risky position as the OEM signing has been compromised. However, if a user possesses their own key, the situation becomes entirely different.
The third aspect pertains to continuous security monitoring and auditing of both the OS and firmware. Regular assessments and audits help identifying vulnerabilities, detect potential threats, and implement timely mitigations. Several specialized companies, such as HardenedVault, Immune and Binarly, have made significant contributions to the development and dissemination of robust below-OS security practices in their respective technical domains.
Epilogue
The world is currently facing a severe situation, as the use of bootkits in malware/ransomware attacks is on the rise. The leaked OEM signing keys by MSI has further worsened the already vulnerable state of x86 firmware security. Despite this, many people (including security professionals) still struggle to understand the significance of threats originating from below-OS. Consider the potential consequences if a bootkit were to be implanted in the firmware of a crypto custody key management service node. Such an exploit could easily facilitate a weak entropy-as-a-service by leveraging memory scanning and hooks. In this scenario, attackers could steal private keys from the public chain through little push of brute-force attacks, all without even touching the custody infrastructure physically.
Nevertheless, there is no need to scare out of death and it’s also unwise to put false hope on “future technologies” like RISC-V or Rust. Instead, try to take control of the secure provisioning process for each device is a feasible plan. Sound like a plan! Stick with the fuc* plan! It’s a good starting point, isn’t it?