Rebadged, Relabeled, Rooted: Pwnage via Solar Supply Chain

Rebadged, Relabeled, Rooted: Pwnage via Solar Supply Chain

Speakers: Anthony Rose, Jake Krasnov

Conference: DEF CON 33

YouTube: https://www.youtube.com/watch?v=aKCSoAtxEHc

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Russell%20Phillips%20-%20How%20to%20Fake%20a%20Badge%20like%20a%20Pro%2011%20Tips%20to%20Counterfeiting%20Event%20Credentials.pdf

Overview

Solar energy infrastructure is expanding rapidly across residential, commercial, and utility scales — but its supply chain is riddled with security problems that most buyers never think to ask about. At DEF CON 33, Anthony Rose (aka Coin) and Jake Krasnov (aka Hubble) from BC Security presented a comprehensive security assessment of solar inverters, charge controllers, and associated monitoring systems purchased from the consumer and commercial market. Their core finding: many solar products sold under distinct brand names are identical hardware with different stickers, share the same vulnerable firmware, and can be owned remotely — in some cases with no authentication at all — giving attackers control over grid-tied energy infrastructure at scale.

The research covers hardware identification, firmware extraction, vulnerability discovery, and demonstrated exploitation of real-world solar devices — with implications not just for device owners but for grid stability.

Background

▶ Watch: Rebadged and relabeled devices: same hardware, different brands (0:06)

The Solar Supply Chain Reality

The solar industry has undergone massive consolidation of manufacturing while maintaining the appearance of product diversity. Dozens of brands sell solar inverters, charge controllers, and monitoring gateways that are produced by a small number of original equipment manufacturers (OEMs) in China and Taiwan. A product selling in the United States under an American brand name may be physically identical — same PCB, same components, same firmware — to products sold under completely different brand names in Europe and Australia.

This "rebadging" or "white-labeling" practice is common across consumer electronics, but it has particularly severe security implications in critical infrastructure. When a vulnerability is discovered in the underlying OEM firmware, every rebadged product shares the same vulnerability, regardless of brand. Patches may be released by some vendors but not others. Enterprise security teams that performed vendor due diligence on "their" brand may have missed vulnerabilities documented under a different product name.

Why Solar Security Matters at Scale

Solar inverters — the devices that convert DC power from solar panels to AC power for grid connection — are now mandatory grid-tie devices in most jurisdictions. A grid-tied inverter communicates with the electrical grid and must comply with standards like IEEE 1547 and UL 1741 for anti-islanding protection. More advanced inverters participate in demand response programs, receiving commands from utilities to curtail or increase output.

The monitoring systems attached to these inverters — often cloud-connected gateways that report production data and accept remote commands — represent an internet-exposed attack surface directly connected to devices controlling significant power generation. A coordinated attack against a large number of distributed solar installations could, in theory, affect grid frequency stability if many inverters simultaneously disconnect or behave unexpectedly.

Rose and Krasnov's background in avionics and military cyber operations (Jake worked at Boeing's Phantom Works on avionics security; Anthony is an Assistant Professor at the Air Force Institute of Technology with a PhD in electrical engineering) gives them a systems perspective on the risks that pure software researchers might underweight.

Prior Research Context

Solar and renewable energy device security has been an emerging research area. Prior work (including research by Secura, Fraunhofer AISEC, and independent researchers) has identified vulnerabilities in specific solar monitoring platforms. Rose and Krasnov's contribution is to systematize the supply chain perspective: rather than analyzing one vendor's product, they examine how vulnerabilities propagate across the rebadged ecosystem and demonstrate that the same firmware vulnerability affects devices sold under many different brand names.

Key Findings

▶ Watch: CVE disclosures: critical vulnerabilities in solar management systems (1:20)

• Multiple commercial solar inverters and monitoring gateways share identical firmware despite different branding. Physical teardown and firmware extraction confirmed that devices from at least three separate brands in the researchers' test corpus were running the same underlying firmware with trivially different configuration.

• The shared firmware contains multiple high-severity vulnerabilities, including hardcoded credentials, unauthenticated command injection endpoints, and insecure update mechanisms.

