Posts
-
Harden your Linux UEFI Secure Boot using GRUB signature checking and a Yubikey
The goal of this article is to walk through hardening your UEFI-supported Linux desktop’s boot. This is accomplished by replacing signature checking keys with your own, keeping a portion of that key chain in an HSM/PIV device, and enabling GRUB signature checking.
-
Executing custom Option ROM on D34010WYK and persisting code in UEFI Runtime Services
In this post we’ll explore running unsigned Option ROM code on an Intel D34010WYK NUC, solely for testing purposes. We will verify that unsigned/unverified Option ROM code is not run when UEFI Secure Boot is enabled. We will demonstrate how to persist code at runtime using UEFI Runtime Services, and use a small signalling protocol to allow an unprivileged userland process to fake the contents of UEFI variables such as the SecureBoot variable.
-
Using an Option ROM to overwrite SMM/SMI handlers in QEMU
This article explores PCI Expansion ROM (or Option ROM) execution within UEFI and walks through a practical scenario of using Option ROM code to modify SMM. In order to accomplish this goal we relax the security within EDK2. Note that this article does not reveal any security weaknesses.
We begin with how to create a QEMU/OVMF/iPXE testing environment that boots Fedora with UEFI Secure Boot enabled and measures the pre-OS environment using a software TPM2. We then install an SMI handler by modifying our iPXE EFI Option ROM, which is the same as a DXE driver run during Boot Device Select (BDS). Finally, we again modify our Option ROM code and overwrite and reliably ‘shim’ an existing SMI’s handler with our own.
-
Debug UEFI code by single-stepping your Coffee Lake-S hardware CPU
In the post I will cover:
- Configuring an ASRock H370M-ITX/ac to allow DCI DbC debugging
- Using Intel System Studio and System Debugger to single-step a Coffee Lake-S i7-8700 CPU
- Debugging an example exploitable UEFI application on hardware
-
Create highly portable ELF binaries using the build-anywhere toolchain
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-anywherescripts to build a easy-to-use toolchain and set compiler flags. -
Exploring Universal Flash Storage (UFS) Write Protection on the HiKey960
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. The 960 version has an onboard Universal Flash Storage (UFS) devices, the future of MMC, and much faster! UFS as a standard has existed since 2011, but seems only since 2017 they were generally obtainable. Support in Linux has experienced very-recent updates (4.15+).
The unfortunate news is I have not found a way to implement an open-source/do-it-yourself Root of Trust on the HiKey960. I will explain why during this post, but this post will focus more on UFS write-protection.
-
Online filesystem or disk changes on embedded hardware
This is a tiny log of my experience expanding an
ext4filesystem on an embedded system that had no alternate boot option. This situation is very nuanced. If you are here because you need to make filesystem or disk changes your best course of action is to boot from a LiveUSB/CD.I moved very fast when making theses changes. There may be an easier and more efficent method, if you know one, please reach out to me!
-
DIY Root of Trust using ARM Trusted Firmware on the 96Boards Hikey
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_SELconfigured 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.Pay special attention to the should as this is not speaking from authority but rather from suspicion and research.
The Root of Trust (ROT) begins in the
BL2programmed to the eMMC’sboot0partition. The bootrom must execute the HiKey’sl-loader.binand ARM-Trusted-Firmware’s (ATF)bl2.binwritten to this alternate boot partition. The eMMC’s extended CSD register 173 (BOOT_WP) is written to permanent write-protect this content. This is a 1-time program operation that has the potential to brick the device. -
Exploring secured boot on the Sabre Lite i.MX6S (v1.3) SBC and NXP HABv4
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.
-
Hands on Introduction to ARM Firmware using the 96Boards HiKey
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.
-
Minnowboard Max: Enable the firmware (TXE) TPM 2.0
In the last two posts we walked through a ‘Secured’ Secure Boot of a Linux 4.1 kernel on the Intel Minnowboard MAX development board. If you have been following along, you have a device semi-resistant to boot and pre-boot tamperment. There is still a long road ahead, with a potential dead end for raising the Minnow’s boot security to known-perfect, but between then and now is a lot of firmware fun!
This next step will detour a bit and provide a walkthrough of UEFI platform code modifications. Pre-built firmware updates for the Minnow, in binary form, can be downloaded on it’s firmware page-- as of January 10th 2016 the latest is version 0.84. The 64-bit image does not enable the TPM 2.0, whereas the 32-bit image will. I remember reading a mention in the 0.82 release notes that the 64bit disablement was related to either export controls or a licensing conflict.
-
Minnowboard Max: Booting Linux Securely
Linux supports UEFI Secure Boot, and works out-of-the-box on boards that ‘only’ include Microsoft UEFI certificates, using a bootloader shim. The shim is a small UEFI bootloader distributed in binary form (source code), signed by Microsoft. At the most basic level the shim allows Canonical, RHEL/Fedora, and other signed grub bootloaders to be executed when UEFI Secure Boot is enabled. The shim allows system owners to extend trust beyond Microsoft without needing to modify protected UEFI variables. This is awesome because you and I can install Linux from a USB and not worry about UEFI and Secure Boot details. We also don’t need to turn off any security features to do cool stuff like run our favorite OS.
-
Minnowboard Max: Quickstart UEFI Secure Boot
This is the first post of a new collection related to Intel’s Minnowboard MAX development board. It begins with a barebones quick start leading to the simplest UEFI-based Secure Boot and paves the way towards a Secure Root of Trust Measurement (SRTM), where the “root” is the UEFI platform code.
By the end of the article the Minnowboard MAX will boot a Ubuntu 14.04 operating system using a signed shim bootloader, a signed GRUB stage 2 bootloader, and a signed Linux 3.xx kernel. The UEFI platform code will not be changed, meaning the out-of-the-box firmware will remain (no flashing), and any kernel modules or Linux executables will remain unsigned and unmeasured.
-
Beautifying your Wireshark on macOS
Need to do some fast and crazy Wireshark hacking? Or are you using Wireshark everyday on macOS and hate the ugly default GTK styling? Let’s make Wireshark beautiful!
-
A Compendium to UEFI Hacking
There are quite a few operating/execution environments running below or before an Operating System’s kernel. Computer science calls protection domains “Rings” and an Operating system’s kernel is called “Ring 0” or “Supervisor mode”. Researchers have called the lower-level environments Ring -1 (Hypervisor mode), and Ring -3 (“system management mode”), and they are fairly apt-names. I like to bundle all of these into a scary-but-funny-and-fitting name subzero, dun dun dun!
-
Embedded Trust (P2): U-Boot Secured Boot
This post will function as a short walk through for installing and using a TPM on a BeagleBone to implement a Secured Boot (wooo…). I will use an example Secure Boot implementation called libsboot for U-Boot. Let’s jump right in with a schematic for the (mostly) required additions to the BeagleBone.
-
Embedded Trust (P1): Beginning to trust my BeagleBone
I plan to have a series of posts outlining my curiosity with embedded development and trust. Let’s start with poking around where my (our) trust lies when deciding on a SoC for embedded development, using the SRM] as an example. In this post we’ll move trust from CircuitCO’s (the Bone manufacture) included bootloaders, Angstrom Linux kernel, and Angstrom development environment to your own compiled bootloaders, kernel, and OS.
-
How To: DIY (Improved) Inexpensive Fog Screen
Last month we built an improved version of the DIY Fog Screen found here.
-
Gelf: L1 Emulation, L2 Tunneling, using an HTTP Client
Simply: Gelf uses an HTTP client to bridge two or more networks. The iPhone is the primary use case; it has access to both AT&T’s mobile network as well as an ad-hoc network. You can bridge the two using Gelf, without running any code on the iPhone, aside from client-side HTML and JavaScript.
This achieves a non-jailbroken, non-rooted, poor-man’s network tether. Here’s the catch, Gelf needs to run on a device inside each target network. Gelf functions as the L2 tunnel end-points, and the L1 emulation: achieved through an HTTP client.
-
Offensive Defense: Protect your high-hanging fruit ...from birds and stuff
One of these days this webserver will be torn open by some low-hanging vulnerability. Sure, but that wont be very exciting, so let’s think outside of the inevitable, and into the what-if.
-
SIM card curiosity, and a little Hardware Hacking
A few months ago I took an interest in the layer 2/3 protocols (and their implementations) for mobile networks. I quickly arrived at SIM card hacking and like a young schoolboy thought, “man if only I could MitM the hardware communication I could spoof other’s SIM cards and use free Internet!” Nope. Well, not nope, but it’s not that easy.
-
Adventures in UAV Hacking
My first accepted workshop paper, accepted to USENIX WOOT 2011, was called “SkyNET: A 3G-enabled mobile attack drone and stealth botmaster”. Catchy name, right? Check out the project page if you’d like a review. After the paper was published, presented, and let lie for a month, the project caught the attention of MIT Technology Review. Shortly after the story was published tons of other websites started duplicating and running their own. The relation between UAVs and “Skynet” did the trick in attracting media attention. Unfortunately there’s very little AI incorporated thus far into the project. Nevertheless, it’s been a blast reading the various comments on the project.
-
Finding a vulnerability was the first step
Finding vulnerabilities is fun, but following through with assessing exploitability is my favorite. This is a review of something I found very entertaining. An example of using a small stored XSS vulnerability on a simple web application to do complicated results manipulation.
-
Route based on Source IP Address (Linux / BSD)
I ran into an interesting situation the other day which I expected would have more documentation online.
Situation: You have a multi-homed router and you would like to route traffic based on client IP addresses, or the source address. In my case I wanted a /24 (Net 1) to be directed (forwarded) through interface A, and another /24 (Net 2) to be forwarded through interface B. In my case I also NATed traffic forwarded to interface A.
This is called source address routing or policy-based routing.
-
Proxied Email Addresses per-Application
Abstract: I wanted some mechanic in email, such that I could tell how a person found my address. Since I post my email address to many web sites, I wanted a way to track which web sites knew which emails. So I wrote a small script which allowed me to think of email addresses on the fly and distribute them. When someone responded to the emails they would be analyzed and forwarded to my inbox with a reply-to address that would take the opposite route and be sent as the ‘on-the-fly’ email address.
subscribe via RSS