___________________________________________________PROCEEDING OF THE 14TH CONFERENCE OF FRUCT ASSOCIATION Too Young to be Secure: Analysis of UEFI Threats and Vulnerabilities Vladimir Bashun, Anton Sergeev, Victor Minchenkov, Alexandr Yakovlev St. Petersburg State University of Aerospace Instrumentation St. Petersburg, Russia {bashun, slaros, Victor, yakovlev.a}@vu.spb.ru Abstract—Unified Extensible Firmware Interface (UEFI) loaded later in the boot process, like operating system or is a software interface between an operating system and hypervisor. And such infection shall be persistent, since platform firmware designed to replace a traditional BIOS. In malware written into boot firmware can be used to re-infect general, UEFI has many technical advantages over BIOS (pre- operating system even if it was re-installed. Since boot OS environment, boot and run-time services, CPU- firmware works before operating system kernel even loaded independent drivers etc.) including also powerful security mechanisms (e.g. secure boot, update, etc.). They are aimed to to memory or takes control, special security software like provide platform integrity, be root of trust of security antivirus can’t detect the invasion. architecture, control all stages of boot process until it pass Two factors raise attention to boot firmware: control to authenticated OS kernel. From the other side UEFI technology is the focus of many new potential threats and 1) Change of technologies in boot firmware. An exploits and presents new vulnerabilities that must be evolutionary change of boot firmware technologies occurs managed. The main goal of this research is to provide analysis right now. A new Unified Extensible Firmware Interface of the UEFI security issues, find the point and source of the (UEFI) takes place of old legacy BIOS that prevailed security problems and classify them. The paper describes the without significant changes for over 30 years. architectural and implementation troubles of UEFI which lead to threats, vulnerabilities and attacks. It also includes 2) In increased number of bootkit and rootkit attacks. extensive review of the previous research activities in this area Many companies that develop antivirus software expect and the results of our own experiments. As the result of the that such attacks shall be main trend in nearest future. work some recommendation about how to make this young technology more safe and secure are provided. New standard brings both new possibilities and new Keywords–UEFI Secure Boot, Boot firmware, Bootkit, threats. With deployment of new unified interface based on Rootkit. well-documented specification and common API and protocols gives malware developers an opportunity to infect a wide range of new systems. Rich possibilities of new I. INTRODUCTION interface give them additional ways to attack the platform. Secure Boot mechanism aimed to provide platform At the same time, these possibilities may be used by UEFI integrity, be root of trust of security architecture, control developers to protect system from malware. all stages of boot process until it pass control to authenticated OS kernel. The rest of the paper organized as follows. In section II a brief review of UEFI interface, its architecture and key The task of hardware initialization process and components, is presented. In section III, security issues of transition control to the operating system and system power UEFI technologies are analyzed, potential threat, attacks on on is accomplished by specialized system firmware, usually UEFI and recommendations for protection of UEFI BIOS. referred to as Basic Input-Output system (BIOS). The executable code (usually called boot firmware) is stored in II. UEFI TECHNOLOGY non-volatile memory of computer. A. Unified Extensible Firmware Interface BIOS place in architecture and in procedure of system start up is very important, because it is a root of trust for UEFI – unified extensible firmware interface – is an platform. BIOS accomplish full control of platform from interface between the operating system and firmware that computer power on until it passes control to operating control hardware. Its main role in the boot process is the system kernel. This special role of boot firmware makes it following [1]: potentially attractive target for attack. Unauthorized BIOS 1) Execute core root of trust (small core block of firmware update, injection of malicious code to BIOS can firmware that executes first and is capable of verifying the be used to compromise and take control over components integrity of other firmware components). ISSN 2305-7254 ___________________________________________________PROCEEDING OF THE 14TH CONFERENCE OF FRUCT ASSOCIATION 2) Initialize and test low-level hardware. specification (version 2.3.1) special attention is given to the 3) Load and Execute Additional Firmware Modules. security issues. The main component of UEFI security is 4) Select boot device, call Boot Loader and pass control Secure Boot module (chapter 27 of specification). to operating system kernel. The key components of UEFI Secure boot are: In addition, UEFI gives possibility to develop extensions (drivers and applications). 1) UEFI Image Signing. The main aspect of UEFI Secure Boot – ability to use cryptography (digital UEFI is developed by the UEFI Forum [2]. The forum signatures and hashes) for local authentication and developed several specifications, the most interesting for verification of UEFI images (drivers, applications). current research are the UEFI Specification [3] (the Specification describes platform public key infrastructure specification of standard itself, defines basic interfaces, based on PKI. UEFI keys are stored in Secure Boot. The prtocols, data structures, etc.) and PI Specification [4] following keys are define by specification (Fig. 1): (defines the boot process, UEFI boot stages and interfaces between them). The main stages of UEFI boot process and Platform Key (PK). This is a root key, created for key components are discussed in the next chapter. this exact platform. PK Key Owner (usually B. Platform Initialization hardware manufacturer) can modify all other keys. Key Exchange Key (KEK) – the owner of this key The UEFI boot process pass through several stages, (usually OS vendor) can update db/dbx keys. each stage has its own role and potentially may pose certain db – all allowed certificates and hashes are stored security risks: here (white list). – SEC. When an EFI system is powered on, the SEC dbx all forbidden certificates and hashes are (Security) phase of EFI is the first code that is stored here (black list). executed within EFI. This phase serves as a root of Microsoft stores its keys in (a) trust for the system and handles platform reset DB because it allows to run MS- signed efi-applications and also Certificate in PK can be events, among other things. (b) in KEK because it provides a self-signed PEI. The PEI (Pre-EFI Initialization) phase way to add new keys to DB Chain of Trust (platform-specific), which is responsible for initializing the CPU and main memory. It prepares Platform Key (PK) platform for next stages, which are written on C Public half of the key in firmware the language. It locates and executes PEIM modules. establishes a trust relationship between the DXE. The DXE (Driver eXecution Environment) platform owner and platform firmware phase is where the majority of the system Signature initialisation takes place. First, the DXE core Key Exchange Key (KEK) Public part of the key is enrolled into the produces a set of Boot and Runtime Services. Boot platform firmware establishing a trust Services provide drivers, applications and Boot relationship between the firmware and the Loaders that run within the EFI environment with a OS. It determines who is authorized to update the DB and DBX number of services such as allocating memory and Signature loading executable images. Boot services are Authorized Signature Database destroyed before pass control to OS kernel. (DB) Runtime Services provide specific services to code DB of authorized signing certificates and running within the EFI environment or within the digital signatures OS kernel once it has taken control of the system. Signature Once these services have been established, the UEFI DXE dispatcher discovers and executes DXE OS Loader drivers from the firmware volume, expansion ROMs on devices connected to the PCIe bus, and Run! connected disks. Signature BDS. The Boot Device Selection phase is responsible for discovering the possible boot OS Kernel devices, selecting one to boot from, loading the Boot Loader and executing it. C. UEFI Security Mechanisms Fig. 1. Hierarchy of UEFI Trusted Key Databases and “ideal” Chain of The boot firmware is potentially attractive target for Trust (a sequence of verification of certificates and signatures) for a secure attack and should face many threats. In the UEFI OS boot. ---------------------------------------------------------------------------- 17 ---------------------------------------------------------------------------- ___________________________________________________PROCEEDING OF THE 14TH CONFERENCE OF FRUCT ASSOCIATION 2) UEFI Authenticated Variable. Time-Based Malware PEIM modules. Authenticated Write Access used to update Authenticated Malware DXE and UEFI drivers and UEFI variables like keys db. Updated variables must be signed. applications (on DXE stage). PK cert verifies PK/KEK update. KEK verifies db/dbx Malware Boot Loader (on BDS stage). update. Certdb