Firmware Security Testing Methodology

@mmar

Hassan 1
 Introduction

 Whether network-connected or standalone, firmware is the center of controlling

any embedded device. As such, it is crucial to understand how firmware can be
manipulated to perform unauthorized functions and potentially cripple the
supporting ecosystem’s security

Hassan
 Introduction

 Usually, the most common goals of firmware analysis will be

to locate the following:
 Passwords

 API tokens

 API endpoints (URLs)

 Vulnerable services

 Backdoor accounts

 Configuration files

 Source code

 Private keys

 How data is stored

Hassan
Introduction

FSTM is composed of nine stages tailored to

enable security researchers, software
developers, hobbyists, and Information
Security professionals with conducting
firmware security assessments

Hassan
 Introduction
Stage Description
Acquire all relative technical and documentation
1. Information gathering and reconnaissance
details pertaining to the target device's firmware
Attain firmware using one or more of the
2. Obtaining firmware
proposed methods discussed in next few slided
3. Analyzing firmware Examine the target firmware's characteristics
Carve filesystem contents from the target
4. Extracting the filesystem
firmware
Statically analyze extracted filesystem
5. Analyzing filesystem contents
configuration files and binaries for vulnerabilities
6. Emulating firmware Emulate firmware files and components
Perform dynamic security testing against firmware
7. Dynamic analysis
and application interfaces
8. Runtime analysis Analyze compiled binaries during device runtime
Exploit identified vulnerabilities discovered in
9. Binary Exploitation previous stages to attain root and/or code
execution
Hassan
 [Stage 1] Information Gathering and Reconnaissance

 During this stage, collect as much information about the target as possible to understand
its overall composition underlying technology

 Supported CPU architecture(s)  Open-source licenses (e.g. GPL)

 Operating system platform  Changelogs
 Bootloader configurations  FCC IDs
 Hardware schematics  Design and data flow diagrams
 Datasheets  Threat models
 Lines-of-code (LoC) estimates  Previous penetration testing reports
 Source code repository location  Bug tracking tickets (e.g. bug bounty platforms
 Third-party components such as BugCrowd or HackerOne)

Hassan
 [Stage 2] Obtaining firmware

 To begin reviewing firmware contents, the firmware image file must be acquired
 Directly from the development team, manufacturer/vendor or client
 Build from scratch using walkthroughs provided by the manufacturer
 From the vendor's support site
 Google dork queries targeted towards binary file extensions and file sharing
platforms such as Dropbox, Box, and Google drive
• It’s common to come across firmware images through customers who upload
contents to forums, blogs, or comment on sites where they contacted the
manufacturer to troubleshoot an issue and were given firmware via a zip or flash
drive sent.
 Man-in-the-middle (MITM) device communication during updates
Hassan
 [Stage 2] Obtaining firmware

 Download builds from exposed cloud provider storage locations such as Amazon Web
Services (AWS) S3 buckets
 Extract directly from hardware via UART, JTAG , etc.
 Sniff serial communication within hardware components for update server requests
 Dumping firmware from the bootloader (e.g. U-boot) to flash storage or over the
network via tftp
 Removing the flash chip or MCU (microcontroller unit) from the board for offline
analysis and data extraction (LAST RESORT)

Hassan
 [Stage 2] Obtaining firmware

 Google Dorks

intitle:"Netgear" intext:"Firmware Download

Hassan
 [Stage 2] Obtaining firmware

 Dumping Firmware from Hardware

Hassan
 [Stage 3] Analyzing firmware

 Once the firmware image is obtained, explore aspects of the file to identify its
characteristics. Use the following steps to analyze firmware file types, potential root
filesystem metadata, and gain additional understanding of the platform it's compiled for

file <bin>
strings
strings -n5 <bin>
strings -n16 <bin>#longer than 16
strings -tx <bin> #print offsets in hex
binwalk <bin>
hexdump -C -n 512 <bin> > hexdump.out
hexdump -C <bin> | head # might find signatures in header
fdisk -lu <bin> #lists a drives partition and filesystems if multiple

Hassan
 [Stage 3] Analyzing firmware

 If the binary may be encrypted, check the entropy using binwalk with the following
command:
$ binwalk -E <bin>

 Low entropy = Not likely to be encrypted

 High entropy = Its likely encrypted (or compressed in some way)
 Alternate tools are also available using Binvis online and the standalone application

• https://code.google.com/archive/p/binvis/
• https://binvis.io/#/

Hassan
 [Stage 4] Extracting the filesystem

 This stage involves looking inside firmware and parsing relative filesystem data to start
identifying as many potential security issues as possible.
Automated Way
$ binwalk -e <bin>
 Filesystem types: squashfs, ubifs, romfs, rootfs, jffs2, yaffs2, cramfs, initramfs are
supported
 Sometimes, binwalk will not have the magic byte of the filesystem in its signatures
and we will be required to approach manually to extract the firmware

Hassan
 [Stage 4] Extracting the filesystem

Manual Way

1. Use binwalk to find the offset of the filesystem

$ binwalk <bin>

$ binwalk DIR850L_REVB.bin

DECIMAL HEXADECIMAL DESCRIPTION

----------------------------------------------------------------------------- ---

0 0x0 DLOB firmware header, boot partition: """"dev=/dev/mtdblock/1""""

10380 0x288C LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 5213748 bytes
1704052 0x1A0074 PackImg section delimiter tag, little endian size: 32256 bytes; big endian size: 8257536 bytes
1704084 0x1A0094 Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 8256900 bytes, 2688 inodes, blocksize: 131072 bytes, created: 2016-
07-12 02:28:41

Hassan
 [Stage 4] Extracting the filesystem

Manual Way

2. Carve the compressed filesystem from the binary

dd if=DIR850L_REVB.bin bs=1 skip=1704084 of=dir.squashfs

 if=DIR850L_REVB.bin: This specifies the input file, in this case, "DIR850L_REVB.bin"

 bs=1: This sets the block size to 1 byte. It means that dd will read and write one byte at a time
 skip=1704084: This option tells dd to skip the first 1,704,084 bytes of the input file before starting to copy
 of=dir.squashfs: This specifies the output file, in this case, "dir.squashfs"

$ dd if=DIR850L_REVB.bin bs=1 skip=1704084 of=dir.squashfs

8257536+0 records in
8257536+0 records out
8257536 bytes (8.3 MB, 7.9 MiB) copied, 12.5777 s, 657 kB/s

Hassan
 [Stage 4] Extracting the filesystem

Manual Way

3. Now extract the filesystem according to the type

squashfs
$ unsquashfs dir.squashfs

CPIO archive files

cpio -ivd --no-absolute-filenames -F <bin>

For jffs2
filesystems
jefferson rootfsfile.jffs2

Hassan
 [Stage 5] Analyzing filesystem contents

 During this stage, clues are gathered for dynamic and runtime analysis stages. Investigate
if the target firmware contains the following (non-exhaustive):
 Legacy insecure network daemons such as telnetd (sometimes manufactures rename
binaries to disguise)
 Hardcoded credentials (usernames, passwords, API keys, SSH keys, and backdoor
variants )
 Hardcoded API endpoints and backend server details
 Review uncompiled code and start up scripts for remote code execution
 Extract compiled binaries to be used for offline analysis with a disassembler for
future steps
Hassan
 [Stage 5] Analyzing filesystem contents

 Statistically analyze filesystem contents and uncompiled code manually or leveraging

automation tools such as firmwalker that parse the following:
 etc/shadow and etc/passwd  search for common web servers used on IoT
 list out the etc/ssl directory devices

 search for SSL related files such as .pem, .crt,  search for common binaries such as ssh, tftp,
etc dropbear, etc

 search for configuration files  search for banned c functions

 look for script files  search for common command injection

vulnerable functions
 search for other .bin files
 search for URLs, email addresses and IP
 look for keywords such as admin, password,
addresses
remote, AWS keys, etc
Hassan
 [Stage 5] Analyzing filesystem contents

 Let’s search for files with the cfg extension using the find command
$ find . -name *cfg
./userfs/profile.cfg
./userfs/romfile.cfg
./boaroot/html/NETGEAR_D6000.cfg
./boaroot/html/romfile.cfg
./boaroot/html/NETGEAR_D6010.cfg
./boaroot/html/NETGEAR_D3610.cfg
/boaroot/html/NETGEAR_D3600.cfg

 You can then look through the configuration files for relevant information. In romfile.cfg,
for example, we find a number of hardcoded user account credentials:

Hassan
 [Stage 5] Analyzing filesystem contents

 Automating Firmware Analysis Firmwalker

 The Firmwalker tool can automate the information gathering and analysis process. Install
it from https://github.com/craigz28/firmwalker/, and then run it

Hassan
 [Stage 6] Emulating Firmware

 Using details and clues identified in previous steps, firmware as well as it’s encapsulated
