In my previous post I gave an overview of basic “do it yourself” root-of-trust creation through MMC boot region write-protection. I used this on sample HiKey (original) devices to authenticate ARM-Trusted-Firmware code beyond BL2, authenticating the OPTEE OS and U-Boot as BL33. This post explores the same concept on a HiKey960.[…]
Teddy Reed has updated his UEFI Firmware Parser project. The first update this year!
This is a series of notes designed to be a walkthrough on how to configure the HiKey Kirin 620 to boot securely with ARM Trusted Firmware’s Trusted Board Boot. This does not use any proprietary settings or vendor-specific details about the SoC. Instead, the secure boot path relies on the SoC’s BOOT_SEL configured to boot solely from the eMMC. With this configuration there should be no way to interrupt or bypass the root of trust via runtime changes.[…]
There is now a description for the CVE. Ah, this makes sense, the Verified Boot issues that Teddy Reed brought up earlier:
U-Boot contains a CWE-20: Improper Input Validation vulnerability in Verified boot signature validation that can result in Bypass verified boot. This attack appear to be exploitable via Specially crafted FIT image and special device memory functionality.
Teddy Reed, author of UEFI Firmware Parser, among other things, has some U-Boot Verified Boot issues:
Verified boot production uses question
Hi all, question, is anyone using the U-Boot verified-boot in production? I am using configuration verification for several OpenCompute/OpenBMC boards. After a deep-dive review I found some edge cases that in rare circumstances could lead to a signature check bypass. I think this is low-risk at best since the scenario requires special hardware behavior to exist. Our board were susceptible in the general sense, but we had implemented some additional sanity checks on the FIT structures that
prevented this. There are some proposed changes that attempt to mitigate this , , . Any one of these changes mitigates the bypass scenario. If you don’t mind reaching out to me I can share the exact situation/details.
Exploring secured boot on the Sabre Lite i.MX6S (v1.3) SBC and NXP HABv4
February 10, 2018
This document is a linear review of my notes taken while exploring the Sabre Lite single-board-computer. It is a mildly expensive ($200 from Boundary Devices) SBC but it has a well documented secure boot implementation rooted in silicon ROM. It is a very good example of a vendor proprietary firmware verification mechanism. The goal of this article is purely an overview of notes, nothing here is novel or groundbreaking and it is not intended to be a tutorial.[…]
Nice, in addition to an upcoming new EFI tool, it appears Duo has some defensive advise, using OSQuery, Puppet, and Chef. Click on the first tweet below for an image from their upcoming presentation.
Note that Teddy Reed is giving a presentation on OSQuery in November at Usenix LISA:
Pepjin’s Apple EFI version spreadsheet:
Team Security has an article on firmware malware, focusing on UEFI-centric malware, with many references to VirusTotal.com-based images.
[…]”We would like to specially thank Teddy Reed, developer of the UEFI firmware python parser, he has been instrumental in helping us overcome our ignorance about BIOS, UEFI, and its ecosystem.”
“This is a walkthrough for flashing custom ARM Trusted Firmware, OP-TEE, and the ARM UEFI Platform code on the Hikey board. Custom means code we’ve built it on our development machine, we’re not making any changes to these reference implementations just yet.[…]”
The video is online, no pointer to slides found:
Short notice, but if you are reading this immediately and are in Bay Area, then you might be able to attend. The rest of us will have to hope they videotape this and share the archive.
Defending, detecting, and responding to hardware and firmware attacks
This presentation takes a different approach to hardware and firmware security by exploring how our enterprise defenders can recognize vulnerable systems and potential compromise. Defense begins with visibility, that means baselining kernel drivers, kernels, boot loaders, ACPI table content, SMBIOS metadata; it then continues into logging real time OS API-generated hardware events. This data and pipeline can fuel existing correlation and IoC collections to identify known good and eventually known bad. Creating production deployable and repeatable recipes for these somewhat esoteric features is essential. We will present a summary of immediate tools and actions for “deep systems defense”, an analysis of where our defenders remain blind to compromise, and recommendations on where our industry can focus tailored effort to generate massive impact.
Teddy is a Security Engineer at Facebook developing production security tools. He is very passionate about trustworthy, safe, and secure code development. He loves open source and collaborative engineering when scale, resiliency, and performance enable defensive and protective software design.
Teddy Reed is proposing a change to U-Boot to support multiple levels of signing keys. Currently this is still at discussion phase, here’s Teddy’s initial post.
I’m looking to support “multiple levels” of keys within u-boot’s verified boot. I need something similar to UEFI’s key enrollment key (KEK) and db/dbx model such that I can support on-line signing of new kernels/rootfs/configurations. To make this work we need a KEK that is not online (kept in a safe), that can be used to sign expirations (revocations) of on-line signing keys in the case of compromise or private key reveals. I know Chrome’s Coreboot verified boot model supports this, wondering if there’s any staged / WIP for u-boot? Off the top of my head I’d imagine this requires extending the FIT to include sets of public keys and a blacklist of keys and expired or bad kernel/rootfs/etc hashes. Then either extending the boot code to inspect multiple FITs or extending mkimage to combine multiple sources to amalgamate a FIT containing the PK-signed set of keys + hashes and the on-line key-signed kernels/rootfs/configurations.
P.S. This may be strongly linked to the need for a TPM to prevent rollbacks. But as far as I can tell, the two features are distinct and a TPM is not completely required for a multi-level key approach to signing FITs.
Ted Reed of Facebook — aka the Teddy Reed who creates UEFI Firmware Parser and related tools — posted a VERY GOOD article on how Facebook defends systems against hardware and firmware attacks, including coverage of Facebook’s osquery tool, and his recent Usenix Enigma presentation. Excerpt of introduction (with whitespace editing by me, sorry):
Hardware and Firmware Attacks: Defending, Detecting, and Responding
The attack landscape for firmware is maturing and needs more attention from defense and detection communities. Recent examples of firmware attacks include the Equation Group’s attacks on drive firmware, Hacking Team’s commercialized EFI RAT, Flame, and Duqu. Simple tools like osquery give defenders important insights about what’s happening on their network so they can quickly detect a potential compromise. Facebook released osquery as an open source project in 2014. Facebook recently added hardware monitoring to osquery, which already aids security teams in vulnerability management, incident response, OS X attacks, and IT compliance. Firmware on commodity laptops and servers is interesting to me as a security engineer for several reasons. This code often bootstraps trust protocols and protective architecture primitives. At the same time, it is a target for vulnerabilities aimed at bypassing those exact controls to unlock, jailbreak, and homebrew — for either good or malicious purposes. Firmware is also a vector for virtualization escapes, hypervisor attacks, and extreme persistence. That risk is magnified by the same fragmentation problem plaguing Android devices, but with an even more complex ecosystem of developers and supported devices. Recent examples of firmware attacks include the Equation Group’s attacks on drive firmware, Hacking Team’s commercialized EFI RAT, Flame, and Duqu. Trammell Hudson’s Thunderstrike-style local system takeover is fast and effective. Drew Suarez’s demonstrations of firmware flashing of Android devices take four seconds of a distracted local user’s attention. Additionally, Computrace has used a UEFI DXE driver capable of injecting a RAT onto unencrypted NTFS partitions for several years. All of this makes firmware security critical for protecting your enterprise. This week, I shared recent work on firmware security at the Enigma 2016 Conference, hosted by USENIX. Since releasing osquery to open source in 2014, I’ve been using it to explore new ways to recognize vulnerable systems and potential compromise. Defensive security professionals should begin scoping firmware components and use simple tools like osquery to gather insight and signal from their corporate network. […]
I’ve not used Facebook’s osquery before, so I have a lot of catching up to do. ;-(
Teddy Reed has a new article out.
If you care about TPM or UEFI you should read this article!
In addition to UEFI Firmware Parser, and other tools, Teddy Reed *ALSO* has written a fuzzer for Apple SMC firmware:
devnull’s SMC read/write code, along with simple fuzz options. This smc tool uses the AppleSMC IOKit interface and a userland API for interacting with the System Management Controller (Mac embedded controllers). The tool focuses on the SMC key/value API, but could be expanded to more API methods.
Click on the above Twitter URL for the follow-up conversation with some more information about SMC.
The other day I noticed some Github activity for Teddy Reed’s UEFI Firmware Parser, but didn’t notice any formal new announcement. It appears I was not looking in the right place. The parser is now in the official Python Cheese Shop! And it is named “uefi_firmware”, not UEFI Firmware Parser, that explains that comment in the comment log. 🙂 It’ll be nice to have this tool more easily-available in Python. I hope the next time the UEFI Forum updates it’s UEFI port of CPython, they add this module to the UEFI port.
Teddy Reed has a second article on UEFI, MinnowboardMax and Linux! This one is called “Minnowboard Max: Booting Linux Securely”, and talks about how the Linux shim is used, and enumerates the various ways this boot security can be bypassed.
[…] I say ‘more-or-less’ because there are tons of places where the verification can be subverted. Unfortunately, if you start examining the implementation and configuration details of the streamlined Secure Boot support, you’ll find plenty of bypasses. Let’s talk briefly about each bypass and conclude with a simple way to use Secure Boot and enforce a signed kernel execution on Ubuntu. To be clear, there are no vulnerabilities here as there is no documented intention to boot Linux securely (e.g., BUG/1401532), only to support a Secure Boot and boot Linux. […]
Teddy Reed wrote libSboot 3 years ago, and I am just noticing it. 😦 This “Secure Boot” is different than the UEFI definition/implementation, and is U-Boot-specific. Excerpting the readme:
libSboot provides an example ‘Secured Boot’ for U-Boot and a U-Boot Second Phase Loader (SPL). libSboot attempts to define an example of how a platform can measure a pre-OS boot environment, thus providing a capability to ensure that a libSboot-enforced OS is only loaded in an owner-authorized fashion. A ‘Secure Boot’ concept is a common means to ensure platform security and integrity; understand that there are many implementations of a ‘Secure Boot’. libSboot uses a TPM v1.2 to implement a secure boot using a static root of trust measurement (SRTM). The static adjective implies a ‘read-only’ attribute, meaning libSboot expects its initialization to occur from ROM code. During this initialization libSboot performs a TPM_Start, TPM_SelfTest and checks that the TPM is neither deactivated nor disabled. The TPM must have its NVRAM locked, meaning access control is enforced. Initialization then checks each PCR used to measure the pre-boot environment and verifies they are reset. Finally Physical Presence is asserted to satisfy NVRAM read/write permissions.
As found by ‘retweeted’ by the CHIPSEC team:
Teddy Reed has an EXCELLENT blog post — the first in a series! — going into detail about the firmware of Intel’s MinnowBoard.
Again, this is an EXCELLENT article, worth reading!
Teddy Reed recently updated UEFI Firmware Parser.
The main new feature appears to be Intel Management Engine (ME) support: