I've worked on many computer security projects since my undergraduate studies. Some of these led to a publication at top-tier (low acceptance rate) computer security venues, such as USENIX Security, IEEE S&P, ACM CCS, and Black Hat USA. Below is a selection of work I'm most proud of and where I played significant role (first, second or co-first author). For an exhaustive list, my CV has it all. For less formal work, my projects and blog are the place to check out.

  1. Emulating Samsung's Shannon Baseband for Security TestingBlack Hat USA 2020 & Hardwear.io 2020
  2. BigMAC: Fine-Grained Policy Analysis of Android FirmwareUSENIX Security 2020
  3. LBM: A Security Framework for Peripherals within the Linux KernelIEEE S&P 2019
  4. ATtention Spanned: Comprehensive Vulnerability Analysis of AT Commands Within the Android EcosystemUSENIX Security 2018
  5. FirmUSB: Vetting USB Device Firmware using Domain Informed Symbolic ExecutionACM CCS 2017
  6. Smart Nest Thermostat: A Smart Spy in your HomeBlack Hat USA 2014

The most crucial interface between modern mobile phones and cellular networks are baseband processors. Basebands are responsible for processing the complicated 2G thru 5G protocols, which gives them a large attack surface. Unfortunately, exploring this surface is cumbersome: finding flaws over-the-air is not scalable, crashes are difficult to reproduce, and devices typically lack even basic debugging interfaces.

To address these concerns, we designed and built an emulation environment for Samsung’s “Shannon” baseband (ShannonEE). We leverage and combine the strengths of two existing frameworks, avatar2 & PANDA, to provide a flexible and extensible platform geared towards vulnerability research. We are able to load and run ARMv7-R Shannon firmware images, which typically exceed 30MB in size and have 65K+ functions. We emulate the custom Shannon RTOS and its peripherals accurately enough to enable task switching and timer interrupts, leading to powerful dynamic analysis platform. We also support different versions of Shannon SoCs, spanning multiple generation of Samsung Galaxy phones.

To take full advantage of ShannonEE, we ported TriforceAFL, allowing for targeted, coverage guided, task or protocol, fuzzing. Unlike over-the-air fuzzing, our platform allows for in-depth introspection of the baseband’s internal state when triggering crashes and gdb-based memory examination providing backtraces and detailed task information. We demonstrate how our emulator can be used to investigate and understand the impact of n-days and how you would go about finding new vulnerabilities.

Author’s Note: I recommend watching both the Black Hat and Hardwear.io talks. Their intro is similar, but one focuses on vulnerability research and the other reverse engineering. Personally, I like the flow of the Hardwear.io talk better, especially since my co-author was present. Plus there are a lot of good questions at the end, which is completely missed in the Black Hat version due to it being pre-recorded (booo).

BibTeX

