Black Hat Briefings US 2016 just announced their schedule, and it has multiple firmware security-related presentations, the most interesting ones (that I found) are listed below:

Full schedule:

https://www.blackhat.com/us-16/briefings.html

Analysis of the Attack Surface of Windows 10 Virtualization-Based Security
Rafal Wojtczuk
In Windows 10, Microsoft introduced virtualization-based security (VBS), the set of security solutions based on a hypervisor. In this presentation, we will talk about details of VBS implementation and assess the attack surface – it is very different from other virtualization solutions. We will focus on the potential issues resulting from the underlying platform complexity (UEFI firmware being a primary example). Besides a lot of theory, we will also demonstrate actual exploits: one against VBS itself and one against vulnerable firmware. The former is non-critical (provides bypass of one of VBS features), the latter is critical. Before attending, one is encouraged to review the two related talks from Black Hat USA 2015: “Battle of the SKM and IUM: How Windows 10 Rewrites OS Architecture” and “Defeating Pass-the-Hash: Separation of Powers.”

Horse Pill: A New Type of Linux Rootkit
Michael Leibowitz
What if we took the underlying technical elements of Linux containers and used them for evil? The result a new kind rootkit, which is even able to infect and persist in systems with UEFI secure boot enabled, thanks to the way almost every Linux system boots. This works without a malicious kernel module and therefore works when kernel module signing is used to prevent loading of unsigned kernel modules. The infected system has a nearly invisible backdoor that can be remote controlled via a covert network channel. Hope is not lost, however! Come to the talk and see how the risk can be eliminated/mitigated. While this may poke a stick in the eye of the current state of boot security, we can fix it!

A Lightbulb Worm?
Colin O’Flynn
Could a worm spread through a smart light network? This talk explores the idea, and in particular dives into the internals of the Philips Hue smart light system, and details what security has been deployed to prevent this. Examples of hacking various aspects of the system are presented, including how to bypass encrypted bootloaders to read sensitive information. Details on the firmware in multiple versions of the Philips Hue smart lamps and bridges are discussed. This talk concentrates on examples of advanced techniques used in attacking IoT/embedded hardware devices.

What’s the DFIRence for ICS?
Chris Sistrunk  &  Josh Triplett
Digital Forensics and Incident Response (DFIR) for IT systems has been around quite a while, but what about Industrial Control Systems (ICS)? This talk will explore the basics of DFIR for embedded devices used in critical infrastructure such as Programmable Logic Controllers (PLCs), Remote Terminal Units (RTUs), and controllers. If these are compromised or even have a misoperation, we will show what files, firmware, memory dumps, physical conditions, and other data can be analyzed in embedded systems to determine the root cause. This talk will show examples of what and how to collect forensics data from two popular RTUs that are used in Electric Substations: the General Electric D20MX and the Schweitzer Engineering Labs SEL-3530 RTAC. This talk will not cover Windows or *nixbased devices such as Human Machine Interfaces (HMIs) or gateways.

SGX Secure Enclaves in Practice: Security and Crypto Review
Jean-Philippe Aumasson  &  Luis Merino
Software Guard Extensions (SGX) is a technology available in Intel(R) CPUs released in autumn 2015. SGX allows a remote server to process a client’s secret data within a software enclave that hides the secrets from the operating system, hypervisor, and even BIOS or chipset manager, while giving cryptographic evidence to the client that the code has been executed correctly the very definition of secure remote computation. This talk is the first public assessment of SGX based on real SGX-enabled hardware and on Intel’s software development environment. While researchers already scrutinized Intel’s partial public documentation, many properties can only be verified and documented by working with the real thing: What’s really in the development environment? Which components are implemented in microcode and which are in software? How can developers create secure enclaves that won’t leak secrets? Can the development environment be trusted? How to debug and analyze SGX software? What crypto schemes are used in SGX critical components? How reliable are they? How safe are their implementations? Based on these newly documented aspects, we’ll assess the attack surface and real risk for SGX users. We’ll then present and demo proofs-of-concept of cryptographic functionalities leveraging SGX: secure remote storage and delegation (what fully homomorphic encryption promises, but is too slow to put in practice), and reencryption. We’ll see how basic architectures can deliver powerful crypto functionalities with a wide range of applications. We’ll release code as well as a tool to extract and verify an enclave’s metadata.

Breaking Hardware-Enforced Security with Hypervisors
Joseph Sharkey
Hardware-Enforced Security is touted as the panacea solution to many modern computer security challenges. While certainly adding robust options to the defenders toolset, they are not without their own weaknesses. In this talk we will demonstrate how low-level technologies such as hypervisors can be used to subvert the claims of security made by these mechanisms. Specifically, we will show how a hypervisor rootkit can bypass Intel’s Trusted Execution Environment (TXT) DRTM (dynamic root of trust measurement) and capture keys from Intel’s AES-NI instructions. These attacks against TXT and AES-NI have never been published before. Trusted computing has had a varied history, to include technologies such as Trusted Execution Technology (TXT), ARM TrustZone, and now Microsoft Isolated User Mode and Intel SGX. All of these technologies attempt to protect user data from privileged processes snooping or controlling execution. These technologies claim that no elevated process, whether kernel based, System Management Mode (SMM) based, or hypervisor based will be able to compromise the user’s data and execution. This presentation will highlight the age-old problem of misconfiguration of Intel TXT by exploiting a machine through the use of another Intel technology, the Type-1 hypervisor (VT-x). Problems with these technologies have surfaced not as design issues but during implementation. Whether there remains a hardware weakness where attestation keys can be compromised, or a software and hardware combination, such as exposed DMA that permits exfiltration, and sometimes modification, of user process memory. This presentation will highlight one of these implementation flaws as exhibited by the open source tBoot project and the underlying Intel TXT technology. Summation will offer defenses against all too often pitfalls when deploying these systems, including proper deployment design using sealed storage, remote attestation, and hardware hardening.

Breaking Kernel Address Space Layout Randomization (KASLR) with Intel TSX
Yeongjin Jang  &  Sangho Lee  &  Taesoo Kim
Kernel hardening has been an important topic, as many applications and security mechanisms often consider the kernel their Trusted Computing Base (TCB). Among various hardening techniques, kernel address space layout randomization (KASLR) is the most effective and widely adopted technique that can practically mitigate various memory corruption vulnerabilities, such as buffer overflow and use-after-free. In principle, KASLR is secure as long as no memory disclosure vulnerability exists and high randomness is ensured. In this talk, we present a novel timing side-channel attack against KASLR, called DrK (De-randomizing Kernel address space), which can accurately, silently, and rapidly de-randomize the kernel memory layout by identifying page properties: unmapped, executable, or non-executable pages. DrK is based on a new hardware feature, Intel Transactional Synchronization Extension (TSX), which allows us to execute a transaction without interrupting the underlying operating system even when the transaction is aborted due to errors, such as access violation and page faults. In DrK, we turned this property into a timing channel that can accurately distinguish the mapping status (i.e., mapped versus unmapped) and execution status (i.e., executable versus non-executable) of the privileged address space. In addition to its surprising accuracy and precision, the DrK attack is not only universally applicable to all OSes, even under a virtualized environment, but also has no visible footprint, making it nearly impossible to be detected in practice. We demonstrate that DrK breaks the KASLR of all major OSes, including Windows, Linux, and OS X with near-perfect accuracy in a few seconds. Finally, we propose potential hardware modifications that can prevent or mitigate the DrK attack.

Capturing 0day Exploits with PERFectly Placed Hardware Traps
Cody Pierce  &  Matt Spisak  &  Kenneth Fitch
The security industry has gone to great lengths to make exploitation more difficult. Yet we continue to see weaponized exploits used in malware campaigns and targeted attacks capable of bypassing OS and vendor exploit mitigation strategies. Many of these newly deployed mitigations target code-reuse attacks like return-oriented-programming. Unfortunately, the reality is that once attackers have control over code execution it’s only a matter of time before they can circumvent these defenses, as the recent rise of EMET bypasses illustrates. We propose a new strategy to raise the bar significantly. Our approach blocks exploits before they gain execution, preventing the opportunity to bypass mitigations. This presentation introduces a new cross-platform, hardware-assisted Control-Flow Integrity (CFI) approach to mitigate control-flow hijack attacks on the Intel architecture. Prior research has demonstrated the effectiveness of leveraging processor-provided features such as the Performance Monitoring Unit (PMU) in order to trap various events for detecting ROP behaviors. We extend and generalize this approach by fine-tuning low-level processor features that enable us to insert a CFI policy to detect and prevent abnormal branches in real-time. Our promising results have shown this approach capable of protecting COTS binaries from control-flow hijack attempts stemming from use-after-free and memory corruption vulnerabilities with acceptable overhead on modern Windows and Linux systems. In this talk, we will cover our research methodology, results, and limitations. We will highlight novel solutions to major obstacles we faced, including: proper tracking of Windows thread context swapping; configuration of PMU interrupt delivery without tripping Microsoft’s PatchGuard; efficient algorithms for discovery of valid branch destinations in PE and ELF files at run-time; and the impact of operating in virtualized environments. The effectiveness of our approach using hardware-assisted traps to monitor program execution and enforce CFI policies on mispredicted branches will be demonstrated in real-time. We will prevent weaponized exploits targeting Windows and Linux x86-64 operating systems that nominally bypass anti-exploit technologies like Microsoft’s EMET tool. We will also present collected metrics on performance impact and the real-world applications of this technology.

