Hackers can use newly patched Intel bugs to install malicious firmware on PCs | GeekComparison

Hackers can use newly patched Intel bugs to install malicious firmware on PCs

Getty Images

As the amount of sensitive data stored on computers has exploded over the past decade, hardware and software makers have invested increasing resources in securing devices against physical attacks in the event they are lost, stolen, or seized. Earlier this week, Intel patched a series of bugs that allowed attackers to install malicious firmware on millions of computers using Intel’s 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. Known as Boot Guard, the measure is designed to embed a chain of trust directly into the silicon to ensure that any firmware loaded is digitally signed by the computer manufacturer. Boot Guard protects against the possibility of someone tampering with the SPI-connected flash chip that stores the UEFI, which is a complex piece of firmware that bridges a PC’s device firmware with the operating system.

Hardware-assisted security

These kinds of hacks usually take place when attackers attach hardware to the inside of a computer and use Dediprog or similar chip programming tools to replace authorized firmware with malicious firmware.

Trammel Hudson

As Intel explains here:

The execution of the UEFI BIOS code is generally unrelated to the underlying hardware, meaning that this UEFI BIOS code is executed without being verified or measured. Thus, this makes the entire boot process vulnerable to BIOS compromise, whether through an unprotected update process or simple hardware attacks using SPI flash memory replacement or using a Dediprog.

Intel Boot Guard provides robust, hardware-assisted boot policies for platform manufacturers and platform owners to authorize what BIOS code is allowed to run on that platform. Intel Boot Guard provides that hardware-based Root-of-Trust (RoT) for platform boot authentication, which is responsible for verifying the BIOS image before running the BIOS. Intel Boot Guard raises the platform’s security bar, reducing the attack vectors mentioned above and making it more difficult for attacks to subvert the boot process.

Early this year, security researcher Trammell Hudson discovered three vulnerabilities that prevented Boot Guard from working when a computer came out of sleep mode. This mode, technically known as S3, preserves all items stored in the computer’s memory, but completely shuts down the CPU.

Subvert Boot Guard

An attacker who can bypass Boot Guard while awake could then perform a variety of malicious activities. Chief among these is getting the keys used to encrypt hard drives, as long as the keys are stored in memory, as many computers do during sleep. This allows an attacker to obtain the decrypted versions of all data stored on the computer without requiring the user’s password.

An attacker can also infect the machine with a rootkit (malicious code that is difficult or impossible to detect) that will run in administrative mode until the next reboot. Such SMM implants are the sort of thing the NSA would have.

While these types of exploits are serious, the attack scenarios are limited as the hack cannot be performed remotely. For many people, attacks that require physical access are not part of their threat model. It also requires hardware and firmware expertise and special tools like Dediprog or Spispy, an open source flash emulator that Hudson developed. In an article published this week, Hudson wrote:

Since CVE-2020-8705 requires physical access, it is more difficult for an attacker to use than a remote exploit. However, there are a few realistic attack scenarios where it can be used.

An example is when clearing customs at an airport. Most travelers close their laptops during the descent and let it go into S3 sleep mode. If the device is captured by the hostile agency upon landing, the disk encryption keys will still be in memory. The opponent can remove the bottom and attach an in-system flash emulator like the spispy to the flash chip. They can wake up the machine via the Spispy and provide it with their firmware. This firmware can scan the memory to locate and disable the OS lock screen process, after which the system can resume normally. Now they can access the unlocked device and its secrets, without forcing the owner to provide a password.

The adversary can also install its own SMM “Ring -2” rootkit at this point, which will remain until the next hard reboot. This could provide them with code execution on the system when it has moved to a trusted network, potentially enabling horizontal movement.

Another example is a hardware implementation that emulates the SPI flash. The iCE40up5k [a small field-programmable gate array board] used in any of the variants of the spispy can easily fit into or under a SOIC-8 package, allowing for a sustained attack on the resume path. Because the FPGA can easily distinguish between a cold boot and validation of the system coming out of sleep mode, the device can provide a clean version of the firmware with the correct signature when it is validated or read by a tool such as flashrom, and only the modified version during a resume from sleep mode. This kind of implant would be very hard to detect via software and, if done right, wouldn’t look out of place on the motherboard.

The correction is in

One of the Boot Guard vulnerabilities stemmed from configuration settings that manufacturers literally burn into the CPU through a process called one-time programmable fuses. OEMs should have the option to configure the chip to run Boot Guard when a computer comes out of S3 or not. Hudson isn’t sure why all five manufacturers he tested had it turned off, but he suspects it’s because machines resume much faster that way.

In an email, an Intel spokeswoman wrote: “Intel has been made aware of a vulnerability in Intel Boot Guard where a physical attack could potentially bypass Intel Boot Guard authentication when resuming from sleep. Intel has released fixes and recommends physical possession of devices.”

Intel is not saying how it fixed a vulnerability stemming from fuse settings that cannot be reset. Hudson suspects Intel made the change using firmware running in the Intel Management Engine, a security and management coprocessor in the CPU chipset that handles access to the OTP fuses, among other things. (Earlier this week, Intel posted never-before-seen details about the ME here.)

The two other vulnerabilities stemmed from flaws in how CPUs fetched firmware when booted. All three vulnerabilities were indexed under the single tracking ID CVE-2020-8705, which received a high severity rating from Intel. (Intel has a rundown of all of the November security patches here. Computer manufacturers started releasing updates this week. Hudson’s post, linked above, has a much more detailed and technical description.

Leave a Comment