Exploiting Hidden Supply-Chain Vulnerabilities to Attack EV Chargers and CPOs
Lionel Richard Saposnik
VP of Research at Saiflow
Contents
It should be explicitly noted that SaiFlow has approached the relevant vendors to disclose the vulnerabilities. Until a full patch is implemented, the names of the vendors won’t be included here.
TL;DR
In this blog, we describe multiple vulnerabilities found in several Charging Stations Management Systems (CSMS) of different EV charging stations’ vendors that maintain “shadow” remote management channels, exposing Charge Point Operators (CPOs) to supply chain attacks.
The SaiFlow’s Research Team found several high-risk vulnerabilities and severe supply chain attack vectors within EV charging stations, which could be exploited by unauthorized users to inflict various types of damage, including:
Gain remote control and impact the charging availability (Denial of Charge);
Execute load-altering attacks to impact the local grid;
Propagate attacks from the charging network to the organizational network and gain access to sensitive information.
CPOs and owners of charging networks, sites, and charging stations should be aware of vendors’ “shadow” management channels and include them as part of their risk assessment reviews and mitigation plans.
SaiFlow’s cybersecurity platform uniquely designed for EV charging networks and could help you with mitigating the risks and exposure of supply chain attacks, by providing visibility, posture management, and continuous monitoring capabilities to EV charging network operators and owners.
“CPOs and owners of charging networks, sites, and charging stations should be aware of vendors’ “shadow” management channels and include them as part of their risk assessment reviews”
Vendors’ Shadow Management Channels
Vendors of EV charging stations offer, alongside their hardware, a wide range of management services to Charge Point Operators (CPOs) to help CPOs effectively oversee their charging stations’ operations.
These management services, offered through the vendor’s default proprietary Charging Station Management System (CSMS), include automatic over-the-air (OTA) firmware updates, scheduling advertisements, and configuring OCPP. All services are supported through their tailored CSMS.
In many cases, CPOs of public or private charging sites and networks opt to switch the default vendor-provided CSMS in favor of a feature-rich 3rd-party CSMS.
While the charging stations are managed by the 3rd-party CSMS, the vendors of the EV charging stations might still maintain a live management backchannel for “their” charging stations (in parallel to the configured CSMS) to support maintenance services and pull telemetry for their own usage.
We observed multiple approaches to how charging station vendors maintain these shadow backchannels:
1. Shadow OCPP Channel
With DC Fast chargers, we observed that the vendors maintain full management control, in addition to a 3rd-party CSMS provider that is used by the CPO. The vendor and the 3rd-party have overlapping functionalities. However, the main use of a 3rd-party CSMS is for drivers management, daily operational usage, and integration with external systems like e-Mobility platforms. The charging station vendors’ CSMS are used for proprietary OCPP configuration, custom features, and firmware updates.
The common term for these backchannels is “Shadow OCPP”, and we will use it in this blog as well. These Shadow OCPP channels can be maintained using a second “vendor” SIM card, a second router, or the same router.
2. Proprietary Backchannel
With Type 2 (AC) chargers, vendors maintain different levels of control over their charging stations. In some cases, vendors continuously send device logs to their backend servers for diagnostic and remote support. Other vendors might establish a higher level of control with a remote shell integrated into the chargers’ OS (as described in ChargePoint Home security research published by Dmitry Sklyar from Kaspersky – 7.3. sshrevtunnel.sh analysis).
3. MQTT Communication
In some cases, Type 2 chargers might be managed with a proprietary protocol and use the vendor’s backend system for OCPP integration service, to enable CPOs to use a 3rd-party CSMS. In this case, EV chargers can’t communicate directly with the 3rd-party CSMS but rather pass through the vendor’s proprietary interface, which maintains full control over the EV chargers.
“These shadow OCPP communication channels, which vendors maintain for their backend systems, expose CPOs to supply chain attacks.”
Exploiting Supply Chain Backchannels
Now that we have listed the different types of shadow management channels used by EV charging station vendors, we can deep dive into the vulnerabilities found on several charging station vendors’ CSMS and how they can affect CPOs and EV charging networks.
1. The CSMS-as-a-“Proxy” Supply Chain Attack
We chose this title to describe the attack path and vulnerabilities on the vendor’s CSMS. To make a long story short, after analyzing the vendor’s CSMS, web API, and public mobile app, we discovered that the messages sent from the user’s mobile app to the web API actually encapsulate the user’s raw payload, which is sent to the target EV charger through the CSMS, without validations. Hence, the reason we describe the CSMS as a “proxy”.
“Anyone can connect to the web service WebSocket interface and send control messages to managed EV charging stations. A threat actor could remotely disable and control all the vendor’s managed EV charging stations.”
Let’s get into the details of the process of finding the supply chain vulnerabilities exposed by the architecture above.
For our analysis, we established MITM between the mobile app and web API.
To analyze the communication between the CSMS and the target charging station, we used SaiFlow’s security monitoring platform.
For the assessment and exploitation process, we used Burp Suite for message manipulation, a jailbroken iOS device, and Objection to bypass the certificate and jailbreak verifications. We also created a new user on the mobile app without any EV charging stations attached to its account.
After analyzing the traffic (see the figure above) and performing code analysis of the mobile app, we were able to construct a list of message types that can be sent from the user’s mobile app directly to the EV charging station, through API and WebSocket requests. The list includes, start (charging) transactions, stop, reset, set max output current, and more.
During the assessment process, we located a main issue. Anyone can connect to the web service WebSocket interface and send control messages to managed EV charging stations. A threat actor could target charging stations by specifying their serial number in the request payload. No authorization controls prevent users from sending control messages to the charging stations, even if they do not belong to them.
The charging station will receive the user request because the vendor maintains its shadow OCPP channel!
“The supply chain attack applies to private charging stations (private EV fleets) and public stations that don’t appear under the vendor’s mobile app.”
We investigated the messages sent from the vendor’s CSMS to the charging stations. We can see the original user messages encapsulated with a DataTransfer OCPP message when the message is sent from the CSMS to the charger. The message contains the original user payload from the mobile app.
Using the control messages in the app, we can manipulate any connected charging station of this vendor. A threat actor can execute a large-scale denial of service (or denial-of-charge) to public charging stations, and private charging fleets. Threat actors might also cause damage to the grid using load-altering attacks – see figure below.
We further investigated the potential damage to the vendor’s architecture and found that in addition to the broken access controls described above, the API service doesn’t validate the user payload. A threat actor could have full control over the sent payload and might attempt to exploit it for other types of vulnerabilities on the charging station itself such as buffer overflows, remote code execution, and more.
2. Device Logs Are Constantly Sent To The Vendor
We also found charging stations sending device logs through insecure channels (HTTP) to the vendors’ backend systems as described in the above-mentioned approach #2. Moreover, part of those logs had actual OCPP messages.
“CPOs should be aware that operational or personal data might be shared with the vendor, exposing them to supply chain attacks. The leaked data might be used by threat actors for extortion or to further their attack on the CPOs.”
In the example below, we analyzed the network traffic of an operational and heavily used charging site. Although the charging stations were configured to use a 3rd-party CSMS, the charging stations continued to send logs to the vendor’s own backend system. Within the collected traffic timeframe, we located messages containing the OCPP messages sent back and forth between the charger and the CSMS, whichincluded sensitive information such as the ID Tags. However, in most cases, those values were masked using the * character.
We used our internal data platform to analyze a large amount of data PCAPs and found interesting insights into the undocumented capabilities the charging stations might support.
On the one hand, this logs collection functionality could help CPOs in case they request support from the vendor. On the other hand, CPOs should be aware that operational or personal data might be shared with the vendor, exposing them to supply chain attacks. The leaked data might be used by threat actors for extortion or to further their attack on the CPOs.
3. Vulnerabilities Within A Proprietary Management Protocol
“Poor access control by the vendor allows anyone to send messages to any connected EV charging station on behalf of the operator (CPO).”
A different vendor of EV charging stations was found using MQTT for remote management, which is a non-standard protocol in the EV charging industry. Using MQTT is not bad by itself, but when you don’t follow the standard guidelines, you might expose yourself to threats that the community tried to prevent. In the case of this specific vendor, the vendor’s backend system acts as an OCPP translation interface as described in the above-mentioned approach #3.
At first, we analyzed the vendor’s mobile app that is used to commission the charging stations. Quickly, we discovered hardcoded credentials to the vendor’s MQTT server, hardcoded as part of the app. The credentials allowed us to access any topic on the MQTT service, and read and write to the communication channels between users, the backend service, and the charging stations.
The credentials are the same for all the mobile app users, meaning there are no user access controls on the MQTT level. Further investigation of the vendor’s proprietary message structure revealed that the access control is implemented at the application layer. However, we found more vulnerabilities within their implementation.
Messages sent by users authenticate themselves using an encrypted value, acting similarly to an authentication token. The encryption key that is used for the authentication “token” is delivered during the commissioning process, which is also sent through MQTT and visible to everyone 🤦♂️.
The encrypted “token” doesn’t have an expiration, and doesn’t include a timestamp value or the request payload, allowing anyone to send messages to any connected EV charging station on behalf of their operator.
The user UID might represent the phone name, which can potentially leak the full personal name of the mobile owner.
In addition, we found a configuration message revealing the WiFi SSID name and key. That information might allow threat actors to gain network access to victims’ WiFi, allowing threat actors to propagate their attack into the organization or building’s networks through the unmonitored and unprotected charging network.
In the figure above, the fields in the command payload are presented in hex string values. To make it easier for the reader, you can see the blue box next to the field with the actual value representation.
Summary
The purpose of this blog is to reveal unfamiliar attack paths to the EV charging infrastructure to help CPOs gain a better perspective on the potential risks of their EV charging network. CPOs would be able to decide whether to reject the risk (by choosing a different vendor) or contain and mitigate the risk by using suitable measurements and safeguards to reduce it, such as using access controls and cybersecurity monitoring solutions at different infrastructure levels.
SaiFlow’s SaaS security platform utilizes the OCPP protocol to natively connect to all energy assets on-site. The platform continuously monitors the charging activities and performs risk analysis of distributed energy and charging sites. With SaiFlow’s network access controls, EVSE configuration posture management, and anomalous power behavior analysis, CPOs could gain back visibility and control over their charging infrastructure and mitigate the supply-chain risks, as described in this blog.
Discover how SaiFlow can simplify your risk assessment and compliance journey today:
