Research by: Andrea D’Ubaldo, Antonio Montillo

Swascan discovered a backdoor in Solar-Log GmbH’s Photovoltaic (PV) monitoring devices with direct impact on thousands of customers. The backdoor could allow an unauthenticated attacker to access remotely to super admin functionalities and restricted area.

Technical Summary

Remediation

Download the new Firmware version 5.1.2_156 and 4.2.8_117 from https://www.solar-log.com/en/support/firmware

Background

In 2021, Swascan identified during a Penetration Testing activity a PV (Photovoltaic) device by Solar-Log. The device ran an outdated version of the firmware with known vulnerabilities and available online exploits. Swascan’s Research Team decided to investigate and explore issues on the newest version of the firmware.

Solar-Log GmbH Vendor

Solar-Log GmbH is a pioneer and one of the leading companies in the areas of PV monitoring, smart energy, and feed-in management with global service for power and heating. Solar-Log™ is compatible with more than 2000 components – making it an unrivaled energy management system for renewable energy.

Solar-Log main products are:

• Solar-Log 50 Gateway, Residential Solar Monitoring: simplified gateway to monitor residential solar PV plants.
• Solar-Log Base Data Logger & Energy Manager: universal energy monitoring and management device.

Devices deployment

At the time of this research, Solar-Log count more than ten thousand devices reachable over internet. For instance, the query on Zoomeye only looks for exposed Solar-Log webserver login pages, but as mentioned by the vendor, Solar-Log is widely spread in all countries.

The device(s)

The device we tested is called Solar-Log 50 gateway, mainly used for residential solar PV plants monitoring, and the cheapest and most popular product.

How Solar-Log devices works

Solar-Log gateway device is in between the PV modules and other objects like sensors, inverters, and other components, gathering information from them via RS232 or RS422, showing the results on the dashboard of local web server. Alternatively, if configured by the user, it can send data to Solar-Log’s cloud-based solution called WEB-Ernest, which was not in the scope of this research.

In the next image, a generic diagram which describes Solar-Log devices communication between multiple components.

Known Vulnerabilities

Solar-Log’s devices are not new to vulnerabilities, in the past, a couple of exploits have been published on exploit-db.com:

• Solar-Log 250/300/500/800e/1000/1000 PM+/1200/2000: https://www.exploit-db.com/exploits/41671
• Solar-Log 500: https://www.exploit-db.com/exploits/49987

The vendor specifies that all the security issues reported above have now been fixed. Models 250, 300, 1200, and 200 will continue to receive technical support but models 500, 800e, 1000, 1000PM+ and 1200 are “End-of-Life”.

Analysis

The Board

The device is composed by a custom board, with USB, RS232, RS4222 and Ethernet connections. In the next image a front and back side of the board:

Right in the middle of the board’s back (right image) there is the System-On-Module, described in the next paragraph.

Overview of System-on-Module (SOM)

The System-on-Module is an electronic circuit that integrates system functions into a single module and is typically used in embedded systems for industrial applications that require high performance and reliability.

Main parts are:

• i.MX6UltraLite 1x Arm® Cortex®-A7 @528 MHz Processor by NXP https://www.nxp.com/part/MCIMX6G2CVK05AB#/
• NAND FLASH Memory by WINBOND – 25M02GVZEIG https://www.alldatasheet.com/datasheet-pdf/pdf/932060/WINBOND/25M02GVZEIG.html
• RAM: DDR3-RAM 256 MB

Winbond NAND Flash Memory

The NAND is a Winbond W25M02GV (called SpiStack technology), a 2x1G-bit Serial Multi Chip Package, based on the W25N Serial SLC NAND SpiFlash series. The difference between this NAND and the majority of other NAND is that the W25M is composed by two stacked individual W25N01GV NAND flash die into a WSON8 (8 pin) package. Due to this detail, has not been easy to fiind a working programmer able to read that NAND

Analyzing the identifier “W25M02GVZEIG” is useful to better understand how to interact with the NAND flash memory:

Unsoldering the NAND flash memory

At this point we were able to desolder the NAND flash memory from the SOM. We used heat gun took that take some minutes, but it was successfully removed from the board.

Reading from memory

Flashrom tool and CH341 programmer is a good and extremely popular combination that works most of the times for memory dumping. Unfortunately, this was not the case because Flashrom does not include a support for e 25MXXXX NAND series. Looking for programmer and tools able to read a SpiStack technology we found FlashcatUSB, another good and well-known programmer for SPI, I2C and JTAG programming device. Compatible with thousands of Flash memory devices. Connects directly via SPI, I2C or JTAG hardware headers. Also, is the official programming partner of WINBOND.

This programmer also has different adapters, very useful when you do not want to deal with cable connections, soldering jumpers and other stuff. This is our basic setup with FlashcatUSB, WSON8 adapter and the NAND flash:

Running FlashcatUSB software:

FlashcatUSB also comes with a software both for GUI and command line tool. In our case the memory dump method used is SPI NAND Flash.

The board immediately recognized the Winbond W25M02GV series and we were able to start reading the Main memory.

The result is a UBI (unsorted block image) image, which stands for “Unsorted Block Images”, a volume management system for raw flash devices.

Subsequentially, by using a UBI reader tool it was possible to extract images and files:

The “slcore-a” and “slcore-b” partitions seems to be the most interesting, where many core components are located.

Reversing slcore binary with Ghidra

The binary file called slcore seems to be the components containing the web server, so we started looking at this by reversing it with Ghidra.

By inspecting the source code of slcore component, we noticed that a different flow withing the login function exists.

There were two different paths for login into the web application without being a “regular user”.  We call the following profiles “regular users” because they are the three users able to manage the web application:

• user (unprivileged)
• administrator (partially privileged)
• installer/PM (privileged – local installer)

The login function has two different code branches for authentication process, the first one that we can consider “legit” (used by regular users), and the second one that only the vendor knows (used for login as Support profile or Embedded profile).

In agreement with Solar-Log and according to the Coordinated Vulnerability Disclosure, we do not share the source code and the details of the algorithm, we only describe the backdoor process:

1. The user login via Solar-Log web page.
2. In case the username matches a specific user then generate two pseudo-random passwords, the algorithm uses the device’s serial number and the current date time as seed.
3. If the user’s password matches the earlier generated password, then login as administrator or super administrator.

Reproduce the password generation

By analyzing the source code appears that the serial number is written inside the IMX6 processor within the OCOTP register, and it is returned by the function getSerialnr(). This register is mapped as files in sysfs, more specifically in the directory /sys/fsl_otp. Instead of running the firmware and accessing that location, we did something easier. We looked at the output of getSerialnr() function which returns the device’s serial number, read from the OCOTP register, and write the results in the configuration file.

We looked for the code XXX (an ID) within our dumped files and spotted the serial number in the configuration file. In our case the serial number was 547870007. That serial number, written in the OCOTP register is the same that is exposed in the login page of every Solar-Log device.

Exploitation

We confirmed that the serial number and the date time are known to the attacker, because they are visible in the login page of every public Solar-Log device. This is the result of our Proof of Concept, that we do not publish intentionally, by using the Serial Number of our Solar-Log 50 device.

We used the generated password to access as super admin to our Solar-Log device, and with no surprise it worked. Both profiles allowed to access to the restricted area not available for “regular users”.  Access to different sub-menu and configurations:  language, display, login, database, tabular config, driver, integrity check, support communication.

References

Solar-Log GmbH Fixed Firmware: https://www.solar-log.com/en/support/firmware/
CWE 912: Hidden Functionality https://cwe.mitre.org/data/definitions/912.html
CAPEC-190: Reverse Engineer an Executable to Expose Assumed Hidden Functionality https://capec.mitre.org/data/definitions/190.html
CVE-ID: Requested

Timeline

08/02/2022 vulnerability reported to vendor
08/02/2022 the vendor responds and start
09/02/2022 the vendor recognizes the vulnerability and starts working on a remediation
11/02/2022 Swascan share the security advisory with the vendor for content review
22/03/2022 the vendor requests changes to the security advisory and shares the steps of vulnerability remediation plan
25/03/2022 agreement for the date for publishing security advisory
17/05/2022 the vendor requires additional days
07/06/2022 public release of the security advisory
25/01/2023 CVE issued CVE-2022-47767