firmadyne: emulation and dynamic analysis of Linux-based firmware

by do son · December 22, 2019

FIRMADYNE is an automated and scalable system for performing emulation and dynamic analysis of Linux-based embedded firmware. It includes the following components:

modified kernels (MIPS: v2.6.32, ARM: v4.1, v3.10) for instrumentation of firmware execution;
a userspace NVRAM library to emulate a hardware NVRAM peripheral;
an extractor to extract a filesystem and kernel from downloaded firmware;
a small console application to spawn an additional shell for debugging;
and a scraper to download firmware from 42+ different vendors.

We have also written the following three basic automated analyses using the FIRMADYNE system.

Accessible Webpages: This script iterates through each file within the filesystem of a firmware image that appears to be served by a web server, and aggregates the results based on whether they appear to required authentication.
SNMP Information: This script dumps the contents of the public and private SNMP v2c communities to disk using no credentials.
Vulnerability Check: This script tests for the presence of 60 known vulnerabilities using exploits from Metasploit. In addition, it also checks for 14 previously-unknown vulnerabilities that we discovered. For more information, including affected products and CVE’s, refer to analyses/README.md.

In our 2016 Network and Distributed System Security Symposium (NDSS) paper, titled Towards Automated Dynamic Analysis for Linux-based Embedded Firmware, we evaluated the FIRMADYNE system over a dataset of 23,035 firmware images, of which we were able to extract 9,486. Using 60 exploits from the Metasploit Framework, and 14 previously-unknown vulnerabilities that we discovered, we showed that 846 out of 1,971 (43%) firmware images were vulnerable to at least one exploit, which we estimate to affect 89+ different products.

FIRMADYNE consists of four major components.

1) Crawling Firmware: The first and largely independent component is a web crawler, which downloads firmware images
from vendor websites. At present, we support 42 device vendors. We manually wrote parsing templates for each of these websites, allowing us to distinguish between firmware images and other binary content. This targeted crawling effort provided us with metadata for each gathered firmware image, including information such as the build date, release version, and links to Management Information Base (MIB) files for the Simple Network Management Protocol (SNMP). Such
metadata proved useful for our automated analyses and exploit development. For dynamic websites that were
difficult to crawl automatically, we instead crawled the vendor’s FTP site, at the expense of no metadata.

2) Extract Firmware Filesystem: In the second step, FIRMADYNE uses a custom-written extraction utility built around
the binwalk API to extract the kernel (optional) and the root filesystem contained within a firmware image.

3) Initial Emulation: Once a filesystem is extracted, FIRMADYNE identifies the hardware architecture of the firmware
image; we have chosen MIPS Little-Endian as an example. Then, our system uses a pre-built Linux kernel in an instance of the QEMU full system emulator that matches the architecture, endianness, and word-width of the target firmware image. Currently, three combinations are supported: little-endian ARM, little-endian MIPS, and big-endian MIPS. An initial emulation is performed to infer the system and network configuration, shown as three IP address assignments to eth0, eth1, and eth2. This is achieved by intercepting system calls to the filesystem, networking, and other relevant kernel subsystems.

4) Dynamic Analysis: The fourth and final step can be repeated for any dynamic analysis supported by FIRMADYNE.
To this end, the environment is dynamically reconfigured to match the expectations of the firmware image (see §IV-C)
as inferred in the previous step. Note that FIRMADYNE is designed for easy extensibility to include new dynamic
analyses or exploits. The results of each individual analysis are aggregated in a database for ease of inspection. In the example above, a command injection vulnerability is being tested on the target firmware image