Automatic device management in Azure IoT Hub automates many of the repetitive and complex tasks of managing large device fleets over the entirety of their lifecycles. Since the feature shipped in June 2018, there has been a lot of interest in the firmware update use case. This blog article highlights some of the ways you can kickstart your own implementation.
When a Patch is Not Enough – HardFails: Software-Exploitable Hardware Bugs
Ghada Dessouky, David Gens, Patrick Haney, Garrett Persyn, Arun Kanuparthi, Hareesh Khattri, Jason M. Fung, Ahmad-Reza Sadeghi, Jeyavijayan Rajendran
(Submitted on 1 Dec 2018)
In this paper, we take a deep dive into microarchitectural security from a hardware designer’s perspective by reviewing the existing approaches to detect hardware vulnerabilities during the design phase. We show that a protection gap currently exists in practice that leaves chip designs vulnerable to software-based attacks. In particular, existing verification approaches fail to detect specific classes of vulnerabilities, which we call HardFails: these bugs evade detection by current verification techniques while being exploitable from software. We demonstrate such vulnerabilities in real-world SoCs using RISC-V to showcase and analyze concrete instantiations of HardFails. Patching these hardware bugs may not always be possible and can potentially result in a product recall. We base our findings on two extensive case studies: the recent Hack@DAC 2018 hardware security competition, where 54 independent teams of researchers competed world-wide over a period of 12 weeks to catch inserted security bugs in SoC RTL designs, and an in-depth systematic evaluation of state-of-the-art verification approaches. Our findings indicate that even combinations of techniques will miss high-impact bugs due to the large number of modules with complex interdependencies and fundamental limitations of current detection approaches. We also craft a real-world software attack that exploits one of the RTL bugs from Hack@DAC that evaded detection and discuss novel approaches to mitigate the growing problem of cross-layer bugs at design time.
SPECTECTOR: Principled Detection of Speculative Information Flows
Marco Guarnieri, Boris Köpf, José F. Morales, Jan Reineke, Andrés Sánchez
(Submitted on 20 Dec 2018)
Since the advent of SPECTRE, a number of countermeasures have been proposed and deployed. Rigorously reasoning about their effectiveness, however, requires a well-defined notion of security against speculative execution attacks, which has been missing until now. We present a novel, principled approach for reasoning about software defenses against SPECTRE-style attacks. Our approach builds on speculative non-interference, the first semantic notion of security against speculative execution attacks. We develop SPECTECTOR, an algorithm based on symbolic execution for automatically proving speculative non-interference, or detecting violations.
We implement SPECTECTOR in a tool, and we use it to detect subtle leaks — and optimizations opportunities — in the way major compilers place SPECTRE countermeasures.
Extracting Secrets from Encrypted Virtual Machines
Mathias Morbitzer, Manuel Huber, Julian Horsch
(Submitted on 7 Jan 2019)
AMD SEV is a hardware extension for main memory encryption on multi-tenant systems. SEV uses an on-chip coprocessor, the AMD Secure Processor, to transparently encrypt virtual machine memory with individual, ephemeral keys never leaving the coprocessor. The goal is to protect the confidentiality of the tenants’ memory from a malicious or compromised hypervisor and from memory attacks, for instance via cold boot or DMA. The SEVered attack has shown that it is nevertheless possible for a hypervisor to extract memory in plaintext from SEV-encrypted virtual machines without access to their encryption keys. However, the encryption impedes traditional virtual machine introspection techniques from locating secrets in memory prior to extraction. This can require the extraction of large amounts of memory to retrieve specific secrets and thus result in a time-consuming, obvious attack. We present an approach that allows a malicious hypervisor quick identification and theft of secrets, such as TLS, SSH or FDE keys, from encrypted virtual machines on current SEV hardware. We first observe activities of a virtual machine from within the hypervisor in order to infer the memory regions most likely to contain the secrets. Then, we systematically extract those memory regions and analyze their contents on-the-fly. This allows for the efficient retrieval of targeted secrets, strongly increasing the chances of a fast, robust and stealthy theft.
S²E is a platform for writing tools that analyze the properties and behavior of software systems. S²E comes as a modular library that gives virtual machines symbolic execution and program analysis capabilities. S²E runs unmodified x86, x86-64, or ARM software stacks, including programs, libraries, the kernel, and drivers. Symbolic execution then automatically explores hundreds of thousands of paths through the system, while analyzers check that the desired properties hold on these paths and selectors focus path exploration on components of interest. S²E is now commercially supported by Cyberhaven. It is free for non-commercial use. S²E was a research project of the Dependable Systems Lab at EPFL in Lausanne.
This past January, I ordered a new TV. […] The TV was manufactured by Sceptre Inc. (note the ‘C’ and ‘P’ switch) and was covered in SCEPTRE branding. My goal for this project was to perform a hardware-level attack against the TV and change the branding to SPECTRE as an homage to the microarchitectural attack. This project has nothing to do with exploiting speculative execution, but instead it demonstrates several common techniques NCC Group uses when analyzing embedded systems.[…]
Hacking Your Way to a Custom TV Boot Screen
The Bareflank Hypervisor is an open source, hypervisor Software Development Toolkit (SDK), led by Assured Information Security, Inc. (AIS), that provides a set of APIs needed to rapidly prototype and create new hypervisors. To ease development, Bareflank is written in C/C++, and includes support for C++ exceptions, JSON, the GSL and the C++ Standard Template Library (STL).
Steve McIntyre has posted an update on Debian’s UEFI Secure Boot status, to the debian-boot and debian-efi mailing lists. Excerpt:
I’ve just pushed changes to a few bits of d-i this weekend to make SB work for amd64:
* build/util/efi-image: […]
* build/config/arm.cfg, build/config/x86.cfg: […]
* debian/control: […]
* grub-installer/grub-installer: […]
The effect of these changes is that the next daily and weekly debian installer images (tomorrow) should Just Work (TM) end-to-end with UEFI Secure Boot. The changes to efi-image also mean that our next live image builds will do SB (for live and installation).
I’ll test all these again in the next couple of days to verify that things have pulled through as I expect, then it’s time to post to d-d-a and write a blog too. We’ve made great progress already. These last changes just tie it all together for end users.
The HDK is an updated version of the HvGdk.h header file published under MSR-LA as part of the Singularity Research Kernel. It has been updated to add the latest definitions, structures and definitions as described in the Microsoft Hypervisor Top-Level Functional Specification (TLFS) 5.0c published June 2018.
“UefiLog is a lightweight log system in UEFI environment“
by Stephano Cetola, Software Applications Engineer, Intel Corportation
CHIPSEC is a firmware threat assessment tool used to help verify that systems meet basic security best practices. The tool’s threat model is primarily based on Unified Extensible Firmware Interface (UEFI). However, other firmware may have different threat models that will cause failures in different CHIPSEC modules. This session is a brief overview of CHIPSEC, limitations of the tool, failures seen on different types of firmware, and information on developing new test modules.
Angora: Efficient Fuzzing by Principled Search
Peng Chen, Hao Chen
(Submitted on 4 Mar 2018 (v1), last revised 27 Mar 2018 (this version, v2))
Fuzzing is a popular technique for finding software bugs. However, the performance of the state-of-the-art fuzzers leaves a lot to be desired. Fuzzers based on symbolic execution produce quality inputs but run slow, while fuzzers based on random mutation run fast but have difficulty producing quality inputs. We propose Angora, a new mutation-based fuzzer that outperforms the state-of-the-art fuzzers by a wide margin. The main goal of Angora is to increase branch coverage by solving path constraints without symbolic execution. To solve path constraints efficiently, we introduce several key techniques: scalable byte-level taint tracking, context-sensitive branch count, search based on gradient descent, and input length exploration. On the LAVA-M data set, Angora found almost all the injected bugs, found more bugs than any other fuzzer that we compared with, and found eight times as many bugs as the second-best fuzzer in the program who. Angora also found 103 bugs that the LAVA authors injected but could not trigger. We also tested Angora on eight popular, mature open source programs. Angora found 6, 52, 29, 40 and 48 new bugs in file, jhead, nm, objdump and size, respectively. We measured the coverage of Angora and evaluated how its key techniques contribute to its impressive performance.
A GUI Test Tool comparing JSON with SPEC using excel
Crackme from “PHDays-2018” event