Contributions from Mathew Mullins, Supply Chain Security Consultant here at Eclypsium.

Introduction

Penetration tests come in many different varieties with the scope varying from all-inclusive to highly specific. When the penetration testing engagement includes devices there is an opportunity to both highlight weaknesses and weaponize the firmware. Many resources and materials exist that explain how to “pen test firmware”. In many of those exercises, the penetration tester or security researcher has access to the firmware and/or the physical device and is testing the resilience and security of the device itself. But what if you are on an engagement testing an environment more holistically that may contain devices you can target remotely? This article aims to describe some of the techniques a tester can use to be more effective in these situations, with the goal being to highlight how attackers use anything in scope, especially the firmware on devices that are often neglected or unmonitored.

Like the penetration testing scenario described above, Red team operations may also include firmware as an attack surface of interest. Due to the open nature of operations, coupled with the lack of industry scrutiny for firmware or IoT devices, operators may find significant advantages in exploiting internal or perimeter devices. Such devices, typically lacking EDR or stronger exploit prevention technologies, may prove an excellent “safe harbor” for either persistence or even an established beachhead into a network (or both). 

I am challenging some assumptions that are present today when defending an organization, including:

1. A purpose-built device should come from the manufacturer “secure”, and free of vulnerabilities. If you purchased a device to perform a specific function (e.g. a VPN appliance) the end-consumer typically does not directly maintain the underlying operating system and applications, and we shift the responsibility of security upstream to the vendor.
2. Firmware updates fall outside the scope of patch management processes (this assumption means that firmware patches do not get applied regularly, if at all)

Finding A Target

During an offensive engagement, several different methods are used to discover targets, depending on the scope and type of assessment. You may be able to scan the target networks to discover devices or you may have to do some OSINT to learn what technology is in use (or preferably both). A great example of discovering perimeter devices of interest is simply using tools like SHODAN or Censys. These tools both allow for the identification of assets in an OPSEC-safe way. This method is of particular interest for Red teamers due to it being a form of “soft recon” or reconnaissance that does not directly have the operator’s systems interact with the target’s systems.

For demonstration purposes, I chose to use Netgear firmware on a specific device: A Nighthawk AXE7800 WiFi Router (RAXE300). While this device is a consumer-focused target, the methods described here apply to many types of devices you would likely encounter on a penetration test for an enterprise (such as VoIP phones, Network Attached Storage (NAS), video teleconferencing equipment, building automation systems, etc…). I also chose Netgear as they run a bug bounty program through Bugcrowd that is well-documented and clearly outlines the rules of engagement and disclosure processes: 

• Netgear Bug Bounty Program 
• Netgear Program Details 

While we will not be disclosing new vulnerabilities as part of this tutorial, we’ll leave that as an exercise for the reader. 

Customizing EMBA

The open source firmware analyzer EMBA is an excellent resource for these types of engagements. All of the “Pre-Modules” that begin with “P” are enabled to allow for firmware extraction to take place, a crucial step in the process. A new scan profile is created with the following module blacklist configuration:

export MODULE_BLACKLIST+=( "S10_binaries_basic_check" "S110_yara_check" "S12_binary_protection" "S13_weak_func_check" "S14_weak_func_radare_check" "S15_radare_decompile_checks" "S16_ghidra_decompile_checks" "S17_cwe_checker" "S99_grepit" )

If you are performing a penetration test of the device directly and not including it in scope with some other form of testing you may want to create a scan profile that enables all the modules. For quicker scan times we’ve disabled the following functionality:

1. S10_binaries_basic_check – The main idea is to identify the binaries that are using interesting and weak functions (e.g. strcpy) and to establish a ranking of areas to look at first.
2. S110_yara_check –  Checks files with yara for suspicious patterns.
3. S12_binary_protection – This module checks for protection mechanisms in the identified binaries via checksec.
4. S13_weak_func_check – This module was the extended S10 module. It iterates through all executables and generates a disassembly with objdump. This disassembly is further analyzed for interesting functions like strcpy (defined in helpers.cfg). 
5. S14_weak_func_radare_check – As S13 it iterates through all executables and generates a disassembly with radare2. All other steps are quite similar to S13. As the module runs quite long with high CPU load it only gets executed when the objdump module fails.
6. S15_radare_decompile_checks – This module identifies binaries that are using weak functions and creates a ranking of areas to look first.It iterates through all executables and searches with radare for interesting functions like strcpy (defined in helpers.cfg). 
7. S16_ghidra_decompile_checks  – This module is using Ghidra to generate decompiled code from the firmware binaries. This module uses the ghidra script Haruspex.java (https://github.com/0xdea/ghidra-scripts). 
8. S17_cwe_checker – Runs a Docker container with cwe-checker on Ghidra to check binary for common bug classes such as vicious functions or integer overflows. 
9. S99_grepit – Initial implementation of the great grepit tool from CRASS (code review audit script scanner) 

With our new scan profile configured let’s scan some firmware!

Running EMBA Against A Target

For testing and poking around the file system of various firmware that I encounter, I’ve been relying on EMBA. We previously discussed EMBA here in a post called “Exploring EMBA: Unraveling Firmware Security with Confidence”. I maintain an Ubuntu 22.04 virtual machine to run EMBA (following their documentation to install, configure, and keep it updated). Give this virtual machine as many resources as you can or use a local server just for this purpose, or you could use cloud computing, but that may get expensive. Be certain EMBA has plenty of CPU, RAM, and disk space—the more the better (details on system requirements are available on the EMBA wiki).

I ran EMBA as follows:

$ sudo ./emba -l ./logs/ -p scan-profiles/pentest.emba -t -f ~/firmware/RAXE300-V1.0.8.64_3.zip -g

• -l – Specifies the log directory to store the results and the extracted file system(s)
• -p – Indicates the scan profile to use. Here we are using a custom scan profile.
• -t – Activates multi-threading. Since I gave the virtual machine multiple cores, this should make it run a little faster.
• -f – The firmware file to be extracted and analyzed
• -g – Tells EMBA to create a grepable log file for troubleshooting purposes and/or to go back and look for specifics in the analysis.

It is not uncommon for EMBA to take a long time to run. Sometimes this can take 24 hours or longer depending on the checks you’ve enabled and the structure of the firmware being analyzed. I have, for example, kicked off EMBA scans and let them run over the weekend. This is not ideal for certain penetration testing engagements that are limited in time. However, using the custom scan profile we created to skip the time-intensive testing modules (and not worry about reversing every binary on the file system to look for possible areas of vulnerabilities) we can cut down our scan times extensively. I was actually quite impressed that the target firmware finished scanning in about an hour!

Now that the EMBA scan has completed we’ll review the results and explore potential exploitation paths.

Discovering Potential Exploits

Firmware comes in all sorts of different shapes, sizes, and types. The first piece of information I am looking for is the platform type, e.g. Which CPU architecture and which operating system are we dealing with? EMBA tells you this right on the main page of the report:

Now we know we have a Linux operating system running on ARM (and if you guessed that LE stands for “Little Endian” you would be correct!). Clicking on the grey arrows on the right brings you to a page with more information about the finding. For example, the kernel page gives you a report from the S25 module that analyzes the kernel. This system seems to have an older kernel 4.9.x from December 2016. You may be a bit puzzled as to why a brand-new model router is using an almost 8-year-old Linux kernel. My theory, which I have not yet proven, is that there is hardware on this platform for which a supplier (usually the Wi-Fi chipset and/or SoC) has provided a binary blog driver that was compiled for this kernel, which holds back the entire system from using more recent versions of open source software. EMBA provides further kernel analysis by using the Linux Kernel Exploit Suggester to find known vulnerabilities and exploits. The report states there are 81 kernel space exploits. The report also details each vulnerability and even provides links to PoC exploits, for example:

This would come in handy in the event that we did gain remote access and needed to escalate privileges, however, at this stage of the analysis we are a long way from needing LPE.

PHP Vulnerabilities

EMBA automatically discovers file types and if there are PHP files present they will be analyzed with static source code analysis tools (progpilot and semgrep). Progpilot discovered a potential vulnerability in foldertree.php:

Digging into the vulnerability results we find that there is a potential path traversal vulnerability on line 25:

A bit of research uncovers that the PHP code that presents a file chooser for USB-connected devices uses code from this website: Tracing down the functionality led me to believe that the input is not user-controlled and the user must be authenticated to access this functionality. 

LigHTTPD Vulnerabilities 

EMBA provides analysis of the web server technology in use as well. In this case the firmware is running lighttpd version 1.4.59.

While this particular version of lighttpd does not contain vulnerabilities with known exploits, lighttpd is often used in firmware distributions and earlier versions contain vulnerabilities that may not have been patched. For example, previous research has shown that many IoT devices use older versions and have not been updated (See VU#31226 for more information).

Related Vulnerabilities and Exploits

You can use various tools to query the CVE database to look for vulnerabilities and exploits specific to a platform such as Netgear in hopes that it may lead you in the right direction to more easily discover an exploitation path. My favorite tool for this is cve-maker. Once you’ve got it installed, execute a search as follows:

Looking through the results, let’s start with any CVEs published in 2024 (although the dates do not always accurately depict when the CVE was published). Several of the disclosed CVEs with 2024 in the CVE number point back to research that was published this year in the article Security Advisory – Multiple Vulnerabilities in Netgear WNR614 Router. CVE-2024-36787 states: “An issue in Netgear WNR614 JNR1010V2 N300-V1.1.0.54_1.0.1 allows attackers to bypass authentication and access the administrative interface via unspecified vectors.” While we are testing a different router, we do have the same file within the firmware we are testing (PWD_password.htm), which references base64 hashing. Unfortunately, there is not a detailed description or PoC exploit for us to work with. This is a likely path to perhaps find an authentication bypass, or it could have been patched by Netgear on supported models. The next step in this research is to do some patch diffing in an attempt to determine where the vulnerability was patched and discover more details that would lead to an exploit.

CVE-2024-4235, while carrying a mere 2.7 CVSS score, points to the research detailed in Netgear DG834Gv5 – Plain Text Credentials Exposure. While many examples are given, including vectors as simple as accessing the page BSW_wsw_summary.htm, it appears exploitation requires authentication. Also, the firmware we are analyzing does not contain the file BSW_wsw_summary.htm, which makes sense that Netgear has removed this from more recent firmware versions (even though the CVE entry states: “NOTE: The vendor was contacted early about this disclosure but did not respond in any way.”).

Netgear routers also contain a vulnerability, CVE-2024-6646, which also states the vendor did not respond to the disclosure (likely these model routers, different from the one we are testing, are no longer supported). This vulnerability leads to information disclosure due to a vulnerability in the downloadFile.php PHP application. This file was also not included in the firmware we are testing (more details can be found here). 

CVE-2024-7153 details yet another vulnerability in older Netgear models and firmware that can be exploited “By visiting http://your-ip/siteSurvey.php, an attacker can obtain detailed information about the wireless network.” As with the other vulnerabilities, this file does not exist in the firmware we are examining. 

At the time of this writing, Netgear has 8 entries on the CISA KEV. For many of the vulnerabilities, there is no patch available, which according to CISA should not qualify to be on the KEV list as this list represents actionable information. In the case of IoT devices, the remediation recommendation is: “Apply updates per vendor instructions. If the affected device has since entered end-of-life, it should be disconnected if still in use.”

Summary

The goal of this article is to enable penetration testers (internal or external), as well as Red team operators, to discover and exploit weaknesses in IoT and/or network devices. Open-source tools, configured specifically for this task, make the process easier and less tedious. You can reference previous security research and disclosed vulnerabilities to help guide your efforts in the right direction. Firmware-based devices often include older, vulnerable software and contain exploitable vulnerabilities in web management interfaces that can pose a threat to your overall network security. Attackers have increasingly used these attack vectors as jumping-off points and command and control servers, so make sure you (and your penetration testers) are digging into the security of all devices on your network.

The post Firmware Guide for Pen Testers appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

*** This is a Security Bloggers Network syndicated blog from Eclypsium | Supply Chain Security for the Modern Enterprise authored by Paul Asadoorian. Read the original post at: https://eclypsium.com/blog/firmware-guide-for-pen-testers/