• Hardcoded credentials are present in devices across multiple product families. These credentials, once extracted from one device's firmware, work against all devices sharing the same OEM base.

• Remote code execution is achievable with no prior authentication on affected devices through command injection in web-accessible management interfaces.

• Affected devices are internet-exposed at scale. Shodan and Censys searches for the devices' characteristic HTTP banners, service signatures, and open ports revealed thousands to tens of thousands of internet-exposed instances, many running unpatched firmware.

• The monitoring cloud infrastructure in some cases was also vulnerable, extending the attack surface beyond individual devices to the aggregated control plane.

Technical Deep Dive

▶ Watch: Grid security implications of compromised solar inverters (1:31)

Hardware Identification and Teardown

The research began with purchasing multiple solar monitoring and control devices from consumer channels. Physical teardown revealed the OEM supply chain: identical PCBs, identical component markings, and in several cases identical manufacturer-printed labels underneath the brand's cosmetic sticker. The researchers also compared firmware images across brands and found identical binaries (confirmed by hash comparison and diff analysis), establishing the rebadged supply chain definitively.

Firmware Extraction

Firmware was extracted using multiple methods:

• UART/serial console access: Many devices expose a debug serial console on unpopulated PCB pads. Connecting a USB-to-UART adapter allowed access to the bootloader and OS shell, from which the firmware filesystem could be dumped directly.
• JTAG interface: Some devices exposed JTAG headers permitting direct flash read without booting the OS.
• SPI flash direct read: For devices without accessible debug ports, desoldering the SPI flash chip and reading it with a programmer provided the raw firmware image.
• Update package analysis: Several vendors provided firmware updates as downloadable archive files. These archives contained the full firmware image, sometimes lightly obfuscated but trivially decompressed.

Vulnerability Analysis

With extracted firmware images available (Linux-based systems running BusyBox on ARM or MIPS processors in all tested cases), the researchers performed static and dynamic analysis:

Hardcoded Credentials:

The /etc/passwd and /etc/shadow files in the extracted filesystems contained hardcoded root password hashes. Several devices used the same password across the OEM product family. Cracking these hashes (using standard dictionary attacks against the weak passwords chosen by the OEM) provided root credentials that worked on any device sharing the same firmware.

Additionally, web application configuration files hardcoded administrative credentials for the device's management interface in plaintext, completely separate from the system-level credentials.

Command Injection:

The web-based management interface (served by a lightweight HTTP daemon, typically mini_httpd or a custom CGI framework) contained multiple command injection vulnerabilities in parameters processed by shell scripts. Specifically, diagnostic functions (ping, traceroute, network configuration) passed user-supplied input directly to shell commands without sanitization:

These endpoints were accessible without authentication on some devices (authentication was enforced on some pages but not all diagnostic endpoints), enabling unauthenticated remote code execution.

Insecure Update Mechanism:

The OTA update mechanism on affected devices downloaded update packages over HTTP (not HTTPS), with no signature verification of the downloaded package before installation. This enabled a man-in-the-middle attack to push arbitrary firmware to any device performing an update check, achieving persistent compromise.

Cloud Infrastructure Vulnerabilities:

Several devices registered with vendor cloud monitoring platforms that exposed additional vulnerabilities. The researchers identified insecure direct object reference (IDOR) issues in cloud APIs that allowed one authenticated user to read telemetry data from, and in some cases send commands to, devices registered to different accounts. In the worst cases, this meant any registered user of the monitoring platform could send control commands to any other user's inverter.

Exploitation and Impact

Combining the hardcoded credentials and command injection vulnerabilities, the researchers demonstrated full remote root compromise of affected devices with a single HTTP request to an unauthenticated endpoint. From a compromised device, an attacker could:

• Modify inverter operating parameters (output power limits, grid connection thresholds)
• Disable anti-islanding protection (a safety feature that disconnects the inverter from the grid during grid faults — disabling this creates a safety hazard for utility workers)
• Use the device as a pivot point to attack other devices on the same local network (home automation, other IoT devices, eventually workstations)
• Enroll the device in a botnet for coordinated attacks (the devices run persistent Linux with outbound internet access)
• Corrupt or delete monitoring data, frustrating owners' ability to track system performance and detect anomalies

