eMSP and CPOs Could Expose EV Chargers to OCPP Hijacking

It should be explicitly noted that all the described vulnerabilities in this blog were already disclosed to Shell Recharge and were addressed professionally to reduce the potential attack surface of their eMSP services. Shell Recharge have already implemented additional security measures and is in the process of enforcing additional controls: Enforce OCPP Security Profile 2 on supported EV charging stations and restrict network access through the means of allowlisting IP addresses of EV charging stations connected via Private APNs.

Intro

⚡ An adversary can abuse leaked charging stations’ identifiers to perform a wide-scale DoS attack on the public charging infrastructure.

The SaiFlow Research Team discovered a new vulnerability and attack path that allows a remote and unauthenticated attacker to cause wide-scale Denial of Services (DoS) to major public EV Charging Stations networks. The cyber attack path combines a sensitive data leakage found on a major e-Mobility Service Provider (eMSP) platforms together with weak authentication methods that are still present in the field (in multiple Charging Point Operators (CPOs)), exposing the public EV charging infrastructure to a wide-scale DoS attack. 

Nowadays, there is a growing number of incidents related to SaiFlow’s discovery happening across the world, as companies continue to move their resources to the cloud. For example, security researcher Anurag Sen found a public database of Shell Recharge, a major e-MSP platform, containing close to a terabyte of logging data with Personal Identifiable Information (PII), such as identification numbers, VIN ID (Vehicle Identification Number), sensitive fleet customers’ names, and more.

In this blog, we present and demonstrate an attack path that showcases how an attacker could easily leak sensitive information from major eMSP platforms and utilize it to perform a wide-scale DoS attack on public EV charging networks.

TL;DR

e-Mobility Service Providers (eMSP) and mobility hubs have a key role in the EV charging ecosystem. They enable interoperability between different EV Charge Point Operators (CPO) and EV drivers. This interoperability enables drivers to charge their EVs with charging stations of different operators and even across different states. As a result, the eMSP platforms aggregate and hold data from multiple CPOs and public charging networks.

eMSP and also Charging Station Management System (CSMS) platforms provide drivers with a variety of information on charging stations, such as charging tariff, type of connector, availability, operator, and more. But they sometimes provide extra and unnecessary sensitive information, such as the charging station’s Identifier and serial number, which could be exploited by an adversary to disrupt the charging station operation and render it unavailability.

This attack scenario utilizes the recent vulnerability found in the common OCPP 1.6J protocol (the mishandling of multiple WebSocket connections open by the same CP identifier) and emphasizes the urgent need to enforce strong authentication methods, defined under the new OCPP standard, and monitor for configuration changes in the charging network.

Potential Attack Flow

1. An adversary uses the API services of the eMSP or CSMS to analyze the full response data.
2. The response leaks excessive information on each EV charging station including name, description, IDRO identifier, availability, and more.
3. The adversary identifies the OCPP endpoints used by the operators’ CSMS using OSINT tools.
4. The adversary connects to the operators’ OCPP endpoint and hijacks the connections of the EV charging stations to disrupt their service and expose sensitive information.

In this blog, we will describe:

• Where leaks of charging station identifiers can be located
• How an adversary can combine OSINT and leaked identifiers to disrupt CPOs functionality
• Disruption simulation
• Attack exposure insights, based on data analysis
• CSMS leaks root cause analysis
• Recommendations for mitigations

eMSP ↔️ CPO

Figure 1 below, illustrates the relationships between the entities in the EV charging landscape. In this blog, we are going to cover mainly the area of data exchange between the EVSE, CPO, and eMSP.

Data is exposed, where?

Behind the scenes, the search (for nearby EV charging stations) runs an API request to query for the charging stations’ information, as can be seen in Figure 3 below (FYI, the API credentials are embedded in the mobile app).

For each location object received from the query above, we could further request the details of the charging station itself based on the location UID, as can be seen in the two figures below (Figure 4 and Figure 5).

The responses include leaked sensitive information. This request is sent to a different API host, responsible for the charging station data itself, as seen in the request’s host header.

In the response (the right side of Figures 4 and 5), we could see multiple data points:

• Marked in yellow, is the name of the EV charging station.
• Marked in orange, is the name of the Charge Point Operator (CPO) that manages this queried charging station.
• Marked in red, are the identifiers evseId and externalId, used for the interoperability between the eMSP and the operator’s CSMS (a.k.a CPO). (These identifiers vary in their format between different CPOs and are dependent on the implementation of data exchange between these entities.)

Moreover, the charging station’s identifier is innocently shown in the mobile app itself (Figure 6):

Why should the charger identification keys be considered sensitive information?

A recently discovered vulnerability in the implementations of CSMS platforms allows attackers to cause Denial of Services (DoS) and perform energy theft. The vulnerability relies on how these systems mishandle multiple connections with the same charging station identifier. The vulnerability, which exists in the WebSockets for OCPP 1.6 protocol (OCPP 1.6J), can be used by an attacker to hijack the connection between the CSMS and the charge point for the sake of disabling the charger and entire station, receive sensitive configuration details, causing billing discrepancies, and stealing energy.You can find more details about it in our blog – https://www.saiflow.com/how-mishandling-of-websockets-can-cause-dos-and-energy-theft/.

How do we know it’s really the charger’s identifier?

The short answer is that people in the industry can easily identify prefixes and formats of charging station vendors just by looking at their serial numbers or identifiers. For example, ABB Terra AC charger starts with TACW<Wh><SERIAL>, Veefil with veefil-<SERIAL>, and so on.

The detailed answer is that we can’t always identify the charger clearly that way. We needed to validate that what was actually exposed is the charger’s correct identifier and for that, we needed to try and connect to the CPO platform by using the exposed key. In order to connect the CPO we require two key information points:

1. The identifier of the charging station (which we claim was exposed).
2. The operator’s URL for the Open Charge Point Protocol (OCPP) endpoint (the endpoint that the charging station is configured to communicate with).

Continuing the attack path – the way to a wide-scale DoS

To fully understand the importance and potential of the leaked information and why it is urgent to enforce the new OCPP security profiles in all charging networks as soon as possible, we simulated an end-to-end attack path on a major public charging network. It is important to note, that multiple eMSP platforms and charging networks are exposed to the same attack scenario as well.

The attack path has 4 main parts:

1. Discover the charging stations identifiers (leaked from the eMSP platforms).
2. Discover the operator of those charging stations (the operator’s name is also leaked from the eMSP platforms).
3. Locate the OCPP end-point the charger is connected to.
4. Connect to the OCPP end-point using the charging station identifiers.

If the charger is not set with the appropriate OCPP security profile, the attacker could hijack the OCPP connection and disrupt its availability (DoS).

Locating the OCPP endpoint with OSINT

One of the methods that can be used to locate the OCPP endpoint of operators is by searching their installation manuals. A quick search on the internet provided us with the example below of Green Motion provider.

As another example, We also located in the Shell Recharge app a charging station operated by a certain operator (as showcased in the section above). We couldn’t find an installation guide to locate the OCPP endpoint, so we used the services of SecurityTrails in order to find the OCPP domain that is probably been used by that operator.

We saw that there are operators that use OCPP wording in their domain names so we filtered according to that and took the most relevant sub-domain.

Validation phase – trying to connect

To validate our observation, we simulated a connection to an OCPP endpoint by using the charger identifier, found in the Shell Recharge app, and for a few seconds simulated what might happen to the presented charging station’s availability via the CSMS platform in case of a possible hijacked connection (one of its ports would be presented as not available). We present the simulated results below – it can clearly be seen that the availability status would have changed in such a scenario, even though nothing was actually changed in the field or in reality.

Finding Another Leak

It is common for eMSP and CPO providers to provide a mobile application for drivers to find and use charging stations. Some of them are also providing their services through websites.

The API interfaces being used for mobile applications and websites might be different, in their structure, data governance, external sources, region, etc. For Shell Recharge, we found a dedicated website for the region of North America located at sky.shellrecharge.com.We analyzed the data that is exposed through the APIs of this website and found identifiers of charging stations leaking at the fields of serial, physicalReference, evseUid, deviceId, evseDisplayId, and evseEmaid.