Dangerous Hare: Hanging Attribute References Hazards Due to Vendor Customization
Nan Zhang
For the purposes of tailoring the Android to different hardware platforms, countries/regions and other needs, hardware manufacturers (e.g. Qualcomm), device manufacturers, carriers and others have aggressively customized Android into thousands of system images. This practice has led to a highly fragmented ecosystem where the complicated relations among its components and apps though which one party interacts with the other have been seriously compromised. This leads to the pervasiveness of Hare (hanging attribute references e.g. package, activity, service action names, authorities and permissions), a type of vulnerabilities never investigated before. In this talk, we will show that such flaws could have serious security implications, that is, a malicious app can acquire critical system capabilities by pretending to be the owner of an attribute who has been used on a device while the party defining it does not exist due to vendor customizations. On the factory image of 97 most popular Android devices, we discovered 21557 likely Hare flaws, demonstrating the significant impacts of the problem from stealing user’s voice notes, controlling the screen unlock process, replacing Google Email’s account settings to injecting messages into Facebook app and Skype. We will also show a set of new techniques we developed for automatically detecting Hare flaws within different Android versions, which can be utilized by the device manufacturers and other parties to secure their custom OSes. And we will provide the guidance for avoiding this pitfall when building future systems.

Demystifying the Secure Enclave Processor
Tarjei Mandt  &  Mathew Solnik
The secure enclave processor (SEP) was introduced by Apple as part of the A7 SOC with the release of the iPhone 5S, most notably to support their fingerprint technology, Touch ID. SEP is designed as a security circuit configured to perform secure services for the rest of the SOC, with with no direct access from the main processor. In fact, the secure enclave processor runs it own fully functional operating system – dubbed SEPOS – with its own kernel, drivers, services, and applications. This isolated hardware design prevents an attacker from easily recovering sensitive data (such as fingerprint information and cryptographic keys) from an otherwise fully compromised device. Despite almost three years have passed since its inception, little is still known about the inner workings of the SEP and its applications. The lack of public scrutiny in this space has consequently led to a number of misconceptions and false claims about the SEP. In this presentation, we aim to shed some light on the secure enclave processor and SEPOS. In particular, we look at the hardware design and boot process of the secure enclave processor, as well as the SEPOS architecture itself. We also detail how the iOS kernel and the SEP exchange data using an elaborate mailbox mechanism, and how this data is handled by SEPOS and relayed to its services and applications. Last, but not least, we evaluate the SEP attack surface and highlight some of the findings of our research, including potential attack vectors.

Does Dropping USB Drives in Parking Lots and Other Places Really Work?
Elie Bursztein
At every Black Hat you will inevitably hear hackers boasting that they can break into any company by dropping a malicious USB drive in the company’s parking lot. This anecdote has even entered mainstream culture and was prominently featured in the Mr. Robot TV series. However despite its popularity, there has been no rigorous study of whether the attack works or is merely an urban legend. To answer this burning question and assess the actual threat posed by malicious USB drives, we dropped nearly 300 USB sticks on the University of Illinois Urbana-Champaign campus and measured who plugged in the drives. And oh boy how effective that was! Of the drives we dropped, 98% were picked up and for 48% of the drives, someone not only plugged in the drive but also clicked on files. Join us for this talk if you are interested in physical security and want to learn more about the effectiveness of arguably the most well known anecdote of our community. We will provide an in-depth analysis of which factors influence users to pick up a drive, why users plug them in, and demo a new tool that can help mitigate USB attacks.

