Remote Code Execution on SolarView Compact Firmware: A Technical Walkthrough
Introduction
Remote system management plays a crucial role in today’s connected environments, enabling real-time monitoring and control of firmware-based products via web interfaces. In this post, we demonstrate how we achieved Remote Code Execution (RCE) on a web server connected to a solar system monitoring firmware: SolarView Compact. This walkthrough covers four key stages: Firmware Extraction, Reconnaissance, Code Review, and Exploitation, and aims to offer insights for both internal knowledge-sharing and training future penetration testers.
Analysis and Firmware Extraction
The target product is the SolarView Compact, designed to monitor solar power systems. At the time of testing, the firmware version was ver 7.00. From the vendor website, we downloaded the update file: svcUpdate700.fpk.
|
💡 Manufacturers often distribute firmware updates as .fpk files, which are uploaded to the device to perform the update. These files typically contain the core firmware code, along with metadata and instructions needed to apply the update properly. |
Knowing that .fpk is a firmware package format, we can attempt to extract its internal contents as shown in Figure 1. Binwalk is well-suited for this task. Running the command binwalk -Me <file-name> allowed us to unpack the firmware files.
Among the extracted directories, the html folder stood out, as it contains the web interface making it a promising initial attack vector.
Reconnaissance
The html directory contains numerous files worth reviewing as seen in Figure 2.
However, before diving into the code, it's essential to determine where the corresponding web server is hosted on the internet. Identifying vulnerabilities in the code is only meaningful if they can be applied to a live target; this is where reconnaissance becomes critical.
We began with index.html, the main page, which might include product-specific keywords. Within it, we found an anchor tag linking to Solar_Menu.php as shown in Figure 3.
To locate live instances, we leveraged Shodan, a powerful search engine for hardware and IoT devices. Using the http.html search filter , the obtained results presented in Figure 4.
The query returned several web servers; however, the Last-Modified headers indicated that most of them were running outdated versions. To ensure consistency with the code we extracted, we needed a more recent instance. During our reconnaissance, we observed that each web page included a copyright footer as shown in Figure 5, a detail that could help refine our search.
What if we refined our Shodan search using the footer text and a recent date to find an active server? Indeed, a recent web server was identified that appears to match the extracted code as shown in Figure 6.
Code Review
Manually reviewing all files would be time consuming, so a more targeted approach was adopted. Since the server runs PHP, functions such as eval, system, and exec were expected and are typically well known and already scrutinized. Instead, attention was directed toward less common functions, such as passthru(), which also executes system commands.
In network_test.php, the host parameter is passed directly into nslookup and ping without input validation and executed via passthru() call as demonstrated in Figure 7, resulting in a RCE vulnerability.
Exploitation
Accessing the referenced file revealed the following interface, as shown in Figure 8.
Command injection payloads like ;ls were rejected, as the input expected a valid hostname. However, using a Burp Collaborator URL as the hostname resulted in a DNS callback, confirming external command execution as illustrated in Figure 9.
How can this behavior be turned into actual code execution? Since the hostname is passed into the passthru() function, subshells such as backticks (`command`) or $(command) can be injected within the hostname. This enables arbitrary command execution, resulting in blind RCE that can be confirmed through DNS based callbacks, as demonstrated in Figure 10.
Mitigation
The vendor mitigated the vulnerability by restricting access to network_test.php using HTTP Basic Authentication as shown in Figure 11, a simple but effective access control layer.
Key Takeaways
This walkthrough highlights how seemingly small implementation choices in firmware-based web interfaces can lead to critical security flaws when combined with real-world exposure. From firmware extraction to live target discovery and exploitation, the exercise underscores the importance of structured reconnaissance, focused code review, and practical validation techniques. The following takeaways summarize what worked well, where limitations were encountered, and the broader lessons applicable to firmware and IoT security testing.
Points of Success:
- Effective Recon: Leveraged Shodan and creative search filters to locate a live, relevant web instance.
- Smart Code Review: Focused on less-common functions passthru() to identify exploitable code efficiently.
- Confirmed RCE: Successfully triggered blind RCE using DNS-based command injection.
Points of Limitation:
Restricted Execution: Payloads containing special characters (id, ls) were blocked, limiting testing.
Lessons Learned
The following lessons summarize the key insights gained from this assessment, highlighting broader security implications that extend beyond this specific vulnerability.
- Firmware Management: Firmware products often include embedded web servers for remote administration. Understanding the interaction between these components is crucial for identifying potential security risks.
- Reconnaissance: Recon is a versatile technique that can be adapted to various contexts. In this case, it enabled us to pinpoint relevant targets and validate our findings effectively.
- Code Review: The success of a code review depends on the approach. By focusing on specific, less-common PHP functions, we were able to efficiently uncover a critical vulnerability.
Writer: Khaled Emad | Cyber Security Engineer I
Editor: Heba Osama | Senior Research Operations Specialist