binaries must be emulated to verify potential vulnerabilities. To accomplish emulating
firmware, there are a few approaches listed below
 Partial emulation (user space) - Emulation of standalone binaries derived from a firmware's extracted
filesystem such as /usr/bin/shellback
 Full system emulation - Emulation of the full firmware and start up configurations leveraging fake
NVRAM. We will be using FAT (Firmware analysis toolkit)
 Emulation using a real device or virtual machine - At times, partial or full emulation may not work
due to a hardware or architecture dependencies. If the architecture and endianness match a device
owned such as a raspberry pie, the root filesystem or specific binary can be transferred to the device
for further testing. This method also applies to pre built virtual machines using the same architecture
and endianness as the target

Hassan
 [Stage 6] Emulating Firmware

 Using details and clues identified in previous steps, firmware as well as it’s encapsulated
binaries must be emulated to verify potential vulnerabilities. To accomplish emulating
firmware, there are a few approaches listed below
 Partial emulation (user space) - Emulation of standalone binaries derived from a firmware's extracted
filesystem such as /usr/bin/shellback
 Full system emulation - Emulation of the full firmware and start up configurations leveraging fake
NVRAM. We will be using FAT (Firmware analysis toolkit). We also have Firmadyne in our toolset
 Emulation using a real device or virtual machine - At times, partial or full emulation may not work
due to a hardware or architecture dependencies. If the architecture and endianness match a device
owned such as a raspberry pie, the root filesystem or specific binary can be transferred to the device
for further testing. This method also applies to pre built virtual machines using the same architecture
and endianness as the target

Hassan
 [Stage 7] Dynamic Analysis

 In this stage, perform dynamic testing while a device is running in its normal or emulated
environment. Objectives in this stage may vary depending on the project and level of
access given. Typically, this involves tampering of bootloader configurations, web and API
testing, fuzzing (network and application services), as well as active scanning using various
toolsets to acquire elevated access (root) and/or code execution
 Burp Suite  Network and protocol fuzzers such as - Mutiny,
boofuzz, and kitty.
 OWASP ZAP
 Nmap
 Commix
 NCrack
 Fuzzers such as - American fuzzy loop (AFL)
 Metasploit
Hassan
 [Stage 7] Dynamic Analysis

Embedded Web Application Testing

 Specific areas to review within an embedded device’s web application are the following:
 Diagnostic or troubleshooting pages for potential command injection vulnerabilities
 Authentication and authorization schemes are validated against the same framework across ecosystem
applications as well as the firmware operating system platform
 Test whether default usernames and passwords are used
 Perform directory traversal and content discovery on web pages to identify debug or testing functionality
 Asses SOAP/XML and API communication for input validation and sanitization vulnerabilities such as XSS and
XXE
 Fuzz application parameters and observe exceptions and stack traces
 Tailor targeted payloads against embedded web application services for common C/C++ vulnerabilities such
as memory corruption vulnerabilities, format string flaws, and integer overflows

Hassan
 [Stage 8] Runtime Analysis

 Runtime analysis involves attaching to a running process or binary while a device is

running in its normal or emulated environment. Tools that may be helpful are (non-
exhaustive):
 gdb-multiarch  IDA Pro
 Peda  Ghidra
 Frida  Binary Ninja
 ptrace  Hopper
 strace

Hassan
 [Stage 9] Binary Exploitation

 After identifying a vulnerability within a binary from previous steps, a proper proof-of-
concept (PoC) is required to demonstrate the real-world impact and risk. Developing
exploit code requires programming experience in lower level languages (e.g. ASM, C/C++,
shellcode, etc.) as well as background within the particular target architecture (e.g. MIPS,
ARM, x86 etc.). PoC code involves obtaining arbitrary execution on a device or application
by controlling an instruction in memory.

 It is not common for binary runtime protections (e.g. ASLR ) to be in place within
embedded systems however when this happens, additional techniques may be required
such as return oriented programming (ROP)
Hassan
 Automated Tools

 There are a number of Online as well as offline tools available that can automate
the process of Firmware Analysis
Bug Prove

 Here we can test 3 firmware per month for free

 It analyses binaries and look for zero days vulnerabilities

Hassan
 Automated Tools

Bug Prove

Hassan
 Automated Tools

Bug Prove

Hassan
 Automated Tools

Bug Prove

Hassan
 Automated Tools

Bug Prove

Hassan
 Automated Tools
Firmware Analysis and
Comparison Toolkit

Hassan
 Automated Tools

EMBA

Hassan
Thanks

Hassan 34