Full Report
Google Nest Hub is an always on smart home display. It runs a device based upon the Amlogic S905D3G SoC. The device has a hidden USB port, making it prime-time for attackers. By holding a combination of buttons (Volume UP + Volume DOWN) at boot (he tried randomly until something worked) to put the device into a Download mode. They tried using a known vulnerability on the same chipset, but this device had already been patched. The author tears open the device to examine things more closely. The board has both USB and power connectors on a separate module, which is connected via a Flexible Flat Cable (FFC). Since there's 5 pins for USB and 2 for power that leaves 8 other pins for other functionality. By probing with a multimeter and a logic analyzer while the device is running, we figure things out. The interesting portion is a pin near 0V and one fluctuating between 0V and 3.3V volts. This matches a UART port. They solder the right connector to a breakout board and decide to poke at the UART interface. While studying the boot log, the text "upgrade key not pressed" appears. Could be a new attack surface! If we try the button combo logged, the text Unable to read file recovery.img appears. From doing research, they figure out this is in the UBoot bootloader code for recovery firmware upload. The author decides to map out the attack surface for the parsing of this file, even though it's signed. They take a look at the FAT32 file system parser, since this had no publicly documented research. UBoot implements a sandbox architecture, which allows is to run as a Linux user space program. Let's fuzz it! To start, they build a fuzzing harness into the block device reader and initialize the state to an expected point, such as USB enumeration and some partitions parsed. Once there, they setup AFL and lifuzzer to fuzz all of the different inputs that can be used. They find a crash on the block size, caused by a buffer overflow in the dev_desc->blksz being larger than 512. Sounds great, right? In practice, USB flash drives never have a block size above this. So, the author decides to build one! TinyUSB provides an example of turning a Raspberry Pi Pico into a Mass Storage device. Using this code, we can induce a crash on the real device! This overflow allows for an overwrite of EIP. Since there are no stack canaries or Nx at this level, we can jump to a location on the stack to execute code. Without easy debug access, the author creates a pattern that tells them what the actual offset is - 0x238. The author writes a payload that dumps the RAM of memory over UART. This requires dump the gd structure, since it contains a pointer to the bootloader in RAM. Once there, we can dump all of the memory. With access to the bootloader, we can call bootloader defined functions to perform arbitrary actions, bypassing secure boot entirely. The vulnerability and exploitation is pretty rad for jailbreaking the device. The author notes that the vulnerability they discovered fuzzing had already been fixed upstream twice. Amazing writeup and implementation of a mass storage device to pwn this.
Analysis Summary