Exposing the Occultations in Large Off-Grid Solar Systems

Exposing the Occultations in Large Off-Grid Solar Systems

Speakers: Dan Berte, Senior Security Researcher, Bitdefender; Alexandru Lazar, Senior Security Researcher, Bitdefender

Conference: DEF CON 32

YouTube: https://www.youtube.com/watch?v=wCt-93lEIME

Overview

In an era increasingly reliant on green energy solutions, the security of rapidly expanding solar infrastructure has become a critical, yet often overlooked, concern. This DEF CON 32 talk, "Exposing the Occultations in Large Off-Grid Solar Systems," presented by Bitdefender security researchers Dan Berte and Alexandru Lazar, sheds light on severe vulnerabilities discovered in popular solar energy management platforms. The presentation dissects how fundamental security oversights could allow attackers to gain control over millions of solar power systems, ranging from residential installations to large-scale off-grid deployments.

The speakers, seasoned vulnerability researchers with a decade of experience uncovering flaws in consumer-grade and IoT devices, turned their attention to the burgeoning solar sector. Their investigation focused on products from the manufacturer Day and the associated management platform, Solarman. The talk reveals a chain of vulnerabilities, from hardcoded credentials to critical API design flaws, that collectively put an estimated 3.5 million solar installations at risk of remote takeover, highlighting a significant gap between the rapid adoption of green energy technology and the maturity of its security posture.

This research is particularly timely given the explosive growth of solar capacity globally, with over 500 gigawatts added last year alone. While traditional power grids are heavily regulated and protected, the solar sector often operates with less stringent security oversight. Berte and Lazar's work serves as a stark warning to both manufacturers and operators within the green energy space, underscoring the urgent need for robust security practices to safeguard critical infrastructure against sophisticated cyber threats, moving beyond the historical narrative that "squirrel terrorism" is the primary grid vulnerability.

Background

▶ Watch: Introduction and Bitdefender's vulnerability research background (0:00)

The prevailing narrative surrounding power grid security has historically downplayed the threat of cyberattacks, often pointing to natural causes or "squirrel terrorism" as the primary disruptors. Speakers Dan Berte and Alexandru Lazar highlighted this perception, referencing a "squirrel index" on Wikipedia and quotes from former NSA officials suggesting that physical threats to the grid might exceed those posed by cyberattacks. This perspective has, in some ways, fostered a complacency that the highly regulated and protected nature of legacy power generation systems inherently extends to newer energy technologies.

However, the landscape is rapidly transforming with the explosive growth of green energy, particularly solar photovoltaics. Last year alone, over 500 gigawatts of solar capacity were added globally, representing an unprecedented expansion. This rapid adoption, while beneficial for sustainability, introduces a new class of "smart systems" that are often remotely controlled and less stringently regulated than their traditional counterparts. As businesses and consumers increasingly integrate solar panels into their energy portfolios, the question of whether security is keeping pace becomes paramount.

Bitdefender’s investigation was prompted by an observation within their own office regarding a newly installed solar system. They focused on a specific manufacturer, Day, and its associated management platform, Solarman. These platforms are critical because they enable the remote monitoring and control of solar inverters and data loggers—the intelligent components that bridge solar panels to the grid or local consumption and connect to the internet. The researchers aimed to determine if the security practices in this less regulated, rapidly expanding smart energy sector were sufficient to withstand dedicated cyber threats, or if they were indeed "occulted" by the sheer pace of innovation and deployment. Their findings ultimately uncovered systemic vulnerabilities that challenge the conventional wisdom regarding grid security.

Key Findings

▶ Watch: Solar energy's rapid growth and overlooked security landscape (4:00)

The Bitdefender research team uncovered several critical vulnerabilities within the Day solar inverter ecosystem and the Solarman management platform, demonstrating a clear path for attackers to compromise and control millions of solar systems. These findings collectively exposed a severe lack of fundamental security practices.

The initial key finding was the discovery of hardcoded credentials embedded within the Day cloud application. These credentials, [email protected] with the password 123456, were not linked to any specific user account but provided access to device information for any solar system managed by the platform. This effectively created a master key capable of querying sensitive data across the entire user base.

Leveraging these hardcoded credentials, the researchers found they could retrieve a device-specific password for the data logger's local Wi-Fi access point. Each data logger, when running, broadcasts an access point with a predictable naming scheme: AP_serial number. By obtaining the serial number (which can be passively observed or acquired through the hardcoded account), an attacker could then use the retrieved password to connect to the logger's local network.

The most critical finding, however, was a severe API vulnerability within the Solarman platform that allowed for arbitrary account takeover of an estimated 3.5 million accounts. This vulnerability stemmed from a flaw in how the platform handled tokens used for granting guest access to business accounts. By manipulating a POST request body, specifically changing the user ID and email fields within a manufactured token, attackers could generate valid server-signed tokens granting full administrative access to any user or organization account. Crucially, this exploit required no signature checks, no authorization headers, and did not even necessitate the use of alg none attacks, highlighting a profound lapse in API security.

In summary, the key findings demonstrate a progression from local, proximity-based attacks enabled by weak credential management to a far more scalable, remote attack vector through a critical API flaw, putting a vast number of solar installations at risk.

Technical Deep Dive

▶ Watch: Diagram of off-grid solar system architecture and data flow (5:12)

The investigation began by understanding the fundamental architecture of a typical solar power system managed by the Day and Solarman platforms. Solar panels convert sunlight into electricity, which is then fed into an inverter. The inverter is a crucial component, converting direct current (DC) from the panels into alternating current (AC) suitable for household use or feeding into the grid. Connected to the inverter is a data logger, which acts as the central communication bridge. This data logger collects performance metrics, system settings, and is responsible for connecting the entire system to the internet. It transmits this information to a cloud platform (Solarman in this case), which then feeds into various user-facing applications and management dashboards. The data logger is also responsible for receiving updates and configuration commands from the cloud.

The initial phase of the technical deep dive involved a Man-in-the-Middle (MITM) attack on the Day cloud application. The researchers achieved this by using only the user certificate, avoiding the need to patch the application itself. During the traffic analysis, a suspicious login request was identified. This request revealed hardcoded credentials: a username of [email protected] and a password of 123456. These credentials were not tied to any specific user account; instead, they functioned as a universal key to access device information across the entire Solarman platform. This account could query details such as the model, firmware version, and crucially, a device-specific password for any given solar inverter or data logger.

Further investigation revealed that while a data logger is operational, it broadcasts its own Wi-Fi access point (AP). The SSID of this access point follows a convenient and predictable naming scheme: AP_serial number. This means that if an attacker could obtain the serial number of a target data logger, they could identify its local access point. The significance of the hardcoded smartconfigurator account became clear here: it allowed researchers to retrieve the specific password for any data logger's access point by simply providing its serial number.

The local attack vector, as described by Alexandru Lazar, would involve:

1. Finding an access point corresponding to the AP_serial number naming scheme. This could be done through war driving or passive scanning.
2. Extracting the serial number from the SSID.
3. Using the hardcoded smartconfigurator account to make an API request to Solarman and retrieve the corresponding Wi-Fi password for that specific serial number.
4. Connecting to the data logger's access point using the retrieved password.
5. Sending AT commands to the logger to gain access to its user interface, potentially allowing control over the user's Wi-Fi network and direct manipulation of the logger's settings.

While effective, this local attack required physical proximity and could only target one device at a time, making it inefficient for large-scale compromise. The researchers sought a more scalable, remote attack.

Their attention then shifted to other platform features, specifically how users could grant "guest" access to business accounts for system modifications. This led to the discovery of a critical vulnerability within the Solarman API. A search API endpoint was found to return extensive data about all users and organizations registered on the platform. While the front-end only displayed business names, the back-end response contained sensitive information such as emails, phone numbers, physical addresses, user IDs, and even the last login IP addresses for administrators and users. This endpoint provided the necessary reconnaissance data for a widespread attack.

The most severe flaw was identified in an API endpoint used to create new tokens for guest access. The researchers discovered that by crafting a POST request with a manufactured token in the body, they could manipulate the user ID and email fields within that token. Upon sending this request, the Solarman server would then generate a new, valid, server-signed token that granted access to the specified user or organization. Critically, this process completely bypassed standard security checks:

• There were no signature checks on the manufactured token provided by the attacker. The server simply trusted the contents of the user ID and email fields.
• The endpoint did not require an authorization header, meaning an unauthenticated attacker could exploit it.
• The attack did not even require the alg none JWT vulnerability, as the server was directly signing a new token based on attacker-controlled data, rather than processing an unsigned token.

This meant an attacker, having obtained user ID and email information from the previously discovered search API, could effectively create an administrative token for any of the 3.5 million accounts on the Solarman platform. The manufactured token, even with a bad signature, was accepted as input, and the server would then issue a legitimate, signed token, granting full control over the target solar system remotely. This demonstrated a catastrophic breakdown in API security, allowing for arbitrary, large-scale account takeovers with minimal effort.

Demo / Proof of Concept

▶ Watch: Step-by-step local attack using predictable logger access points (7:58)

While the presentation did not feature a live, real-time demonstration, the speakers meticulously walked through the conceptual steps and evidence of their proof-of-concept attacks. For the local, proximity-based attack, Alexandru Lazar detailed the precise sequence of actions an attacker would take. This involved identifying a data logger's Wi-Fi access point (e.g., AP_123456789), using the [email protected] credentials to query the Solarman cloud API for the AP_123456789's specific password, and then connecting to that access point. Once connected, the attacker could issue AT commands to the logger, effectively gaining control over the device and potentially the user's local network. This sequence, though not visually demonstrated, clearly outlined a functional proof-of-concept for localized compromise.

The more significant proof-of-concept involved the remote account takeover vulnerability. The researchers presented a side-by-side comparison of a "manufactured token" (crafted by the attacker with a bad signature) and the "received token" (the legitimate, server-signed token issued by Solarman in response). They explained how they would first use the publicly accessible search API to gather user ID and email information for a target account. With this data, they would then construct a POST request containing a token with the desired user ID and email in its body. Despite the manufactured token having an invalid signature, the Solarman server would process it and return a new, valid token, signed by the server, granting the attacker full access to the target account. This demonstration, relying on the visual comparison of tokens and a clear explanation of the API interaction, served as compelling evidence of the critical remote takeover capability. The fact that the vulnerability was fixed within 24 hours of disclosure further validates the severity and reproducibility of their proof-of-concept.

Defensive Implications

▶ Watch: Limitations of local attack, hinting at remote exploitation (8:30)

The findings presented by Dan Berte and Alexandru Lazar have profound defensive implications for both manufacturers of smart energy systems and the operators/consumers using them. The vulnerabilities exposed in Day and Solarman platforms highlight fundamental security failures that, if unaddressed, could jeopardize critical infrastructure and consumer trust.

For manufacturers like Day and platform providers like Solarman, the immediate defensive actions are clear:

1. Eliminate Hardcoded Credentials: The presence of [email protected] with 123456 as a universal master key is an egregious security blunder. All such credentials must be removed and replaced with robust, unique authentication mechanisms, ideally leveraging multi-factor authentication for administrative access.
2. Implement Robust API Security: The token manufacturing vulnerability is a catastrophic failure in API design. All API endpoints, especially those involved in authentication, authorization, and token generation, must rigorously validate all input. This includes:

• Signature Verification: Any token received from a client must be cryptographically verified to ensure its integrity and authenticity.
• Authorization Checks: All endpoints must enforce proper authorization, ensuring that only authenticated and authorized users can perform specific actions. The fact that the vulnerable endpoint didn't even require an authorization header is a critical oversight.
• Principle of Least Privilege: APIs should be designed so that users and applications only have access to the minimum necessary data and functions.

1. Secure Sensitive Data Endpoints: The search API that exposed user IDs, emails, phone numbers, addresses, and last login IPs for all 3.5 million accounts should be secured. Such sensitive information should never be broadly accessible and should only be retrieved with proper authentication and strict authorization for legitimate purposes.
2. Secure Device Access Points: While local Wi-Fi access points are convenient for setup, their security relies on strong, unique, and non-guessable passwords. The ability to retrieve these passwords via a hardcoded cloud credential is unacceptable. Passwords should be generated securely, stored encrypted, and potentially allow for user-defined changes.
3. Establish a Robust Vulnerability Disclosure Program: As highlighted by Dan Berte, many vendors fail to respond or take too long to patch vulnerabilities. Manufacturers must appoint a permanent security contact, set up a public vulnerability disclosure program with a clear URL, include a PGP key for secure communication, and actively monitor the inbox. This fosters responsible disclosure and ensures timely remediation.

For users and operators of solar systems, the implications emphasize the need for vigilance and informed decision-making:

1. Vendor Due Diligence: Prioritize solar system providers and platform operators with a strong track record of security, transparent vulnerability disclosure, and timely patching.
2. Monitor System Access: Be aware of who has access to your solar monitoring accounts and report any suspicious activity.
3. Physical Security: While the primary focus was on remote attacks, ensuring physical security of data loggers and inverters can mitigate local attack vectors, especially if default Wi-Fi passwords remain unaddressed.
4. Stay Informed: Keep abreast of security advisories and firmware updates from your solar system manufacturer and platform provider.

Ultimately, these findings underscore that the "smart grid" is only as secure as its weakest link. As green energy expands, security must be integrated by design, not as an afterthought, to prevent widespread compromise of critical infrastructure.

Key Takeaways

• Solar Energy's Rapid Growth Outpaces Security: The explosive expansion of solar power capacity introduces smart systems that often lack the robust security regulations and practices found in traditional power grids.
• Fundamental Security Flaws Persist: Critical vulnerabilities like hardcoded credentials and easily exploitable API design flaws can be found in widely adopted solar management platforms.
• Hardcoded Credentials are a Master Key: The discovery of [email protected] with 123456 provided a universal means to retrieve sensitive device information, including local access point passwords.
• Catastrophic API Vulnerability Enabled Mass Account Takeover: A severe flaw in the Solarman platform allowed attackers to manufacture tokens, bypassing signature checks and authorization, to gain administrative control over 3.5 million accounts.
• Proactive Vendor Engagement is Critical: Many vendors fail to respond or take over 180 days to address reported vulnerabilities, with 20% taking over a year or never patching, underscoring the urgent need for clear vulnerability disclosure programs and dedicated security contacts.
• Security by Design is Non-Negotiable: As solar becomes a cornerstone of energy infrastructure, implementing robust security measures from the outset, including secure API design, strong authentication, and continuous monitoring, is paramount to prevent widespread compromise.

About the Speaker(s)

Dan Berte and Alexandru Lazar are Senior Security Researchers at Bitdefender, a global cybersecurity technology company. They are seasoned experts in vulnerability research, with over a decade of experience dedicated to uncovering security flaws in a wide array of devices. Their work primarily focuses on consumer-grade and IoT devices that are popular, interesting, or present significant security challenges.

Over their careers, they have been instrumental in publishing over 25 high-profile vulnerability cases and have authored dozens of white papers detailing their findings. Their past research includes significant discoveries in products such as Ring Doorbell, LG TVs, Amazon Fire Stick, August Lock, UFI Evis cameras, and more. Berte and Lazar are advocates for responsible disclosure, frequently highlighting the challenges researchers face with vendor responsiveness and timely patching, emphasizing the critical need for vendors to establish clear vulnerability disclosure programs.