Leak Summary

Note: Not only did the name of the charging station has revealed the real charging station identifier, but also the “externalId” and “evseId” have revealed the charging station identifier value in the case of the operator’s charging station above. The red mark in Figure 5 shows the real identifier included as part of the IDRO value used for roaming providers. This indication might be strongly related to the CSMS implementation of the roaming protocol. We will cover this subject later in this blog.

The Community as an OSINT Platform

⚡ Using the pictures that are uploaded by drivers to the Chargermap community platform, we have located valid charging stations’ identifiers that could be abused in the same manner by cyber attackers.

The sections above illustrate how an adversary can locate charger identifiers and their managing operator using eMSP leaks in the interoperability channels. However, we found out that leaks can also manifest in different ways.

Adversaries can gather large amounts of charging station identifiers and their operators’ OCPP interface, via OSINT operations, in order to perform large-scale cyber attacks and impact those public charging networks and the eMSPs.

Data Insights

In order to see how vast this potential exposure is, we analyzed the data containing about 490,755 individual ports of charging stations in Europe and South America. We focused on the fields: Name, Physical Reference, and EVSE ID and searched for leaking charging station identifiers.

To minimize inaccuracies in our estimations, we eliminated the chargers with identified IDs that don’t fit the serial number format and groups of chargers that are managed by that CPO that had mostly sequential numbers in its pattern and generic prefix. We needed to be careful when eliminating these charging stations because some EV charging station manufacturers do use sequential identifiers, but it was important for us to minimize the false positives as much as possible.

The values below are based on the filter criteria which represent in most cases an identifier of a charger. An identifier would be a value that contains a prefix of 2 to 4 letters representing a charging station model, and a suffix of letters and numbers in the length between 6 to 9.

Our estimation is as follows:

Listed below is the estimation of exposed charger identifiers in each field:

• Name: 5.8% of chargers
• Physical Reference: 1.5% of chargers
• EVSE ID: 16.3% of chargers
• Total: 19.8% of chargers identifiers were exposed.

Close to 97,169 charging station ports can be potentially exploited.

Manufacturers that use sequential values for charging station identifiers or serial numbers might allow adversaries to reduce the time and effort of performing brute force attempts on CSMS providers and their OCPP interface by adjusting the range of possible values.

Operational Habits & Implementation

We asked ourselves how is it that only a portion of the data contains these sensitive values and not all of the data.

Our answer is that different CPOs have different approaches when provisioning charging stations:

1. It could be that some operators are used to save chargers’ IDs in fields like description, name, and physical location but are not aware that these sensitive fields are shared with external entities and can later be publicly exposed to EV drivers and malicious actors.
2. Another aspect is the different implementations of the roaming interface by CSMS providers. Some CSMS providers use the real charging station identifier as an IDRO or use it in other identifying fields that are shared publicly through the eMSP services. Those identifiers should be handled like a secret by the CSMS and mask it from external entities.

Recommendations

• Enforcing OCPP security profile 2 or above – implementing and enforcing the authentication for charging stations would prevent abuse of leaked data by adversaries who intend to disrupt operators and eMSP providers.
• Remove any potentially sensitive data – remove any sensitive data located in fields that might be shared with roaming providers.
• CSMS providers should mask the real identifier of the charging station they manage and prevent them from being revealed to external entities. A unique reference ID should be created for the interoperability between the CSMS and the eMSP.
• Monitor for suspicious connections made to the CSMS provider – Monitor for connections made on behalf of charging stations and create alerts on suspicious OCPP messages that could indicate a large-scale attack, such as suspicious charging station IP (location), number of unsuccessful tries, etc.
• Check if your CSMS provider or CPO is sharing your sensitive data or using your real charging station identifiers as the ID Registration Organization.

SaiFlow’s cybersecurity platform can enforce the needed OCPP security profiles and detect anomalies in the EVSE network, prevent, and alert in real-time on attempts to attack the charging stations. SaiFlow helps manage security policies across charging stations and Distributed Energy Resources (DER) networks and provides visibility and risk management abilities, allowing a CPO to decide on enforcing authentication policies, default credentials, and other cyber security standards.