Professional IoT Hacking Series: Target Selection & Firmware Analysis

When considering where to spend limited penetration testing resources, most organizations (and penetration testing shops) focus on the typical mix of servers and workstations normally found in every organization. While this is a necessary area of focus, other things like that IoT device sitting on the edge of a network can be quite the playground for hackers that are willing to do a little reverse engineering. In this blog series on “Professional IoT Hacking,” VDA Labs will demonstrate some of the ways we attack IoT devices and hopefully communicate just how damaging these devices can be to an organization’s security posture.

Time warp to the 1990’s

Most modern, traditional operating systems (that are used on things like servers and workstations) have the security advantages of years of use across many different organizations and vetting by talented security researches. Centralized methods for releasing security updates and layers of additional protections have been added over the years. For example, at one point Windows did not have Executable space protection (DEP), Address space layout randomization (ALSR), or even stack canaries. These memory corruption protections were all developed to make it harder for attackers to abuse control flow hijacking.

With the rise of IoT, it would have been wonderful if all the lessons learned from traditional operating system security were implemented as a new security baseline, but that is often not the case. Due to the embedded nature of many IoT operating systems, traditional operating system security hardening is thrown out window — which means its like being time warped back to the 1990’s for attackers trying to find exploits. Perhaps in the rush to beat competitors to market first, many modern IoT device operating systems and applications seem to be missing even the basics of input sanitization, resulting in a playground for exploit developers. Is your organization really considering the risk that IoT devices bring to your networks? Hopefully, the following articles in this blog series will help bring awareness to just how vulnerable modern IoT devices are.

Selecting our research target

To demonstrate how we go about finding vulnerabilities in modern IoT devices (network cameras, connected cars, building controllers, ICS, routers, etc), VDA Labs decided to spend a few hours of focused research time on a particular IoT camera. This device first came on our radar during an actual penetration test. While looking for ways to pivot into a restricted internal network subnet, for some reason access to this IoT camera running inside the restricted subnet was allowed. By dynamically fuzzing the web interface for this particular IoT camera, a zero day command execution vulnerability was discovered, which allowed a foothold to be established inside the restricted subnet.

The device chosen is a fully patched and update version of VIVOTEK’s FD8136. The only reason VDA decided to pick this device for research is because we stumbled across it during a penetration test, but one thing to note is that this device dose not have any disclosed Common Vulnerabilities and Exposures (CVE). Many people might think this is a good sign, and would perhaps prefer that the device or software they use have a clean CVE track record, but in our experience a lack of CVE history is typically because the device or software has not been properly vetted for vulnerabilities. We prefer to use devices and software that have a good track record of mitigating disclosed vulnerabilities.

Decompressing target firmware

Throughout this blog series on Professional IoT Hacking, we plan to demonstrate several different types of static and dynamic analysis that can be used to assess any IoT device. To that end, we purchased a fully functional version of the target device for dynamic analysis and fuzzing, but an obvious place to get started was reverse engineering target device firmware. As with lots of IoT devices, the latest version of the firmware (version 0301a) was available online for public download. In cases where the firmware for a target device is not easily available, it is often possible to obtain a Man-in-the-middle position on the target device in your research lab, then capture new device firmware off the wire when it downloads. Common methods for doing this include sniffing wireless interface traffic with Wireshark, using an ethernet tap device like the Throwing Star LAN Tap or Packet Squirrel, or simply using ARP poisoning on a local subnet to sniff traffic between the target device and its internet gateway.

After downloading the firmware, we opened the ZIP file with a linux virtual machine, and quickly noticed the file “FD8136-VVTK-0301a.flash.pkg” as probably containing the firmware we want to decompress.

Running the “file” command simply returned “data” so we turned to Binwalk, our favorite firmware decompression tool. In the screen capture below, the command “binwalk -e -M ./FD8136-VVTK-0301a.flash.pkg” was used to recursively decompress our target FD8136 Network Camera firmware. We have found that Binwalk typically works best on a Linux distro, like Ubuntu or Debian — sometimes it does not work as well when trying to use it on Mac OSX.

During the decompression process, Binwalk recursively identified LZMA compressed data, a squashfs file system, and eventually decompressed ARM 32-bit ELF files. This information will come in handy later when doing things like reverse engineering and fuzzing the ARM binaries for memory corruption vulnerabilities or searching cgi scripts for command injection.

At this point, we have successfully decompressed the firmware and have full access to the underlying filesystem that would be running on the actual device. This contains loads of helpful information about the device, like the path “../squashfs-root/etc/” contains config files, but one particular path of interest is “../squashfs-root/usr/share/www/cgi-bin/,” because it contains the scripts and binaries that are used to manage the device from its web interface. Later in this blog series, we will find that several of these are exposed to non-authenticated users via the Boa web server interface running on TCP port 80.

Next steps

At this point in the process, we have picked a research target and successfully downloaded and decompressed firmware that will actually be running on the device. Quick analysis of the decompressed firmware uncovered attack surface that will be of interest (Boa web server) when later attempting to remotely exploit the device. Future posts in this “Professional IoT Hacking” series will cover fun topics like using IDA Pro to statically identify memory corruption vulnerabilities in ARM binaries, using BurpSuite Pro to dynamically fuzz the web management interface for command injection and memory corruption, emulating ARM binaries for fuzzing with QEMU, using GDB to help with exploitation of memory corruption vulnerabilities, possibly dumping device firmware with JTAGulator, and more. As a side note to this blog series, VDA Labs will be using a Coordinated Vulnerability Disclosure process for the zero day vulnerabilities identified during this research.  (Follow CVE-2018-14494, CVE-2018-14495, and CVE-2018-14496.)