Hardware Hacking for Fun and Feeds - CVE-2018-5560

Work documented here was done as part of a larger event in Dallas, 0DayAllDay and what is here is representative of the work I contributed to the exploit ultimately found. The environment and teamwork provided at a 0-Day hunting event is incredible and I'd highly recommend any security enthusiasts check out or organize one. It's a wonderful experience and the only reason we found the CVE.

Initial Enumeration

Work began with setting up and using the Guardzilla Model #:GZ521W as it was intended. This was done through a wireless access point we controlled, which allowed us to inspect the traffic as it was leaving the camera. While we found interesting API endpoints and various connections to AWS and other locations, we ultimately moved on to other avenues for attack.

Firmware Analysis

We then opened up the camera to see what was available on board.

Board Front
Guardzilla Back

With a brief search of the components, we found the Winbond 25q128fvsg chip was a SPI ROM chip, meaning we should be able to quickly and easily dump the firmware. We used a Pomona 5250 and a Bus Pirate along with the flashrom utility to do so. The chip clip is a hooked up according the board schematic found here and then dumped:

flashrom -p buspirate_spi:dev=/dev/ttyUSB0 -r guardzilla.rom

The ROM dump was then analyzed with binwalk to verify see what the ROM contained and extract any contents found:

kulinacs[guardzilla]% binwalk guardzilla.rom
241752        0x3B058         CRC32 polynomial table, little endian
393216        0x60000         uImage header, header size: 64 bytes, header CRC: 0xD7E81691, created: 2016-03-29 02:41:53, image size: 1819824 bytes, Data Address: 0x2000000,
Entry Point: 0x2000040, data CRC: 0xC49D6E19, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: "gm8136"
410289        0x642B1         gzip compressed data, maximum compression, from Unix, NULL date (1970-01-01 00:00:00)
3538944       0x360000        Squashfs filesystem, little endian, version 4.0, compression:xz, size: 3890486 bytes, 148 inodes, blocksize: 131072 bytes, created: 2016-05-05 0
7733248       0x760000        JFFS2 filesystem, little endian

After exploring the file system, we found the following information about the system:

Distribution Base: Grain Media ARM Linux 3.3

Shadow Password (DES): root:MvynOwD449PkM:0:0:99999:7::: -> GMANCIPC

init starts boot.sh, which starts /mnt/mtd/startapp and /home/daemon.exe, startapp starts vg_boot.sh (which configures low level video settings) and main.exe

We then passed the binaries off to Charles Dardaman for reversing, who discovered the hardcoded AWS S3 credentials.

Work left undone

We ultimately stopped work after finding the AWS keys as the event was over and we no longer had physical access to the camera, the following work was left unfinished

Telnet Login Access

During our network enumeration, we found a telnet like service running on port 23 with an ipc login prompt. It would be great to, in the future, verify if we are give shell access with the found root credentials

UART Access

The UART pads were missing resistors and after adding them we briefly had data flowing, but never got full terminal access.

Mystery 16 Pin Port

We ran a JTAGulator against the 16 Pin port found on the back, but did not find anything of use.

Reversing the Camera's interactions with the Cloud

During out network captures, we found an interesting HTTP API that we were unable to identify exactly what it does:**snipped****snipped**&event_type=1&event_time=1538239032

Disclosure Timeline

● Sat, Sep 29, 2018: Issue discovered at 0DayAllDay Research Event
● Wed, Oct 3, 2018: Issue disclosed to Rapid7 for coordinated disclosure
● Wed, Oct 24, 2018: Issue disclosed to vendor
● Thu, Nov 8, 2018: Issue disclosed to CERT/CC as VRF#18-11-NPPXC
● Fri, Dec 14, 2018: CVE-2018-5560 reserved
● Thu, Dec 27, 2018: Public disclosure


  • Charles Dardaman
  • Andrew Mirghassemi
  • INIT_6
  • Chris