Hackers can solely use fastened Intel bugs to put in malicious firmware on PCs
As the amount of sensitive data stored on computers has exploded over the past decade, hardware and software manufacturers have invested more and more resources in securing devices against physical attacks in the event that they are lost, stolen, or confiscated. Earlier this week, Intel fixed a number of bugs that allowed attackers to install malicious firmware on millions of computers using their CPUs.
The vulnerabilities allowed hackers with physical access to override an Intel protection built into modern CPUs that prevents unauthorized firmware from running during the boot process. The measure known as Boot Guard is intended to anchor a chain of trust directly in the silicon to ensure that all loaded firmware is digitally signed by the computer manufacturer. Boot Guard protects against the possibility of someone tampering with the SPI-connected flash chip on which the UEFI is stored. This is a complex firmware that connects the device firmware of a PC with the operating system.
Hardware enforced security
These types of hacks usually occur when attackers plug hardware inside a computer and use Dediprog or similar chip programming tools to replace authorized firmware with malicious firmware.
As Intel explains here:
The execution of the UEFI BIOS code is generally not tied to the underlying hardware. This means that this UEFI BIOS code will run without being checked or measured. This makes the entire boot process vulnerable to a subversion of the BIOS, regardless of whether this can be done through an unprotected update process or simple hardware attacks with SPI flash memory replacement or with a Dediprog.
Intel Boot Guard provides platform manufacturers and platform owners with robust, hardware-enforced control controls to authorize what BIOS code can run on that platform. Intel Boot Guard provides the hardware-based root-of-trust (RoT) for checking the platform start-up, which is responsible for checking the BIOS image before the BIOS is executed. Intel Boot Guard raises the platform's security bar, reduces the aforementioned attack vectors and makes it harder to launch attacks in order to undermine the boot process.
Earlier this year, security researcher Trammell Hudson discovered three vulnerabilities that prevented Boot Guard from working when a computer went out of sleep mode. Technically known as S3, this mode retains all of the items stored in computer memory but turns off the CPU entirely.
Undermine Boot Guard
An attacker who could bypass Boot Guard while waking it up could then carry out a wide variety of malicious activities. The most important of them is obtaining the keys that will be used to encrypt hard drives while the keys are stored in memory, as is the case with many computers at rest. This could allow an attacker to obtain the decrypted versions of all data stored on the computer without needing the user's password.
An attacker could also infect the computer with a rootkit – malicious code that is difficult or impossible to detect – that will run in system administration mode until the computer is restarted. The NSA is said to have such SMM implants.
Although these types of exploits are serious, the attack scenarios are limited because the hack cannot be performed remotely. For many people, attacks that require physical access are not part of their threat model. It would also require hardware and firmware expertise and specialized tools like Dediprog or Spispy, an open source flash emulator that Hudson developed. In an article published this week, Hudson wrote:
Because CVE-2020-8705 requires physical access, it is more difficult for an attacker to use than it is for a remote exploit. However, there are some realistic attack scenarios it could be used in.
One example is customs clearance at an airport. Most travelers close their laptop during the descent and let it switch to S3 sleep. If the device is taken over by the enemy agency when it lands, the hard disk encryption keys are still in memory. The opponent can remove the bottom cover and attach a flash emulator in the system like the Spispy to the flash chip. You can wake up the machine and supply it with its firmware via the Spispy. This firmware can scan the memory to locate and disable the operating system's lock screen, and then allow the system to proceed normally. Now they have access to the unlocked device and its secrets without forcing the owner to provide a password.
The opponent can also install his own SMM rootkit "Ring -2" at this point, which remains resident until the next hard restart. This could allow them to run code on the system if it has been moved to a trusted network, potentially allowing horizontal movement.
Another example is a hardware implant that emulates the SPI flash. The iCE40up5k (a small field programmable gate array card) used in one of the variants of the Spispy fits easily into or under a SOIC-8 package and allows a permanent attack on the resume path. Because the FPGA can easily distinguish between a cold boot and a validation of the system resumed from hibernation, the device can provide a clean version of the firmware with the correct signature when validated or read by a tool like flashrom, and only the modified version during a resume from sleep. This type of implant would be very difficult to detect via software and, if done well, would not look out of place on the motherboard.
The update is in
One of the security flaws in Boot Guard resulted from configuration settings that manufacturers literally burn into the CPU through a process known as one-time programmable backups. OEMs should be able to configure the chip to either run Boot Guard when a computer comes out of S3 or not. Hudson isn't sure why all five of the manufacturers he tested turned off the device, but he suspects that's because machines get back up and running much faster this way.
In an email, an Intel spokeswoman wrote: “Intel has been informed of an Intel Boot Guard vulnerability in which a physical attack could bypass Intel Boot Guard authentication when returning from sleep. Intel has released damage controls and recommends maintaining physical ownership of devices. "
Intel doesn't say how it fixed a vulnerability related to backup settings that cannot be reset. Hudson suspects that Intel made the change using firmware running in the Intel Management Engine, a security and management coprocessor in the CPU chipset that, among other things, manages access to the OTP backups. (Earlier this week, Intel posted never-before-released details about the ME here.)
The other two vulnerabilities resulted from errors in getting the firmware by CPUs at power-up. All three vulnerabilities were indexed under the single tracking ID CVE-2020-8705, which has been given a high severity rating by Intel. (Intel has an overview of all November security patches here. Computer manufacturers started making updates available this week. Hudson's post, linked above, has a far more detailed and technical description.