Trammell Hudson

spispy is an open source hardware tool for emulating SPI flash chips that makes firmware development and boot security research easier. In this talk we'll discuss the challenges of interfacing on the SPI bus and emulating SPI devices, as well as demonstrate how to use it quickly debug issues with coreboot and how we used spispy to discover a critical class of TOCTOU vulnerabilities in secure boot systems like Intel BootGuard.

Hardware implants and supply chain attacks have been in the news recently, but how feasible are they and what can we do about them? In this talk we'll examine the design of a proof of concept SPI bus hardware implant that has similar capabilities to those described in the Bloomberg/Supermicro article as well as some countermeasures that we can use to try to detect these "modchips" and increase our trust in our systems.

We don't know how much of the Bloomberg story about hardware implants installed in Supermicro servers shipped to Apple and Amazon is true, nor do we know the story behind the story and the reasons for the vehement denials by all the parties involved. However, a technical assessment of details of the describe implants reveals that a supply chain attack on the hardware is definitely possible, that the capabilities of the BMC can be used to bypass OS protections, and that there are means to access the BMC that would not necessarily generate readily identified network traffic. In this talk we'll examine the design of a proof of concept SPI bus hardware implant that has similar capabilities to those described in the Bloomberg/Supermicro article as well as some countermeasures that we can use to try to detect these "modchips" and increase our trust in our systems.

Firmware security track keynote

The NERF and Heads projects bring Linux back to the cloud servers' boot ROMs by replacing nearly all of the vendor firmware with a reproducible built Linux runtime that acts as a fast, flexible, and measured boot loader. It has been years since any modern servers have supported Free Firmware options like LinuxBIOS or coreboot, and as a result server and cloud security has been dependent on unreviewable, closed source, proprietary vendor firmware of questionable quality. With Heads on NERF, we are making it possible to take back control of our systems with Open Source Software from very early in the boot process, helping build a more trustworthy and secure cloud.

The NERF project was started by Ron Minnich (author of LinuxBIOS and lead of coreboot at Google) in January 2017 with the goal to bring Linux back to the BIOS by retaining a minimal set of PEI modules for memory controller initialization and replacing the entirety of the server vendor's UEFI DXE firmware with a reproducibly built Linux runtime. It has been ported to a few different manufacturer's servers, demonstrating the general portability of the concept. NERF is fast - less than twenty second boot times, versus multiple minutes. It's flexible - it can make use of any devices, filesystems and protocols that Linux supports. And it's open - users can easily customize the boot scripts, fix issues, build their own runtimes and reflash their firmware with their own keys. The Heads runtime was started by Trammell Hudson (author of Thunderstrike and Magic Lantern) and was presented last year at 33c3. It is a slightly more secure bootloader that uses Linux, the TPM, GPG and kexec to be able to load, measure, verify and execute the real kernel. As part of porting Heads to work with NERF on server platforms, it now includes tools like Keylime to allow severs to remotely attest to user controlled systems that the NERF/Heads firmware matches what they expect, as well as network and iSCSI drivers for diskless compute node servers. In this talk we'll provide an overview of the NERF project, the currently supported server mainboards, and the continued development on the Heads runtime that allows more trust in the servers that make up the cloud.

Heads is an open source custom firmware and OS configuration for laptops and servers that aims to provide slightly better physical security and protection for data on the system. Unlike Tails, which aims to be a stateless OS that leaves no trace on the computer of its presence, Heads is intended for the case where you need to store data and state on the computer. It targets specific models of commodity hardware and takes advantage of lessons learned from several years of vulnerability research. This talk provides a high level overview of Heads, a demo of installing it on a Thinkpad and a tour of some of the attacks that it protects against.

Heads builds on several years of firmware security research focused on firmware vulnerabilities ("Thunderstrike: EFI bootkits for Apple Macbooks" and "Thunderstrike 2") as well as many other CCC talks ("Hardening hardware and choosing a #goodBIOS", "Beyond anti evil maid", "Towards (reasonably) trustworthy x86 laptops", etc.) and combines these ideas into a single system. It is not just another Linux distribution - it combines physical hardening and flash security features with custom Coreboot firmware and a Linux boot loader in ROM. This moves the root of trust into the write-protected ROM and prevents further modifications to the bootup code. Controlling the first instruction the CPU executes allows Heads to measure every step of the boot process into the TPM, which makes it possible to attest to the user or a remote system that the firmware has not been tampered with. While modern Intel CPUs require binary blobs to boot, these non-Free components are included in the measurements and are at least guaranteed to be unchanging. Once the system is in a known good state, the TPM is used as a hardware key storage to decrypt the drive. Additionally, the hypervisor, kernel and initrd images are signed by keys controlled by the user, and the OS uses a signed, immutable root filesystem so that any software exploits that attempt to gain persistence will be detected. While all of these firmware and software changes don't secure the system against every possible attack vector, they address several classes of attacks against the boot process and physical hardware that have been neglected in traditional installations, hopefully raising the difficulty beyond what most attackers are willing to spend.

In this talk I'll show how to build an open source vector gaming system with MAME, a microcontroller and an XY monitor or oscilloscope. Relive the joys of playing vector video games from 1979 and enjoy some of the retro-styled vector games of 2015.

Other people: Adelle Lin

Last year at 31c3 we disclosed Thunderstrike, the first firmware attacks against Macbooks.

This year we’ve ported old UEFI vulnerabilities to the Mac and will demo Thunderstrike 2, an extension to the attack that no longer requires physical access and can replicate via shared Thunderbolt devices.

In this presentation we demonstrate Thunderstrike, a vulnerability that allows the installation of persistent firmware modifications into the EFI boot ROM of Apple's popular MacBooks. The bootkit can be easily installed by an evil-maid via the externally accessible Thunderbolt ports and can survive reinstallation of OSX as well as hard drive replacements. Once installed, it can prevent software attempts to remove it and could spread virally across air-gaps by infecting additional Thunderbolt devices.

It is possible to use a Thunderbolt Option ROM to circumvent the cryptographic signature checks in Apple's EFI firmware update routines. This allows an attacker with physical access to the machine to write untrusted code to the SPI flash ROM on the motherboard and creates a new class of firmware bootkits for the MacBook systems. There are neither hardware nor software cryptographic checks at boot time of firmware validity, so once the malicious code has been flashed to the ROM, it controls the system from the very first instruction. It could use SMM and other techniques to hide from attempts to detect it. Our proof of concept bootkit also replaces Apple's public RSA key in the ROM and prevents software attempts to replace it that are not signed by the attacker's private key. Since the boot ROM is independent of the operating system, reinstallation of OS X will not remove it. Nor does it depend on anything stored on the disk, so replacing the harddrive has no effect. A hardware in-system-programming device is the only way to restore the stock firmware. Additionally, Thunderbolt devices' Option ROMs are writable from code that runs during the early boot and the bootkit could write copies of itself to new Thunderbolt devices. The devices remain functional, which would allow a stealthy bootkit to spread across air-gap security perimeters through shared Thunderbolt devices. While the two year old Option ROM vulnerability that this attack uses can be closed with a few byte patch to the firmware, the larger issue of Apple's EFI firmware security and secure booting with no trusted hardware is more difficult to fix.