At scale — given the Shodan-identified exposure of thousands of devices — coordinated exploitation could represent a meaningful threat to distributed grid stability, particularly in regions with high solar penetration.

Demo / Proof of Concept

▶ Watch: Firmware analysis revealing shared vulnerable codebase (4:32)

The DEF CON 33 demo included:

1. Live remote exploitation: Starting from a publicly accessible IP address of a test device, the researchers demonstrated a single unauthenticated HTTP request achieving command execution, then escalation to an interactive shell.

1. Cross-brand credential reuse: Credentials extracted from one vendor's firmware image were used to authenticate to a device sold under a completely different brand name, confirming the rebadged supply chain vulnerability amplification.

1. Shodan enumeration: A live Shodan query demonstrating the scale of internet-exposed devices with the characteristic banners of the affected product families.

1. Cloud IDOR demonstration: Using two test accounts on an affected monitoring platform, the researchers demonstrated that one account could access telemetry and send commands to a device registered to the other account.

Defensive Implications

▶ Watch: Remote access vulnerabilities in solar monitoring platforms (11:15)

For solar system owners:

• Place solar monitoring gateways on an isolated network segment (or a dedicated IoT VLAN) with no direct path to workstations, servers, or sensitive network resources.
• Immediately change default credentials on any solar monitoring or control device. If the device has hardcoded credentials (confirmed by checking if changing the "admin" password actually prevents root login via other means), contact the vendor.
• Disable any remote management features not actively needed.
• Check for firmware updates and apply them. If the vendor does not provide signed updates over HTTPS, treat the device as permanently compromised and segment it accordingly.

For solar installers and integrators:

• Perform vendor due diligence that includes verifying whether the product is an OEM rebadge and checking whether known vulnerabilities in the OEM firmware have been patched.
• Include network security requirements (separate network segment, no direct internet exposure) in standard installation procedures.

For utilities and grid operators:

• Grid-tied solar inverters with internet-exposed management interfaces represent a distributed attack surface at the grid edge. Demand response and smart-grid programs that communicate with these devices should ensure communication channels are authenticated and encrypted end-to-end.
• Consider requiring that grid-participating inverters comply with minimum security baselines (similar to the NERC CIP framework for large generators) before connection is authorized.

For policymakers:

• The rebadging problem means that CVEs and vulnerability disclosures filed against one product name may not be searchable for operators of identical hardware sold under different names. A product identifier registry or mandatory disclosure of OEM supply chain relationships would improve accountability.

Key Takeaways

1. The solar product supply chain is dominated by OEM rebadging, meaning a single firmware vulnerability affects many products across multiple brand names — dramatically amplifying the blast radius of any disclosed vulnerability.
2. Hardcoded credentials, unauthenticated command injection, and unsigned OTA updates are prevalent in the tested solar monitoring and control devices.
3. Remote unauthenticated root compromise is demonstrated on affected devices; thousands of similar devices are internet-exposed.
4. The attack surface extends to cloud monitoring platforms, which in some cases allow cross-account device control via IDOR vulnerabilities.
5. Grid-scale impact is plausible given the distributed deployment of vulnerable, internet-connected devices with control authority over grid-tied generation.

About the Speaker(s)

▶ Watch: Exploitation demonstration against solar infrastructure devices (13:45)

Jake Krasnov (aka Hubble) is the Red Team Operations Lead and Embedded Systems Specialist at BC Security. He has a background in astronomical engineering and served in the US Air Force, where he worked in missile testing and later at the 57th Information Aggressor Squadron conducting offensive cyber operations emulating nation-state threats. He subsequently joined Boeing's Phantom Works division as a lead security engineer for avionics.

Anthony Rose (aka Coin) is an Assistant Professor at the Air Force Institute of Technology with a PhD in electrical engineering. He co-created BC Security's offensive tooling and conducts research at the intersection of machine learning and offensive security. He and Krasnov previously worked together on fighter aircraft cyber testing, and at DEF CON 33 they combined their systems engineering expertise with offensive security skills to systematically evaluate the solar energy supply chain's security posture.