@article{hernandez_basebands_2020,
  title={{Emulating Samsung's Shannon Baseband for Security Testing}},
  author={Hernandez, Grant and Muench, Marius and Tucker, Tyler and Searle, Hunter and Zhu, Weidong and Traynor, Patrick and Butler, Kevin},
  journal={Black Hat USA},
  year={2020}
}
A block diagram of the major components of ShannonEE.

Figure: A block diagram of the major components of ShannonEE.

A block diagram of the Shannon baseband in relation to its peripherals and the application processor.

Figure: A block diagram of the Shannon baseband in relation to its peripherals and the application processor.

To defend against malicious applications and external attack, Android relies upon a complex combination of discretionary and mandatory access control mechanisms, including Linux capabilities, to maintain least privilege. To understand the impact and interaction between these layers, we created a framework called BigMAC that combines and instantiates all layers of the policy together in a fine grained graph supporting millions of edges. Our model filters out paths and types not in use on actual systems that policy analysis alone would consider. Unlike previous work which requires a rooted device, using only static firmware and Android domain knowledge, we are able to extract and recreate the security state of a running system, achieving a process credential recovery at best 74.7% and a filesystem DAC and MAC accuracy of over 98%. Using BigMAC, we develop attack queries to discover sets of objects that can be influenced by untrusted applications and external peripherals. Our evaluation against Samsung S8+ and LG G7 firmwares reveals multiple policy concerns, including untrusted apps on LG being able to communicate with a kernel monitoring service, Samsung S8+ allowing IPC from untrusted apps to some root processes, at least 24 processes with the CAP_SYS_ADMIN capability, and system_server with the capability to load kernel modules. We have reported our findings to the corresponding vendors and release BigMAC for the community.

BibTeX

@inproceedings{hernandez_bigmac_2020,
        title = {{BigMAC}: {Fine}-{Grained} {Policy} {Analysis} of {Android} {Firmware}},
        author = {Hernandez, Grant and Tian, Dave (Jing) and Yadav, Anurag Swarnim and Williams, Byron J. and Butler, Kevin R.B.},
        booktitle = {29th {USENIX} {Security} {Symposium} ({USENIX} {Security} 20)},
        shorttitle = {{BigMAC}},
        year = {2020}
}
The most notable security mechanisms used by Android to enforce its security policy. BigMAC examines SELinux, DAC, and capabilities the most.

Figure: The most notable security mechanisms used by Android to enforce its security policy. BigMAC examines SELinux, DAC, and capabilities the most.

The relationship between key Android processes and their DAC and MAC security policy definitions.

Figure: The relationship between key Android processes and their DAC and MAC security policy definitions.

The key graph derivations used by BigMAC to create an attack graph from Android firmware.

Figure: The key graph derivations used by BigMAC to create an attack graph from Android firmware.

Modern computer peripherals are diverse in their capabilities and functionality, ranging from keyboards and printers to smartphones and external GPUs. In recent years, peripherals increasingly connect over a small number of standardized communication protocols, including USB, Bluetooth, and NFC. The host operating system is responsible for managing these devices; however, malicious peripherals can request additional functionality from the OS resulting in system compromise, or can craft data packets to exploit vulnerabilities within OS software stacks. Defenses against malicious peripherals to date only partially cover the peripheral attack surface and are limited to specific protocols (e.g., USB). In this paper, we propose Linux (e)BPF Modules (LBM), a general security framework that provides a unified API for enforcing protection against malicious peripherals within the Linux kernel. LBM leverages the eBPF packet filtering mechanism for performance and extensibility and we provide a high-level language to facilitate the development of powerful filtering functionality. We demonstrate how LBM can provide host protection against malicious USB, Bluetooth, and NFC devices; we also instantiate and unify existing defenses under the LBM framework. Our evaluation shows that the overhead introduced by LBM is within 1μs per packet in most cases, application and system overhead is negligible, and LBM outperforms other state-of-the-art solutions. To our knowledge, LBM is the first security framework designed to provide comprehensive protection against malicious peripherals within the Linux kernel.

BibTeX

@inproceedings{tian_lbm_2019,
        title = {{LBM}: {A} {Security} {Framework} for {Peripherals} within the {Linux} {Kernel}},
        author = {Tian, Dave Jing and Hernandez, Grant and Choi, Joseph I. and Frost, Vanessa and Johnson, Peter C. and Butler, Kevin R. B.},
        booktitle = {2019 {IEEE} {Symposium} on {Security} and {Privacy} ({SP})},
        shorttitle = {{LBM}},
        year = {2019}
}
The flow of filter expressions through lbmtool, which compiles them to eBPF for loading into the kernel.

Figure: The flow of filter expressions through lbmtool, which compiles them to eBPF for loading into the kernel.

LBM's Bluetooth hooks installed at various layers of the protocol to offer different levels of packet filtering.

Figure: LBM's Bluetooth hooks installed at various layers of the protocol to offer different levels of packet filtering.

LBM's hooks into Linux's USB subsystem. This allows all USB packets in and out of the kernel to be filtered.

Figure: LBM's hooks into Linux's USB subsystem. This allows all USB packets in and out of the kernel to be filtered.

AT commands, originally designed in the early 80s for controlling modems, are still in use in most modern smartphones to support telephony functions. The role of AT commands in these devices has vastly expanded through vendor-specific customizations, yet the extent of their functionality is unclear and poorly documented. In this paper, we systematically retrieve and extract 3,500 AT commands from over 2,000 Android smartphone firmware images across 11 vendors. We methodically test our corpus of AT commands against eight Android devices from four different vendors through their USB interface and characterize the powerful functionality exposed, including the ability to rewrite device firmware, bypass Android security mechanisms, exfiltrate sensitive device information, perform screen unlocks, and inject touch events solely through the use of AT commands. We demonstrate that the AT command interface contains an alarming amount of unconstrained functionality and represents a broad attack surface on Android devices.

BibTeX

@inproceedings{tian_attention_18,
  title = {{ATtention Spanned: Comprehensive Vulnerability Analysis of AT Commands Within the Android Ecosystem}},
  author = {Dave Tian and Grant Hernandez and Joseph Choi and Vanessa Frost and Christie Ruales and Kevin Butler and Patrick Traynor and Hayawardh Vijayakumar and Lee Harrison and Amir Rahmati and Mike Grace},
  booktitle = {27th {USENIX} Security Symposium ({USENIX} Security 18)},
  year = {2018},
  publisher = {{USENIX} Association}
}
A diagram showing all of the major components that can influence whether AT command interfaces are exposed on Android devices and where those commands would flow through.

Figure: A diagram showing all of the major components that can influence whether AT command interfaces are exposed on Android devices and where those commands would flow through.

An diagram that didn't make it into the paper of some reverse engineering of Samsung's native daemons that handled AT commands. We reversed these daemons to investigate the effects of more complex AT commands during testing.

Figure: An diagram that didn't make it into the paper of some reverse engineering of Samsung's native daemons that handled AT commands. We reversed these daemons to investigate the effects of more complex AT commands during testing.

An diagram showing the parts of different types of AT commands.

Figure: An diagram showing the parts of different types of AT commands.

The logo for the website (not the bugs).

Figure: The logo for the website (not the bugs).

The USB protocol has become ubiquitous, supporting devices from high-powered computing devices to small embedded devices and control systems. USB’s greatest feature, its openness and expandability, is also its weakness, and attacks such as BadUSB exploit the unconstrained functionality a orded to these devices as a vector for compromise. Fundamentally, it is virtually impossible to know whether a USB device is benign or malicious. This work introduces FirmUSB, a USB-specific firmware analysis framework that uses domain knowledge of the USB protocol to examine firrmware images and determine the activity that they can produce. Embedded USB devices use microcontrollers that have not been well studied by the binary analysis community, and our work demonstrates how lifters into popular intermediate representations for analysis can be built, as well as the challenges of doing so. We develop targeting algorithms and use domain knowledge to speed up these processes by a factor of 7 compared to unconstrained fully symbolic execution. We also successfully find malicious activity in embedded 8051 firmwares without the use of source code. Finally, we provide insights into the challenges of symbolic analysis on embedded architectures and provide guidance on improving tools to better handle this important class of devices.

BibTeX

@inproceedings{hernandez_firmusb_2017,
   title = {{FirmUSB}: {Vetting} {USB} {Device} {Firmware} using {Domain} {Informed} {Symbolic} {Execution}},
   author = {Hernandez, Grant and Fowze, Farhaan and Tian, Dave (Jing) and Yavuz, Tuba and Butler, Kevin R.B.},
   shorttitle = {{FirmUSB}},
   booktitle = {Proceedings of the 2017 {ACM} {SIGSAC} {Conference} on {Computer} and {Communications} {Security}},
   publisher = {Association for Computing Machinery},
   year = {2017}
}
The relationship between source code, binary firmware, and Intermediate Representation (IR).

Figure: The relationship between source code, binary firmware, and Intermediate Representation (IR).

The Nest thermostat is a smart home automation device that aims to learn about your heating and cooling habits to help optimize your scheduling and power usage. Debuted in 2010, the smart Nest devices have been proved a huge success that Google spent $3.2B to acquire the whole company. However, the smartness of the thermostat also breeds security vulnerabilities, similar to all other smart consumer electronics. The severity of security breach has not been fully embraced due to the traditional assumption that thermostat cannot function more than a thermostat even though users are enjoying its smartness.

Equipped with two ARM cores, in addition to WiFi and ZigBee chips, this is no ordinary thermostat. In this presentation, we will demonstrate our ability to fully control a Nest with a USB connection within seconds (in our demonstration, we will show that we can plug in a USB for 15 seconds and walk away with a fully rooted Nest). Although OS level security checks are available and are claimed to be very effective in defeating various attacks, instead of attacking the higher level software, we went straight for the hardware and applied OS-guided hardware attacks. As a result, our method bypasses the existing firmware signing and allows us to backdoor the Nest software in any way we choose. With Internet access, the Nest could now become a beachhead for an external attacker. The Nest thermostat is aware of when you are home and when you are on vacation, meaning a compromise of the Nest would allow remote attackers to learn the schedule of users. Furthermore, saved data, including WiFi credentials, would now become available to attackers. Besides its original role of monitor the user’s behavior, the smart Nest is now a spy rooted inside a house fully controlled by attackers.

Using the USB exploit mentioned above, we have loaded a custom compiled kernel with debug symbols added. This enables us to explore the software protocols used by the nest, such as Nest Weave, in order to find potential vulnerabilities that can be remotely exploited. Loading a custom kernel into the system also shows how we have obtained total control of the device, introducing the potential for rootkits, spyware, rogue services and other network scanning methods, further allowing the compromise of other nodes within the local network.

BibTeX

@article{hernandez_nest_2014,
  title={{Smart Nest Thermostat: A Smart Spy in Your Home}},
  author={Hernandez, Grant and Arias, Orlando and Buentello, Daniel and Jin, Yier},
  journal={Black Hat USA},
  year={2014}
}