Tag: Teddy Reed

Debug UEFI code by single-stepping your Coffee Lake-S hardware CPU

~ hucktech ~ Leave a comment

Teddy Reed of Facebook has a new blog post on using Intel DCI, UEFI Tool, Intel System Studio, and other tools:

TL;DR, if you have a newer CPU & chipset you can purchase a $15 off-the-shelf cable and single-step your hardware threads. The cable is a USB 3.0 debugging cable; and is similar to an ethernet crossover cable in the sense that the internal wiring is crossed. Be careful with this cable as unsupported machines will have undefined behavior due to the electronics of USB.

https://casualhacking.io/blog/2019/6/2/debug-uefi-code-by-single-stepping-your-coffee-lake-s-hardware-cpu

build-anywhere: Create highly portable ELF binaries using the build-anywhere toolchain

~ hucktech ~ Leave a comment

This post describes the basic requirements for compiling highly portable ELF binaries. Essentially using a newer Linux distro like Ubuntu 18.10 to build complex projects that run on older distros like CentOS 6. The details are limited to C/C++ projects and to x86_64 architectures. The low-level solution is to use a C++ runtime that requires only glibc 2.13+ runtime linkage and link all third-party libraries as well as the compiler runtime and C++ implementation statically. Do not make a “fully static” binary. You will most likely find a glibc newer than 2.13 on every Linux distribution released since 2011. The high-level solution is to use the build-anywhere scripts to build a easy-to-use toolchain and set compiler flags.[…]

https://github.com/theopolis/build-anywhere

https://casualhacking.io/blog/2018/12/25/create-highly-portable-elf-binaries-using-the-build-anywhere-toolchain

Ted Reed: Exploring Universal Flash Storage (UFS) Write Protection on the HiKey960

~ hucktech ~ Leave a comment

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.[…]

https://casualhacking.io/blog/2018/10/6/exploring-universal-flash-storage-ufs-write-protection-on-the-hikey960

see-also: https://casualhacking.io/blog/2018/7/8/diy-root-of-trust-using-arm-trusted-firmware-on-the-96boards-hikey

DIY Root of Trust using ARM Trusted Firmware on the 96Boards Hikey

~ hucktech ~ Leave a comment

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.[…]

https://casualhacking.io/blog/2018/7/8/diy-root-of-trust-using-arm-trusted-firmware-on-the-96boards-hikey

https://www.96boards.org/documentation/consumer/hikey/getting-started/

CVE-2018-1000205: U-Boot, Verified Boot input validation

~ hucktech ~ Leave a comment

Re: https://firmwaresecurity.com/2018/06/26/cve-2018-1000205-u-boot/

and https://firmwaresecurity.com/2018/06/07/teddy-reed-on-u-boots-verified-boot/

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.

https://nvd.nist.gov/vuln/detail/CVE-2018-1000205

https://lists.denx.de/pipermail/u-boot/2018-June/330454.html

https://lists.denx.de/pipermail/u-boot/2018-June/330898.html

Teddy Reed on U-Boot’s Verified Boot

~ hucktech ~ 1 Comment

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 [1], [2], [3]. 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.

[1] https://lists.denx.de/pipermail/u-boot/2018-June/330454.html
[2] https://lists.denx.de/pipermail/u-boot/2018-June/330487.html
[3] https://lists.denx.de/pipermail/u-boot/2018-June/330599.html

https://lists.denx.de/pipermail/u-boot/2018-June/330898.html

Teddy Reed: Exploring secured boot on the Sabre Lite i.MX6S (v1.3) SBC and NXP HABv4

~ hucktech ~ Leave a comment

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.[…]

https://prosauce.org/blog/2018/2/10/exploring-secured-boot-on-the-sabre-lite-imx6s-v13-sbc-and-nxp-habv4

The i/MX image header, where Image Data can be U-Boot, followed by an optional CSF.

more from Duo on Apple EFI security

~ hucktech ~ Leave a comment

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:

https://docs.google.com/spreadsheets/d/1qGRVF1aRokQgm_LuTsFUN2Knrh0Sd3Gp0ziC_VIWqoM/edit#gid=0

Team Security on UEFI malware

~ hucktech ~ Leave a comment

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.”

https://tsecurity.de/de/109335/IT-Security/Malware-Trojaner-Viren/Putting-the-spotlight-on-firmware-malware/

Teddy Reed on firmware attacks TONIGHT

~ hucktech ~ Leave a comment

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.

https://www.eventbrite.com/e/fastly-security-speaker-series-part-2-tickets-25216388898

U-Boot Verified Boot to get security improvements

~ hucktech ~ Leave a comment

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.

Full post/thread:
http://lists.denx.de/mailman/listinfo/u-boot

Facebook on defending against firmware threats (and osquery)

~ hucktech ~ Leave a comment

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. […]

Full post:
https://code.facebook.com/posts/182707188759117

I’ve not used Facebook’s osquery before, so I have a lot of catching up to do. ;-(
https://github.com/facebook/osquery
https://osquery.io/
https://code.facebook.com/projects/658950180885092/osquery/
https://code.facebook.com/posts/844436395567983/introducing-osquery/
https://osquery-slack.herokuapp.com/

Teddy Reed’s SMC fuzzer

~ hucktech ~ Leave a comment

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.

https://github.com/theopolis/smc-fuzzer

Click on the above Twitter URL for the follow-up conversation with some more information about SMC.

UEFI Firmware Parser now in Cheese Shop

~ hucktech ~ Leave a comment

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.

https://pypi.python.org/pypi/uefi_firmware

https://firmwaresecurity.com/2015/12/28/uefi-firmware-parser-updated-2/

Teddy Reed on bypassing Linux Secure Boot

~ hucktech ~ Leave a comment

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. […]

http://prosauce.org/blog/2015/10/31/booting-linux-securely

https://firmwaresecurity.com/2015/09/19/teddy-reed-research-on-minnow-firmware/
https://firmwaresecurity.com/2015/07/17/secure-boot-strength-varies-by-linux-implementation/

libSboot: Secure Boot for U-Boot

~ hucktech ~ Leave a comment

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.

https://github.com/theopolis/sboot
https://github.com/theopolis/u-boot-sboot
http://www.trustedcomputinggroup.org/community/2013/03/securing_embedded_devices_with_the_tpm__a_schmoocon_talk
http://prosauce.org/blog/2013/2/11/embedded-trust-p2-u-boot-secured-boot.html