Back
Dissecting a Research Paper on Mobile EVCS App Security
How Safe are Electric Vehicle Charging Mobile Applications from Attack?
This post provides a review of research on mobile EVCS app security and how vulnerable these apps are from attack. I have detailed my take on the research and findings, as well as what we learn from the research on improving security for mobile electric vehicle charging apps.
This paper was titled Investigating the Security of EV Charging Mobile Applications As an Attack Surface and consequently I was looking forward to reading up on novel and existing techniques to identify and exploit vulnerabilities in Electric Vehicle Charging Station (EVCS) mobile applications.
I had expected that the paper would outline the background and overall technology used with EVCS systems, but also provide a more detailed analysis of the vulnerabilities pertaining to these mobile applications, as well as their supporting remote services.
In addition to remote service-related vulnerabilities, I had also expected some of the vulnerabilities to pertain to direct mobile-2-EVCS communications such as BLE, NFC and possibly Wi-Fi along with an analysis of the protocols used within these transports.
While I was hopeful for a deep technical dive into mobile EVCS app vulnerabilities, the paper didn’t quite deliver, and operates on a higher level and more hypothetical basis. The remaining sections that follow provide some additional details on what I learned from reading the paper as well as some opinions on where I believe some improvements could be made.
Research Overview: Performing an Analysis of a Mobile EVCS App
The authors describe a general methodology and selection of tools used to perform their mobile application analysis, and while the methodology and approach to their analysis seems sound, the paper does not contain any decompiled Java, disassembled native libraries or captured/proxied HTTP data to show these techniques being used in practice.
The authors also indicate that some security controls in certain applications they examined had to be bypassed, such as certificate pinning and geofencing, but aside from bypassing certificate pinning by modifying the network security configuration file, the research does not provide any specifics on how these controls were bypassed.
Third-party software, such as “GPS JoyStick ADB Shell”, was used for a geofencing bypass, but no detailed description is provided as to who the geofencing provider is (often these geofencing features are provided by third-party libraries), the exact nature of the data collected (ie: frequency, accuracy etc…) or who collected the data (the third-party or the app provider themselves).
Rather than the mobile application itself, the paper primarily focused on the theoretical attack vectors against the supporting APIs the mobile application used (labelled CMS in the paper). One theoretical attack vector involves the simultaneous compromising of several thousand EVCSs; however, some details about how this attack could plausibly be carried out seem to be absent from the paper.
Takeaways From the Research About EV-Based Technologies
The introduction on pages 1 through 3 provides a high-level technical detail on the EVCS technologies and the industry as a whole. From reading just this section, EV-based technologies are here to stay and will be relied upon at an increasing rate for the next several years as various governments strive to meet their EV commitments and targets.
This study is not the only one to focus on the potential security issues with EV technologies as the paper quotes and references multiple previous research initiatives in this field.
While doing some of my own ancillary research, I came to view EV and EV infrastructure development as a hot topic for many levels of government, both in the US and Canada, but probably Europe as well. I am left with the impression that various government departments will rely on their respective SMEs to consult and learn from papers such as this one, so that informed and effective policies can be developed in response to a very rapidly growing sector.
Other EV-Technology Security Insights You Should Know
One of the primary threat cases discussed by the paper is the mass hijacking or malicious control of multiple EV charging stations. This single threat case is used as the basis for several attacks against the power grid itself as well as the users. However, I find the likelihood and feasibility of such an attack extremely unlikely, at least with the information that is provided in the paper. In the authors’ own words:
An attacker can leverage the discussed vulnerabilities to launch various malicious activities against the charging station and its operations such as DoS and remote charging sessions hijacking. To do this, attackers need to control a number of adversarial accounts (e.g., bots), which provide access to existing charging services through the mobile applications.
The term “a number of” is further elaborated on later in the document. The proposed attack is to place a high enough load on the modelled municipal grid bus to cause an overload, which is calculated to be around 84 MW. The authors calculate the required number of simultaneous charging sessions required for this load to be the “equivalent to 7636 EVs charging at the 11 kW Level 2 chargers”. The mass compromise of more than 7,000 EVCSs is likely a non-trivial task, but the authors do not really elaborate on how this could be done or coordinated. Some additional detail would have helped make this attack scenario more credible as I am left with some questions such as:
- How many EVCSs can one attacker-controlled account operate?
- What enumeration possibilities exist so that an attacker can know the location of a given EVCS?
- Assuming a payment method is required to create an account, or at least activate an EVCS, would it act as a mitigating factor?
There are some additional considerations for this attack to work:
- All 7,636 vehicles must be connected and drawing the full load of 11kW. EVs contain their own charging circuits and typically do not draw the full available charging current during the entire charge cycle.
- All 7,636 compromised EVCSs must be distributed within the same geographic area for that grid bus, which may represent a higher EVCS density than is present on current grid buses. However, the risk does make for a good design constraint for grid designers.
- These attacks apply only to commercial EVCSs. Private and home stations are not in-scope (and probably neither dense enough nor powerful enough) for the attack scenario.
- The attacker must have the means to identify from a compromised commercial EVCS if a vehicle is already connected to it, but no charging session has been initiated yet. No such proof of concept was provided in the paper.
I also note that the entire premise of this attack hinges on a single authentication-related vulnerability presented in the paper:
However, we found that the CMS does not perform any account-based authorization or check during charging. In other words, the connection is decoupled from the user account. The user is coupled with the charging station ID only.
In this case, having a proof of concept, where it can be shown by a series of manipulated HTTP requests that an account is able to initiate charging for one or more non-owned vehicles, would have given more merit to this attack. Being able to demonstrate the existence of this key vulnerability would help transition my perception of the attack scenario from theoretical to practical. Even a redacted attack chain would provide some reassurance. And if the issue has been reported to the manufacturer and fixed, then the full attack chain would be very useful both as proof of the issue and as a guide to other implementations for problems to avoid.
EVCS Privacy-Related Issues
Can attackers enumerate or harvest potentially sensitive data that can be used to track or conduct more advanced attacks against users or the infrastructure? Knowing a given vehicle by unique identifier, and location with time (because it was at a known charging station) seems likely to be abused by attackers.
Other Connectivity to EVCSs
The paper does not discuss the viability of attack scenarios against EVCSs using direct means such as Wi-Fi, BLE or RFID (NFC). These features are supported in home EVCSs and I would have liked to see a bit more about this potential, given that a mobile application is well suited to communicate using all of these mediums.
In addition, chargers may also support direct communications via the cable itself, such as the Tesla/CCS2 protocols. While it is unlikely to see a mobile application implementing such an interface, does the EVCS expose these protocols to the remote service in some way, or are they completely isolated in all cases?
The Attack Surface Presented by Exposed IPCs
One note that caught my eye was the requirement by some EVCSs for the user to prove physical proximity by scanning a QR code. My experience with QR code scanning and mobile apps is that they often use IPCs (ie intents in Android and custom URL schemes in iOS) to function. The paper does not elaborate on the attack surface presented by any exposed IPCs or even how the observed QR scanning system works. An example of a decoded QR code, even if partially redacted, would have been interesting to see.
An Android-Only EVCS App Was Tested
The authors only use the Android application when doing their analysis work, stating that:
Any security concern discovered in the communication between the mobile application and the CMS applies to both Android applications and iOS since they rely on the same back-end that handles their requests in most cases. Therefore, we assume that our analysis methodology and results can be generalized to both platforms, respectively.
While this statement is generally true for the issues pertaining strictly to the supporting remote services, differences between the Android and iOS platforms may affect the exploitability of certain vulnerabilities depending on what information is needed. For example, if an application uses a cross-platform development framework such as React Native and user credentials are stored to a database in the app, the implementation of that storage may differ across operating systems.
The authors do add that examining any potential differences between the two platforms “will be considered for future work”.
Takeaways to Guide Design and Implementation of Municipal EV Charging Stations
While the attacks documented in the paper do appear theoretical, I think they warrant further investigation and more detailed evidence. The paper should also be a guide to those designing and placing charging stations on municipal power grids. While designers may be tempted to assume only a percentage of EVCSs will be charging at a given time, mostly not at full power, it is probably better to assume the possibility that an attacker could cause a coordinated large percentage high power draw and restrict the number of EVCSs and the potential load on any individual power grid.
01.19.23