GreatFET: Making GoodFET Great Again
Michael Ossmann
My evil plot began by making small but seemingly helpful contributions to the GoodFET project, a line of code here, a simple add-on board there. Soon I was answering the occasional question on IRC or the mailing list, and I was in: commit rights! I had chosen my prey carefully. GoodFET, the preferred open source tool of discriminating hardware hackers around the world, consisted of too many disparate hardware designs. It was full of terrific ideas and PoCs, but it was becoming unmaintainable. The Facedancer variant alone had at least three different and incompatible code bases! The hardware designs were easy to build one at a time but needlessly costly for volume manufacturing. The project was ripe for a takeover. I struck when Travis Goodspeed was most vulnerable, his faculties diminished by the hordes of Las Vegas. He accepted my $5. GoodFET was mine! With GoodFET in my control I moved quickly to replace the entire project with something superior, something greater! Today I unleash GreatFET!

Intra-Process Memory Protection for Applications on ARM and x86: Leveraging the ELF ABI
Sergey Bratus  &  Maxwell Koo  &  Julian Bangert
Today’s software needs to isolate not only processes but the many components *within* a process from each other. Process-level isolation via jails, sandboxes, VMs, or hypervisors is finally becoming mainstream, but it misses an important point about modern software: its growing number of libraries that are all loaded into the same address space, and may all interact with complex inputs by way of vulnerable parsers. A process, even isolated, is as weak as the weakest of its components, but is as valuable as the most sensitive data it holds. Heartbleed was a perfect example of this: a faulty parser in a library could read absolutely everything in memory; there are many others less famous but no better. The biggest challenge of making intra-process memory protection practical is that it cannot require major changes to how software is written. A practical granular memory protection scheme must work for the existing C/C++ build chains, nor should it change the ABI. Further, it cannot rely on concepts that aren’t already intuitively clear to C/C++ programmers. Many academic proposals for more granular memory access control stopped short of this. They disregard the glue what keeps the development process and runtime together: the ABI. We demonstrate ELFbac, a system that uses the Linux ELF ABI to express access control policies between a program’s components, such as libraries, and requires no changes to the GNU build chain. It enforces these policies by using a modified Linux loader and the Linux virtual memory system. ELFbac policies operate on the level of ELF object file sections. Custom data and code units can be created with existing GCC C/C++ attributes with a one-line annotation per unit; they are no more complex than C’s static scoping. We have developed prototypes for ARM and x86. We used our ARM prototype to protect a validating proxy firewall for DNP3, a popular ICS protocol, and our x86 one to write a basic policy for Nginx. We will also demonstrate a policy for protecting OpenSSH.

Ouroboros: Tearing Xen Hypervisor with the Snake
Shangcong Luan
The Xen Project has been a widely used virtualization platform powering some of the largest clouds in production today. Sitting directly on the hardware below any operating systems, the Xen hypervisor is responsible for the management of CPU/MMU and guest operating systems. Guest operating systems cound be controled to run in PV mode using paravirtualization technologies or HVM mode using hardware-assisted virtualization technologies. Compare to HVM mode, PV mode guest OS kernel could recognize the existence of hypervisor and, thus, work normally via hypervisor inferfaces which are called hypercalls. While performing priviledged operations, PV mode guest OS would submit requests via hypercalls then the hypervisor do these operations for it after verifying its requests. Inspired by Ouroboros, an ancient symbol with a snake bitting its tail, our team has found a critical verification bypass bug in Xen hypervisor and that will be used to tear the hypervisor a hole. With sepecific exploition vectors and payloads, malicious PV guest OS could control not only the hypervisor but also all other guest operating systems running on current platform.

The Tao of Hardware the Te of Implants
Joe FitzPatrick
Embedded, IOT, and ICS devices tend to be things we can pick up, see, and touch. They’re designed for nontechnical users who think of them as immutable hardware devices. Even software security experts, at some point, consider hardware attacks out of scope. Thankfully, even though a handful of hardware manufacturers are making some basic efforts to harden devices, there’s still plenty of cheap and easy ways to subvert hardware. The leaked ANT catalog validated that these cheap hardware attacks are worthwhile. The projects of the NSA Playset have explored what’s possible in terms of cheap and easy DIY hardware implants, so I’ve continued to apply those same techniques to more embedded devices and industrial control systems. I’ll show off a handful of simple hardware implants that can 1) Blindly escalate privilege using JTAG 2) Patch kernels via direct memory access on an embedded device without JTAG 3) Enable wireless control of the inputs and outputs of an off-the-shelf PLC 4) Hot-plug a malicious expansion module onto another PLC without even taking the system offline and 5) Subvert a system via a malicious display adapter. Some of these are new applications of previously published implants – others are brand new.
I’ll conclude with some potential design decisions that could reduce vulnerability to implants, as well as ways of protecting existing hardware systems from tampering.

