SolaX inverter’s Pocket WiFi using poor authentication

CVE-2023-35835, CVE-2023-35836, and CVE-2023-35837
SolaX Pocket WiFi v3
At time of writing believed to affect all known firmware versions
Tested up to and including v3.009.03_20230504
No known plans to distribute patches to existing owners of SolaX equipment

These three vulnerabilities are all in relation to the Pocket WiFi v3 hardware module that can be used with SolaX inverters for solar panels and batteries. The three CVEs represent three different but related vulnerabilities for the same device. Between the three vulnerabilities, an attacker could trivially write a script that detects SolaX Pocket WiFi networks, connects to them, and then issues potentially damaging ModBus commands to the inverter. Additionally, the attacker could use this access to further infiltrate the victim’s WiFi network that the Pocket WiFi device is simultaneously connected to.

CVE-2023-35835: Persistent Open WiFi Access Point

The device maintains a permanent open WiFi access point. It is intended to be used for initial configuration and it lacks any form of network authentication. This access point persists even after setup is complete and provides access to a web-based configuration utility and an unauthenticated ModBus protocol interface. It is possible to send standard ModBus messages to the inverter using this unauthenticated WiFi access point. The ModBus service facilitates reading and writing data to the inverter which could change its configuration and therefore cause disruption to its standard functioning. Though not tested, owing to a limited number of test devices, it is anticipated that this service could be attacked in order to cause physical damage to the inverter and potentially other connected components.

CVE-2023-35836: Network Configuration Disclosure

Attackers within radio frequency range can obtain a cleartext copy of the device’s network configuration, including the Wi-Fi Pre-Shared Key (PSK), during setup and reconfiguration of the Pocket WiFi device. This means that an attacker could access the victim’s Wi-Fi network using the obtained PSK and therefore could perform attacks on machines and services that were otherwise not exposed.

CVE-2023-35837: Web admin uses predictable password

The web interface authentication relies on an unauthenticated WiFi access point, and the administrative password is the device’s registration ID, which is also the WiFi SSID. This means that an attackers could gain unauthorized access to the Pocket WiFi web interface, reconfigure the device, or upload malicious firmware. This then potentially leads to Denial of Service, code execution, or Privilege Escalation.

SolaX’s response to the disclosure

After persistent communication from myself, SolaX informs me that they are going to:

• • “hide the SSID”, which might mean turning off SSID beacons

• • add a “local encryption strategy”, which I think means adding TLS to the web interface, but this is a guess

• • add a “default password modification strategy”, which I hope means alerting users to default passwords

• • add a PSK to the WiFi access point

SolaX have been unable to identify a strategy for getting any security patches distributed to existing owners of their Pocket WiFi modules. They have indicated that they could perform the updates remotely. I asked them for further details but none were forthcoming. At the time of writing there has been no update pushed to the Solax Pocket WiFi device I can access. In all fairness to them, there has been an extra option appear in the smart phone app that suggests it may now be possible to toggle on and off the WiFi access point. This feature doesn’t work though, presumably because I don’t have a corresponding firmware version.

The below summarises my communication with SolaX. As you can see, some of it was hugely encouraging, whilst at other times it was lacking altogether. Above all else, I think this demonstrates how important it is that organisations have a vulnerability disclosure process in place. It was hard to get to talk to anyone in the first place, and even then it wasn’t the right person and during the whole period communication was patchy.

---

On May 11th, I sent an initial email expressing my concerns about the cybersecurity issues I discovered with their product. I offered to help them improve their product through responsible disclosure.

After receiving no response, I decided to follow up on May 17th. I reiterated the importance of responsible disclosure and mentioned my intention to request official CVE IDs with a 90-day disclosure period.

Still not hearing back from SolaX, I reached out to their telephone helpdesk on May 24th and sent another email, hoping for a response.

On May 25th, I received a call from a SolaX UK representative who understood my concerns and advised me to apply for CVE IDs whilst they investigated internally.

I informed SolaX on June 8th that I had submitted the CVE request and also requested their GPG key for encrypted communication.

Unfortunately, I received no response to my request for the GPG key or any subsequent emails I sent.

On July 17th, I sent a reminder about the impending public disclosure of the vulnerabilities on September 15th. I asked for cooperation from SolaX to work on security patches.

SolaX provided me with firmware images on July 20th, and communication resumed.

I asked SolaX about their plans to address the vulnerabilities, the timeline for implementation, and whether they had third-party security testing in mind on July 25th.

On 04 September 2023 after having received no response to several emails I decided to gather all the contacts I could find for company globally from their website and forward the email chain to date to them all asking for a response.

I got a flurry of emails starting on the 13th September, two days before the planned publication date. These were generally quite promising, they were looking at engineering solutions that would make the situation better and though needed a little direction to deal with the issues correctly, they seemed to be taking it all seriously. Then the emails stopped again.

Since I didn’t receive a response, I decided to follow up on September 20th. I wanted to understand when they expected to complete the corrective actions and distribute them to customers. I also proposed a delayed publication date of January 1st, 2024 in an attempt to give them some breathing room.

On September 25th, SolaX confirmed their planned security measures and mentioned a tentative completion date for corrective actions in December. They appeared to be unfamiliar with Coordinated Vulnerability Disclosure (CVD) so I gave them a brief explanation and pointed them to some online articles on the subject.

I reached out again on October 23rd to offer assistance and check on SolaX’s progress but heard nothing back.

On December 21st, I sent a final reminder regarding the impending publication date and requested information on SolaX’s distribution plan for security patches to their customers. As I didn’t hear back and I wanted to be as fair as possible to them, I have delayed publication until today.