Blog Feature

By: Andy Sherman on October 25th, 2016

Print/Save as PDF

Secure Boot: Stop Rootkits Dead in Their Tracks by Converting from BIOS to UEFI

End User Devices and Services

As outlined in our previous article, Windows 10 Security, The Good, The Bad, and The Ugly, there are several exciting new security features in Windows 10 Enterprise, such as Device Guard and Credentials Guard, that leverage features of more recent hardware. In order to take full advantage of all that Windows 10 Enterprise has to offer, you will probably need to convert a lot of existing boot drives from BIOS to UEFI, and when you do that, you will also want to enable the Secure Boot feature of your workstation hardware. Sound opaque and confusing? This article will explain what it means and talk about some strategies for making the conversion in your enterprise.


Develop a transition strategy for a successful Windows 10 upgrade, and make this migration your best.

Learn More


What is UEFI?

In the earliest incarnations of the IBM PC-compatible computers, the hardware input-output capabilities were implemented in firmware called the Basic Input Output System, or BIOS. The BIOS came with restrictions that were quite appropriate for the generation of processors for which it was developed, (such as 16-bit operating mode and 1MB address space), the development of more advanced processors made continued use of BIOS untenable. Intel addressed this in the late 1990s with the Extensible Firmware Interface (EFI) which later became the standards-based Unified Extensible Framework Interface (UEFI). When Apple introduced Intel-based Macs in the early 2000s, they only ever shipped with EFI or UEFI. At current writing, most user and server class machines ship with UEFI firmware, since it is a Windows logo requirement.

Most UEFI implementations (other than Apple’s) maintain a BIOS compatibility mode, so that they can boot in either BIOS or UEFI mode. However, we will see that some security features can only be enabled in a pure UEFI environment, meaning that compatibility support is disabled.

Changing over to a pure UEFI environment is not a trivial matter. The boot disks are not compatible, since they use a different partition table format. BIOS based disks are partitioned using the original Master Boot Record (MBR) partition scheme. With the introduction of UEFI, a new partition table schema, GUID Partition Table (GPT), was introduced. UEFI can only boot GPT disks. Booting a disk with a MBR requires that the firmware operate in BIOS compatibility mode. Since many of your existing machines will probably be using BIOS and MBR, a non-trivial conversion process will be required. Before we go through that, why are we going to do this to ourselves?

Why Convert to UEFI?

Arguably, the strongest reason for doing this conversion actually predates Windows 10: enabling Secure Boot. Secure Boot is a feature of UEFI firmware that checks the digital signature of the bootloader and boot-time device drivers and will only allow them to run if they are signed with a certificate that is in a list of trusted signers embedded in firmware. Any Windows 8 or later logo certified PC is configured with secure boot enabled and Microsoft’s signing certificate in the trust store. The major Linux distributions have either distributed their keys to major hardware manufacturers or have had their bootloaders signed by Microsoft, so secure boot does not restrict you to booting Windows. (This is true for Intel and AMD-based PCs. ARM-based Microsoft branded tablets only have certificates to boot Windows.)

You want to convert to Secure Boot to protect against rootkits and other boot-time malware. If a rootkit attempts to install its own bootloader, it won’t boot and the user will be alerted that something is wrong. While most manufacturers allow you to turn off Secure Boot, it is important to educate users (and support staff) not to turn off Secure Boot if what had been a known-good system suddenly refuses to boot.

UEFI and Secure Boot are also pre-requisites for two powerful security features, Device Guard and Credentials Guard (which will be the subject of future articles). These features use the virtualization capabilities of the hardware to move checks on the trustworthiness of code or the retrieval of stored credentials into their own virtual containers. These containers are not accessible (even to kernel mode code) except through service calls, so that they cannot be easily compromised.

Note that new machines are likely to come configured for UEFI and Secure Boot. Even if you are going to re-image them with your own image, you should leave them in UEFI-only mode with Secure Boot enabled.

Conversion Scenarios

There are two likely scenarios for converting your existing machines from BIOS compatibility mode to UEFI:

  • Convert the machine while retaining its current Windows 8 or 8.1 image
  • Convert the machine as part of an upgrade to Windows 10. (This is the only option for Windows 7, which has limited support for UEFI.)

For either mode, you should ensure that your firmware is up-to-date, since many of these features require a minimum version level of UEFI to work. Out of date firmware should be updated with the manufacturer’s firmware updater. This will also ensure that Secure Boot has the right trusted certificates.

Conversion in Place

The part of the conversion that is the trickiest is changing the partition table from MBR to GPT. While it is possible to do that in place without data loss, the procedure for doing that is risky and could lead to inadvertent loss of that data on the disk. Also, it’s a hack that doesn’t lend itself to automation; I only mention it here because if you Google, you will find it – don’t use it. As Mr. Wizard says, “Don’t try this one at home, kids.”

Thus the first step of any conversion will be to back up the existing image. Then you need to erase the MBR, repartition the disk as GPT, install a UEFI boot partition, a recovery partition, and change the firmware mode to UEFI only with Secure Boot. Finally, you will need to restore the saved image from backup.

This is an involved set of tasks for a single machine. For a large installed based, doing this manually is untenable and some sort of automation will be called for. More on that later.

Convert and Upgrade

A good time to convert from BIOS to UEFI is as part of an upgrade to Windows 10, since you may avoid the need to restore the existing image if you are updating by re-imaging the machine. The rest of the process is much simpler: erase the MBR, create a GPT, and then run your software installer. That’s still more hands on than you want to do for every machine, so automation is desirable. On the other hand, if your upgrade strategy is to upgrade the existing image in place, then you will need to take all of the steps above and then start the upgrade process.


Develop a transition strategy for a successful Windows 10 upgrade, and make this migration your best.

Learn More


Automation

Automating either of these conversion processes is actually quite difficult. If it can be done with System Center or similar systems management tools, it can’t really be done with a single worklist. The reason for this is that multiple PXE boots or the equivalent are required:

  • A boot into Windows PE in order to change the disk partitioning.
  • Another boot for:

Orchestration across multiple reboots and worklists will be hard.

Another approach is offered in the most recent release of 1E’s Nomad product, released in September 2016. The new version contains a workflow (and control screens) specifically for the BIOS to UEFI conversion. In a multi-site enterprise, Nomad ensures that backups and PXE-boot equivalents are all performed locally. Best of all, the system administrator only need to configure and kick off the process once, while Nomad does all the orchestration. With the addition of 1E’s self-service module, scheduling the upgrade can be left to the end-user to avoid working hour inconvenience.

 Planning-for-Windows-10-Starts-Now

About Andy Sherman

Andy Sherman, Eden Technologies’ security practice lead has a PhD in physics from Rensselaer Polytechnic Institute and started his career in the academic world. He then went to AT&T Bell Laboratories where he discovered the power – and hazards – of large distributed computer networks. It was also at Bell Labs, during the early days of the Internet, that Andy became interested in the security problems associated with public networks. From Bell Labs Andy moved to the financial services industry. There he worked on a large range of infrastructure design, deployment, and management projects, but is best known for his 15+ years in information and technology security.