Editor’s note: Read our technical blog post for a detailed examination of the vulnerability and methods of hijacking.
The SaiFlow Research Team recently discovered that cyber attackers could disable Electric Vehicles (EV) Charge Point (CP) and cause a service disruption, by exploiting certain versions of the Open Charge Point Protocol (OCPP) that uses WebSocket communications. The discovered attack method combines two new vulnerabilities that were found in the OCPP standard:
I) mishandling of multiple chargers’ connections and II) weak authentication policy.
The OCPP standard doesn’t specify how to handle more than one connection simultaneously, per individual CP. Cyber attackers could disrupt the original connection between the CP and the Charging System Management Service (CSMS), by opening an additional “new” connection to the CSMS, on behalf of the CP, and expose it to a variety of damages, including potential Denial of Service (DOS) attacks, data and energy theft from the Electric Vehicle Supply Equipment (EVSE) network. Combining the mishandling of new connections with the weak OCPP authentication and chargers identities policy could lead to a vast Distributed DoS (DDoS) attack on the EVSE network.
The attack was recently demonstrated and tested on multiple CSMS providers. Each CSMS provider that was tested handled multiple connections with the same CP ID differently and most CSMS providers were found to be vulnerable to the attack, exhibiting two types of reactions:
- Some CSMS providers will close the original CP connection, leaving the actual CP disconnected.
- Others will keep the original connection open but won’t communicate with it.
Both cases are vulnerable to the Distributed Denial of Service (DDoS) attack, while the last case is the most problematic since both the CSMS nor the CP won’t notify the Charge Point Operator (CPO) that something is not working properly.
Moreover, during the attack, in which the connection of the attacker is connected to CSMS, sensitive and personal information is exposed to the attackers, which might allow them to further attack the CSMS or steal customers’ identities.
The new vulnerabilities were found in the OCPP 1.6J version, which is the dominant version found in the wild today. The newer OCPP version (2.0.1), which is yet to be vastly deployed, can also be vulnerable to this attack if not implemented properly with the needed authentication safeguards.
“During the attack, in which the connection of the attacker is connected to CSMS, sensitive and personal information is exposed to the attackers …”
The exploitation of EV chargers
The attack method combines two vulnerabilities in the OCPP standard. I) mishandling of multiple CP connections and II) weak authentication policy in the OCPP standard. Combining both vulnerabilities can be exploited to execute a Denial of Service (DoS) on the EVSE network or perform a much larger impact and cause Distributed Denial of Service (DDoS).
I) Mishandling of Multiple Chargers’ Connections
The standard OCPP protocol doesn’t define the expected behavior when a CP accepts a “new” connection, while the original one is still in use. A CP expects to have a connection with a CSMS to allow functionalities like charging authorization, payments, discounts, billing reports, and more. If a CP isn’t able to authorize an EV to charge, the charging transaction may not be accepted and the EV won’t be able to charge. The DoS could cause financial and reputational damage to the CPO. Furthermore, in an even worst-case scenario, a company with an electric vehicle fleet that is critical for its business could be harmed or extorted for ransom by cyber attackers.
Saiflow’s research team found that CSMS providers handle multiple connections in different ways, all of which were exploitable to the attack. Some CSMS providers in the market disconnect the CP WebSocket connection when a “new” connection is established. This behavior allows cyber attackers to cause a DoS by preventing the real CP from communicating with the CSMS, via the original charger’s connection. Other CSMS providers started using the “new” malicious connection, allowing the attacker to receive sensitive information like driver’s personal information, credit card credentials, or even CSMS’s credentials for file servers used for over-the-air firmware updates.
II) Weak Authentication Policy in the OCPP Standard
According to the OCPP protocol standard with its security extensions of version 1.6J, CP can be authenticated by the CSMS provider using one of three methods: 1) CP identity alone 2) CP identity and credentials 3) CP identity and client certificate. Using method #1 might allow cyber attackers to hijack a connection from a valid charger point and act on its behalf.
In most cases, the CSMS providers are configured to enforce the above-mentioned weak authentication method #1.
When a CP creates an OCPP connection to the CSMS, using WebSocket channels, the CP provides its identity by using a parameter in the URL endpoint. An attacker can disrupt and attack many CP that are connected to the same CSMS by brute-forcing the CP identity and impersonating them. In addition to that, although passwords in general are advised to be changed every 30 days, the CP identifier is intended to be the same for the CP’s entire lifetime.
“Using method #1 might allow cyber attackers to hijack a connection from a valid charger point and act on its behalf.“
Recommendations for mitigation
As we are describing two different vulnerabilities, the mitigation should be implemented accordingly:
I) Mishandling of multiple CP connections
When a CSMS has more than one connection from a single CP, both connections should be managed by the CSMS until it determines and identifies the actual “correct” connection, by actively sending a WebSocket ping or an OCPP heartbeat request. If one of the connections is not responsive, the CSMS should eliminate it. If both connections are responsive, the operator should be able to eliminate the malicious connection directly or via a CSMS-integrated cybersecurity module.
It should be noted that there are situations where a single CP might have more than one connection simultaneously as a result of cellular reception issues, power outage following a reconnection, shutting down all of the connected CP, etc.
II) Weak authentication policy in the OCPP standard
The CPO should set a stronger security profile with at least basic authentication measures, setting a customized password and not using the default password from the factory, if provided. Enforcing this policy would make it harder for cyber attackers to exploit the above-mentioned vulnerabilities.
Looking into the future, OCPP version 2.0.1, and its security extension, will require CP credentials as the minimal obligatory security profile which might make the recommendation above redundant. However, version 2.0.1 is new and still in the early stages of adoption. We will watch for new developments in the exposure of these vulnerabilities.
Given that the CP identifier is sensitive, it should be protected with similar policies as passwords in general, for example, using a Web Application Firewall to limit the number of failed OCPP connections originating from the same IP address for a certain amount of time, or using threat intelligence feeds to prevent connections from Tor network, suspicious VPS and VPN providers.
SaiFlow’s cyber monitoring product can detect anomalies in the EVSE network, prevent, and alert in real-time on attempts to attack the CP by exploiting the above-mentioned vulnerabilities. SaiFlow also helps manage security policies across CPs, EVSE, 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 important cyber security standards.
SaiFlow provides a tailor-made cybersecurity solution for CP, EVSE, DER, energy networks, and assets, focusing on securing their standard protocols, such as OCPP, OCPI, IEEE 2030.5, DNP3, and IEC 61850. SaiFlow’s platform provides posture management, 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 established early in 2022 by experienced cybersecurity experts, coming from the Israeli Defense Forces’ cyber and tech elite units, such as Mamram, Matzov and the 8200 units.
Examples from a live exploit: