Background Link to heading

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

We discovered a backdoor and started a cooperation with the vendor in order to fix the vulnerability.

Everything about the vulnerability has been reported by us to the vendor and then published on Swascan’s blog, the company I work for https://www.swascan.com/security-advisory-solar-log/.

How Solar-Log devices works Link to heading

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.

Analysis Link to heading

The Board Link to heading

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:

Figure 4 Circuit board from Solar-Log Gateway 50

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) Link to heading

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:

Winbond NAND Flash Memory Link to heading

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

Figure 5 W2502GV family, source: winbond.com

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

Figure 6 W2502GV family, source: winbond.com

Unsoldering the NAND flash memory Link to heading

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.

Figure 7 Unsoldering NAND flash memory from the SOM

Reading from memory Link to heading

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:

Figure 8 FlashcatUSB + WSON8 adaprter reading WINBOND NAND flash memory

Figure 9 FlashcatUSB with WSON8 adapter connected to the laptop via usb

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.

Figure 10 Winbond detected by FlascatUSB

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

Figure 11 Main Memory Dump with FlashcatUSB

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

Figure 12 Extracted UBI image

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

Figure 13 Extract images with ubireader

Figure 14 Solar-Log Filesystem

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

Figure 15 Core software components

Reversing slcore binary with Ghidra Link to heading

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.

Figure 16 Reversing with Ghidra

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

Figure 17 Part of the login function

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)

Figure 18: Function graph

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 Link to heading

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.

serialNumber <- _getSerialnr_() //read from OCOTP register  
write(configuration, "XXX: %s", serialNumber)

Figure 19 Pseudocode representation (XXX is an ID)

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 Link to heading

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.

Figure 20 Result of the Proof of Concept

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.

Figure 21 Solar-Log Login page

Figure 22 Super admin functions

References Link to heading