It should be explicitly noted that all the described vulnerabilities in this blog were already disclosed to ABB’s ChargeSync and were addressed professionally in the utmost serious manner, resulting also in an already operational and deployed mitigation, in collaboration with the SaiFlow cybersecurity team.

This blog describes three vulnerabilities found on the ChargerSync platform, a Charging Station Management System (CSMS) provider, owned by ABB. These vulnerabilities should serve as a use case for broader attack paths and vulnerabilities that could potentially be found on API interfaces of CSMS platforms. In the ChargerSync use case, we will demonstrate attack vectors that expose drivers’ data and impact service availability of the vendor’s provisioning process, management, and operations of charging stations.

TL;DR

The SaiFlow research team found multiple vulnerabilities in ChargerSync platform, ABB’s CSMS provider for the Terra AC charging stations, allowing adversaries to access files uploaded by other users, bypass the required provisioning PIN code (authentication), and hijack a charger OCPP connection. The vulnerabilities are described below:

• An exposed old API allowed adversaries to bypass the PIN code requirement in the charger provisioning process and takeover chargers that are not yet provisioned by ChargeSync. Doing so could have prevented chargers from being provisioned by the user. Alternatively, gathering the PIN codes of ABB chargers that are not yet provisioned, could have been leveraged to overtake a large number of charging stations in the future to perform extorsion.
• A file import vulnerability allowed users in the ChargerSync portal to access files uploaded by other users and organizations, which included drivers’ personal data such as ID Tags, Emails, and Usernames.
• Lack of support for charging station basic authentication methods enabled adversaries to hijack OCPP connections (including chargers already deployed in the field), disrupt the chargers’ operations, and expose sensitive OCPP data from ChargerSync. You can find more details on OCPP hijacking covered by previous blogs on SaiFlow’s website.

While these vulnerabilities were found specifically on the ChargerSync platform, Charging Network Operators (CPOs) and e-Mobility Service Providers (eMSP) should be aware of possible data leakages and API vulnerabilities in CSMS platforms. CPOs should constantly monitor their charging networks for any suspicious activities and compromised ID tags.

Technical Details

About ChargerSync Platform

ChargerSync is a Charging Station Management System (CSMS) provider, owned by ABB, which is used solely for their Terra AC Wallbox charging models. ChargerSync provides charging management capabilities such as setting the charging station’s configuration, assigning drivers ID tags, and more. The platform also serves as the control center that authorizes field operators (installers) when configuring the charger via the TerraConfig mobile application (as part of the charger station provisioning process).

Provisioning a new ABB Terra AC charger to a charging management (CSMS) platform is done using the ABB TerraConfig mobile application (as can be seen for example in Monta’s provisioning guide here: ABB AC Installation Guide – Monta). The charger provisioning process requires a unique PIN code delivered with the charger’s installation papers. After a successful installation, the operator can configure the charger using the CSMS platform and add ID Tags of EV drivers that will be allowed to use the charger after authenticating with an RFID card (or other means).

Bypassing The PIN Code Authentication

ChargerSync provides two mobile apps, one for personal use (by EV drivers) and one for field operators use (Installers), which are called ChargerSync and TerraConfig apps respectively.

When using the ChargerSync mobile app, we discovered that the app uses the API endpoint: https://abb.api.chargedot.com:18971/api/v3/user/device/bindv2, with a JSON payload containing the keys pinCode and deviceNumber. These keys represent the charger’s serial number and PIN code value. For example: {"deviceNumber":"TACW22XXXXXGXXXX","pinCode":"ab3de6gh"}.

Field operators must provide a PIN code when they onboard their charging stations to the ChargerSync platform both in the mobile app and web portal. The unique PIN code is provided with the papers of the charging station.

A successful binding (provisioning) request to the ChargeSync platform will result in the charger being bound to the requesting user’s account, and in a response with an HTTP body containing the charger’s full details. The binding process will reject any provisioning request with an invalid pin code value.

After a successful binding process, the newly added charging station could be found on the user’s “charging stations page” in the ChargerSync platform. On the charging stations page, we can locate the value of the PIN code that was assigned to the charging station (The PIN code value was also provided to us in response to the successful binding request).

However, the SaiFlow research team found that the ChargerSync API service also exposed the endpoint: https://abb.api.chargedot.com:18971/api/v3/user/device/bind (bind instead of bindv2 as mentioned above) which is an old version of the API service. The “old” API could have been used to bind charging stations without needing to provide the PIN code. The JSON payload for this API required only the deviceNumber key, essentially allowing adversaries to bypass the PIN code authentication requirement.

ChargerSync allows the change of the PIN code using the button next to the PIN code, as shown in the figure below (Figure 2). An adversary could have just clicked on the reset PIN code button which will make it inconsistent with the PIN code that was provided to the person who purchased the charger. When that person would have tried to configure their charger with TerraConfig app or to bind it to their ChargerSync account, they would have been rejected with an error of “incorrect PIN code”.

Threat actors could have caused massive disruption to ABB’s customers by exploiting this vulnerability and resetting the PIN code values using ChargerSync API at scale. By doing so, customers who intend to use ChargerSync or TerraConfig apps to manage their chargers would have failed in their binding attempts when using the old and already invalid PIN code values. It would have also resulted in a spike in help-desk calls by customers who seek help in addressing their PIN code issues.

Note: The binding operation would work only if the charger is not already bounded or provisioned (This applied to both bind and bindv2 endpoints).

The serial number of ABB Terra AC chargers are sequential and their identifier could be enumerated by using the TACW, Model type number (kilo-watts per hour) prefix and 10 digits of 0-9 and A-Z, allowing adversaries to exploit this vulnerability at scale and cause widespread damage.

At first, it seemed like the charging station also provided sensitive data about the charger’s actual address. After further investigation, we realized that the address points to the location of the Terra AC chargers manufacturer.

Exposure of Sensitive EV Drivers’ Information Through File Import

ChargerSync web portal provides the ability to manage and register ID Tags for EV drivers that intend to use the chargers in their apartment building or workplace.

The web portal allows a user to register a batch of EV drivers by uploading a CSV or XLS file to https://abb.admin.chargedot.com/api/v1/util/img/upload API. When a user successfully uploads a file, the service will return back a file identifier. The returned file identifier is then provided to /api/v1/user/card/import API for the import process of the file. After a successful upload, the EV drivers list is saved and added to the list of drivers managed by the user account that executed the import operation, as expected.

SaiFlow’s research team found that when such a file was uploaded to the ChargerSync portal, the generated file identifier was a sequential number that could have been easily enumerated. During the enumeration process (i.e. when trying to import “random” files to a user account), when a valid file identifier was selected for import, the drivers’ information stored in that file was exposed in the ChargerSync portal and could have been seen by an unauthorized user. The drivers’ information included their ID Tags, Usernames, and Email addresses. The access to file identifiers, generated for other users, was not enforced securely, allowing any user in the ChargeSynce platform to access these files indirectly and expose sensitive driver information.

For example, in the figure below (Figure 5) we demonstrated a request to import a “random” file ID that was generated for another user which resulted in the exposure of that user’s name, email address, and the company he works for (Figure 6).

OCPP Hijacking

Despite having covered the subject and the need to enforce EV charging station OCPP authentication extensively before (https://www.saiflow.com/how-mishandling-of-websockets-can-cause-dos-and-energy-theft/), we still find it to be a common vulnerability in most CSMS platforms and charging stations. It seems that this issue will follow us at least for a while.

While Terra AC chargers support OCPP Security Profile 2, ChargerSync didn’t support a credential-based authentication method for the charging stations, which could enable adversaries to hijack the OCPP connection between the charger and the ChargerSync platform. Exploiting that vulnerability could have disrupted the charging station service and could have exposed sensitive data sent by ChargerSync to the charging station like Local Authorization List, which contains ID Tags.

The good news is that after disclosing the vulnerabilities above, ABB also added support for Security Profile 2 and is enforcing it by default on ChargerSync for Terra AC chargers.

Mitigations

As part of the security disclosure made by SaiFlow to ABB’s Security Team, the mitigations that were suggested, and deployed to the ChargeSync platform and to the ABB Tera AC Chargers from version 1.6.6 and above, were as follows:

• Removal of redundant APIs from the ChargerSync service, especially the old deprecated binding function which bypasses the PIN code authentication.
• Enforcement of authorization control on the API level for files uploaded by different users. Please use the ChargerSync enterprise or account Identifier for that.
• Randomly generated file identifiers to make it harder for adversaries to enumerate file IDs. We recommended using the UUID format.
• Added support for OCPP Security Profile 1-2, username and password authentication over HTTP/s, to Terra AC models with a unique random key to each charger. If possible, please apply Security Profile 2 by default.

ABB adopted the mitigation principles that were suggested above, closed the vulnerabilities of ChargerSync API, and added support for OCPP Security Profiles 1-2 to the ChargeSync platform, by default.

ABB also implemented a rotation of OCPP credentials without the need of a user intervention.

SaiFlow’s Responsible Disclosure and ABB’s Response

After disclosing the vulnerabilities found on ChargerSync to ABB, the ABB security team understood the severity of this issue and took all the necessary steps to investigate and mitigate it quickly. ABB’s security team validated SaiFlow’s findings and conducted an investigation to find if those vulnerabilities were exploited by threat actors.

Disclosure timeline:

• April 14, 2023 – SaiFlow Research Team first noticed the issues with ChargerSync platform.
• April 16, 2023 – Issues reported to ABB.
• April 18, 2023 – Report received by ABB.
• April 19, 2023 – ABB disabled the vulnerable APIs, and initiated an investigation after further technical details were provided.
• May 27, 2023 – ABB deployed a new version of file import API.
• May 31, 2023 – Deploy support to OCPP Security Profile 1-2 for ChargerSync.

About SaiFlow

SaiFlow provides a tailor-made contextual cybersecurity solution for decentralized energy networks and EV charging sites (including EVSE, energy storage units, BMS, EMS, and more.) focusing on securing their unique architecture and standard protocols, such as OCPP, OCPI, and IEC 61850.

SaiFlow’s platform provides posture management and cyber monitoring, detection, and prevention abilities, all incorporating smart-grid and sensor data in establishing the baselines, correlations, and anomalies of these types of networks.

SaiFlow was founded by experienced cybersecurity experts, coming from the Israeli Defense Forces’ cyber and tech elite units, such as Mamram, Matzov, and the 8200 units.