Using Undocumented CPU Behavior to See into Kernel Mode and Break KASLR in the Process
Anders Fogh  &  Daniel Gruss
Typically, hackers focus on software bugs to find vulnerabilities in the trust model of computers. In this talk, however, we’ll focus on, how the micro architectural design of computers and how they enable an attacker to breach trust boundaries. Specifically, we’ll focus on how an attacker with no special privileges can gain insights into the kernel and how these insights can enable further breaches of security. We will focus on the x86-64 architecture, but round up with comments on how our research touches on ARM processors. Unlike software bugs, micro architectural design issues have applications across operating systems and are independent of easily fixable software bugs. In modern operating systems the security model is enforced by the kernel. The kernel itself runs in a processor supported and protected state often called supervisor or kernel mode. Thus the kernel itself is protected from introspection and attack by hardware. We will present a method that’ll allow for fast and reliable introspection into the memory hierarchy in the kernel based on undocumented CPU behavior and show how attackers could make use of this information to mount attacks on the kernel and consequently of the entire security model of modern computers. Making a map of memory and breaking KASLR Modern operating systems use a number of methods to prevent an attacker from running unauthorized code in kernel mode. They range from requiring user-privileges to load drivers, over driver signing to hardware enabled features preventing execution in memory marked as data such as DEP (Data Execution Prevention) or more resonantly SMEP that prevents execution of user allocated code with kernel level privileges. Often used bypasses modify either page tables or use so called code reuse attacks. Either way an attacker needs to know where the code or page tables are located. To further complicate an attack modern operating system is equipped with “Kernel Address Space Randomized Layout” (KASLR) that randomizes the location of important system memory. We’ll present a fast and reliable method to map where the kernel has mapped pages in the kernel mode area. Further, we’ll present a method for locating specific kernel modules thus by passing KASLR and paving the way for classic privileged elevation attacks. Neither method requires any special privileges and they even run from a sandboxed environment. Also relevant is that our methods are more flexible than traditional software information leaks, since they leak information on the entire memory hierarchy. The core idea of the work is that the prefetch instructions leaks information about the caches that are related to translating a virtual address into a physical address. Also significant is that the prefetch instruction is unprivileged and does not cause exceptions nor does it have any privilege verification. Thus it can be used on any address in the address space. Physical to virtual address conversion A number of micro-architectural attacks is possible on modern computers. The Row hammer is probably the most famous of these attacks. But attacks methodologies such as cache side channel attacks have proven to be able to exfiltrate private data, such as private keys, across trust boundaries. These two attack methodologies have in common that they require information about how virtual memory is mapped to physical memory. Both methodologies have thus far either used the “/proc/PID/pagemap” which is now accessible only with administrator privileges or by using approximations. We will discuss a method where an unprivileged user is able to reconstruct this mapping. This goes a long way towards making the row hammer attack a practical attack vector and can be a valuable assistance in doing cache side channel attacks. Again we use the prefetch’s instructions lack of privilege checking, but instead of using the timing that it leaks we now use the instructions ability to load CPU caches and that timing of memory access instructions depend heavily on the cache state. Bonus material We will shortly discuss the attack vectors relevance on ARM platforms and its potential impact on hypervisor environments. Finally, we will shortly outline a possible defense.

Xenpwn: Breaking Paravirtualized Devices
Felix Wilhelm
Instead of simply emulating old and slow hardware, modern hypervisors use paravirtualized devices to provide guests access to virtual hardware. Bugs in the privileged backend components can allow an attacker to break out of a guest, making them quite an interesting target. In this talk, I’ll present the results of my research on the security of these backend components and discuss Xenpwn, a hypervisor based memory access tracing tool used to discover multiple critical vulnerabilities in paravirtualized drivers of the Xen hypervisor. If you like virtualization security, race conditions, vulnerabilities introduced by compiler optimizations or are a big fan of Bochspwn, this is the right talk for you.